Anzeige:
Seite 3 von 3 ErsteErste 123
Ergebnis 31 bis 42 von 42

Thema: Apache absichern unter centos

  1. #31
    Registrierter Benutzer
    Registriert seit
    Dec 2016
    Beiträge
    34
    Hallöchen Newbie, vielen Dank das Du dran bleibst bei mir Nervensäge.

    das Upload Limit sollte derzeit bei 1 GB liegen.
    Unter www/srv liegt überhaupt keine Datei, keine Schulbade gar nichts.



    kann ich irgendwie nach "config.php" suchen ?
    oder meinst du mit "wo die Owncloud installiert wurde" genau die Owncloud schublade ? dann hätte ich eine Chance zu suchen.

    ich bin ja froh das SSL überhaupt erst mal "pips" sagt...

    UPDATE:
    mein Cloud ist online, sicher, und okay nun.
    Auhc Owncloud wirft keine Fehler mehr aus

    UND JETZT KOMMT DAS BESTE:
    mal komm ich ran, kann mich aber nicht einloggen,
    mal komm ich nicht ran.

    Grund:
    DSL.
    Eigentlich ist sie ja für einen Kalender Abgleich gedacht, aber das InternetSystem da ist
    irgendwelcher alter SChweißdraht oder so was

    es ist .................................. schlimm
    hat noch einer ne Idee, wie man die Verbindung stabiler bekommt ?

    Timeout fehler usw.
    Geändert von MasterofEnki (13.01.17 um 08:59 Uhr)

  2. #32
    Newbie and practicing Avatar von Newbie314
    Registriert seit
    Mar 2007
    Beiträge
    7.639
    Korrektur: Installation unter OpenSuse Leap 42.1 direkt aus den Paketquellen, dann liegt owncloud unter /srv/www/htdocs/owncloud .

    Da OpenSuse sich gut an die Standards hält hat du eine gute Chance die Dateien bei dir auch dort in der Gegend zu finden.

    Guck auf jeden Fall mal ins /www Verzeichnis, dort gehört der ganze Kram eigentlich hin.

    Generell gibt es unter Linux den find Befehl. Soweit ich mich erinnere war das ungefähr find (regular expression) -print damit es den Namen und Pfad der Datei ausdruckt.

    Zur Internetverbindung kannst du nur deine HW checken und den Provider nerven. Nur: muss das Ding wirklich ins WWW? Bei mir läuft es lokal im LAN. Viel weniger Sicherheitsaufwand und auch keine Zugriffsprobleme.
    Bei Konsolenausgaben / Fehlermeldungen bitte immer Code Tags verwenden: [code] -Text- [/code]
    "Überzeugungen sind gefährlichere Feinde der Wahrheit als Lügen" (H. Lesch)

  3. #33
    Elefantenversteher Avatar von florian0285
    Registriert seit
    Jun 2016
    Beiträge
    1.054
    Zitat Zitat von MasterofEnki Beitrag anzeigen
    Grund:
    DSL.
    Eigentlich ist sie ja für einen Kalender Abgleich gedacht, aber das InternetSystem da ist
    irgendwelcher alter SChweißdraht oder so was

    es ist .................................. schlimm
    hat noch einer ne Idee, wie man die Verbindung stabiler bekommt ?
    Ich hatte mal ein Netz aus DSL Verbindungen über alte Blei-Leitungen. Eigentlich sollte so ne DSL-Pipe die Verbindung teils automatisch regulieren. Was du aber noch machen kannst is die MTU runter zu schrauben. Das sollte eigentlich bei jedem Router gehen. Für DSL ist das eigentlich 1492 probier z. B. mal 1452.
    Das kannst du in manuell rauf und runter drehen und testen oder mit solchen Tools wie http://www.iea-software.com/products/mtupath/ ermitteln lassen.

    Werte über 1492 sind nicht sinnvoll also sollte das dein Maximalwert sein.

    https://de.wikipedia.org/wiki/Maximum_Transmission_Unit

    Ansonsten geb ich Newbie recht. Owncloud ungeschützt ins Netz zu lassen ist nicht gut.

    Nimm da lieber ein VPN oder nen SSH Tunnel dazu her.

    Bevor ich find benutze nehme ich lieber locate. Das ist wesentlich schneller.

    Wo das Paket seine Files ablegt findest du auch durch den Paketmanager z. B. für RPM

    rpm -ql packet-name
    Geändert von florian0285 (13.01.17 um 12:42 Uhr)
    Matthäus 7:3 Was siehst du aber den Splitter in deines Bruders Auge, und wirst nicht gewahr des Balkens in deinem Auge?

  4. #34
    Registrierter Benutzer
    Registriert seit
    Dec 2016
    Beiträge
    34
    Hallo ihr 2

    Also ins WWW muss sie. Sie läuft nun auf Nginx, der mir von der Configuration, dank einzelner virtueller Hosts, mehr einleuchtet als Appache2, bei dem ich wohl in 1000 Jahren nichts blicke.
    Keine Ahnung wieso, aber iss so.

    Sicher sieht sich das ganze an, da eigentlich alles ziemlich vernagelt ist, und auf SSL zurückweist d.h. mit HTTP ist gar nichts mehr zu wollen.
    Das Root System ( Data ) befindet sich auch nicht mehr im Owncloud Ordner, und ist ausgelagert.

    normal sollte "eigentlich" nichts mehr passieren können.

    MIt dem MTU das muß ich mir unbedingt anschaun.

    das Problem ist halt:
    ich komme bis zum Ladebildschirm.
    also den Loginscreen kriege ich
    sobald ich aber einlogge, überschreite ich die maximale Antwortzeit

  5. #35
    Elefantenversteher Avatar von florian0285
    Registriert seit
    Jun 2016
    Beiträge
    1.054
    Zitat Zitat von MasterofEnki Beitrag anzeigen
    MIt dem MTU das muß ich mir unbedingt anschaun.
    Wenns denn wirklich an DSL liegt?

    das Problem ist halt:
    ich komme bis zum Ladebildschirm.
    also den Loginscreen kriege ich
    sobald ich aber einlogge, überschreite ich die maximale Antwortzeit
    Innerhalb des LAN's funktioniert das dann einwandfrei? Dann melde dich mal dort an und schau mit
    Code:
    netstat -antp
    oder
    ss -antp
    welche Ports bei dieser Verbindung geöffnet sind. Hört sich nämlich eher so an als hättest du grundsätzlich HTTPS/SSL (Port 443?) aktiviert und am Router frei gegeben und ggf. is da irgendwo noch der Wurm auf nen anderen Port (80?) drin der dann natürlich nicht verfügbar ist.

    Wenn es an der DSL Verbindung liegen würde sollte eigentlich die Problematik auch bei der Login-Seite auftreten. So gesehen auch bei Verbindungen von innen nach außen.
    Matthäus 7:3 Was siehst du aber den Splitter in deines Bruders Auge, und wirst nicht gewahr des Balkens in deinem Auge?

  6. #36
    Banned
    Registriert seit
    Feb 2005
    Beiträge
    1.151
    openSUSE installiert kein locate. Das muss man erst mal mit zypper in findutils-locate nachinstallieren und dann die Datenbank mit updatedb erzeugen.

    Ich bevorzuge find, das ich schon beim Systemstart im Hintergrund einmal durchrödeln lasse.
    Hat man es nämlich einmal aufgerufen, dann ist es wahrscheinlich bei komplexen Suchvorgängen sogar schneller als locate.

    Die Sytax ist einfach
    find GlobaleOptionen VonWoAus Was UndMachDamit
    Die globalen Optionen braucht man eher selten.
    VonWoAus ist schlicht eine Liste von Verzeichnissen.
    Was kann ein ziemlich komplexer Ausdruck sein. Es gib -a and und -o or und dann jede Menge an Operatoren um irgendwelche Attribute der gesuchten Datei zu spezifizieren.
    UndMachDamit kann eine ziemlich komplexe Anweisung sein, die dann für jedes gefundene Objekt ausgeführt wird.

    Du willst schlicht ein
    find / -iname '*config.php' # -iname ignoriere Groß/Kleinschreibung und der Name soll ....

    Die MTU kann dir egal sein.
    Du hättest längst mit anderen Anwendungen schon länger Ärger.
    Das MTU Gespiele stammt noch aus der Zeit, als die Telekomiker Ärger mit PPPoE hatten. Lange vorbei.

    Vielleicht hast du einfach mit Portweiterleitung Ärger?
    Mag ja sein, dass da bei der Anmeldung auf SSL umgeschaltet wird.
    (Ich kenne ownCloud nicht)

    Funktioniert denn SSL durchgehend?

  7. #37
    Newbie and practicing Avatar von Newbie314
    Registriert seit
    Mar 2007
    Beiträge
    7.639
    Nach dem Login sollte Owncloud eine Übersicht über den Ordner zeigen in dem die zu teilenden Dateien liegen. Ein timeout an der Stelle weist für mich eher darauf hin dass Ports verwendet werden sollen die nicht offen sind oder dass sich die Datenbank die für Owncloud benutzt wurde irgendwie verschluckt.
    Owncloud (ich verwende eine veraltete Version da nur im LAN) sollte nicht eigenständig versuchen auf SSL zu schalten.
    Bei Konsolenausgaben / Fehlermeldungen bitte immer Code Tags verwenden: [code] -Text- [/code]
    "Überzeugungen sind gefährlichere Feinde der Wahrheit als Lügen" (H. Lesch)

  8. #38
    Registrierter Benutzer
    Registriert seit
    Dec 2016
    Beiträge
    34
    Hallo Leute

    zuerst mal wie immer:
    VIELEN DANK für Euer "mitgrübeln" hier.

    Newbie:
    welche Ports bei dieser Verbindung geöffnet sind. Hört sich nämlich eher so an als hättest du grundsätzlich HTTPS/SSL (Port 443?) aktiviert und am Router frei gegeben und ggf. is da irgendwo noch der Wurm auf nen anderen Port (80?) drin der dann natürlich nicht verfügbar ist.
    das ist auch mein Gedanke...
    Ich gehe da jetzt neu motiviert (nach ewiger Rätselei, und einleserei in Nginx, irgendwie mag ich den *hm*) mal mit 2 neuen Versuchen ran:

    derzeit ist die 80 noch durchgeschleift auf die Haupt IP.
    Da die aber kein 80 mehr brauchen wird (vorraussichtlich) schleife ich die nach Niedergang des neuen Systemes, noch einmal extra auf den Server Linux durch.

    oder anders: derzeit teilen sich 3 Server den Zugang.
    1x der derzeitige "Hauptserver", der noch produktiv ist
    1x der neue Server, der schon "online" ist, aber noch nicht produktiv (der ist halt in Vorbereitung / installation)
    1x der Linux Server auf der VM.

    intern (wie Du gelesen hast / richtig anmerkst ) geht alles.
    Dort funktioniert auch die datenbank hervorragend. ( mit MariaDB habe ich eigentlich keinen Ärger, sämtliche zugriffsrechte passen, die Nutzerverwaltung passt, die Erreichbarkeit passt, und
    das Ding runnt super (gefällt mir sehr gut).

    D.h. habe ich derzeit folgenden "Aufbau".
    1. - Hautpserver, direkt durchgeschleift, keine fremdports (d.h. z.B. "80" geht direkt an 80, 3389 direkt an 3389 usw. )
    2. - Nebenserver: dort schleife ich RDP z.B. über Port Tiggering. beispiel: port 100 z.B. weist auf 3389 usw.
    3. Linux Server, selbes Thema dort. Die 443 z.B. ist (imaginär) über Port 5555 durchgeschleift

    darum gebe ich am ende auch den Port an.
    z.B.
    meinedomain.dyndns.org/owncloud/:5555

    so komm ich auch auf den Login Screen.
    Wie zu erwarten, nervt mein selbstausgestelltes SSL Zertifikat dann: "(nicht vertrauenswürdig)"
    aber die Verschlüsslung ist aktiv (wird auch korrekt im Browser angezeigt) und wenn ich den Hinweis "skipee" komme ich normal weiter.

    Problem ist dann eben halt,das ich "mal" auf die Loginseite komme, "mal" nicht.
    dann habe ich ZUgriffszeitüberschreitung.

    also vermute ich 2 Dinge:
    1. - entweder kann ich mir mit den Ports "DIREKT" durchschleifen helfen ( der Hauptserver fährt keine Webanwendungen, außer RDP braucht
    der keinen Außenzugriff, der kann eigentlich vernagelt und verrammelt werden ).

    2. - der Linux in der VM ist einfach zu langsam.
    Warum kann ich nicht direkt beantworten, aber auch über XRDP, ist das eher ein Eigenmasochismus, statt eine "schnele" Anbindung. Windows
    kommt damit deutlich besser klar, der Linux baut sich "blockweise" auf (System derzeit: ubuntu 16 LTS )

    hm.
    Also werd ich heute wohl einen der später "arbeitslosen" Clienten nehmen, und installiere Ubuntu mal auf dem. Dann schau ich mir die Geschichte
    mal "direkt" an, ohne VM, sondern konkret auf Hardware.

    Vielleicht kann ich da noch etwas "Speed" rausholen, SOOO schwer, kanns nicht sein.

    PS: besteht ggf. die Möglichkeit, eine art "beckup" System von der VM zu machen ? also ohne das ich erst alles neu installieren müßte ?
    eher weniger oder ?

    Sonst alternativ, kann ich den "alten" server, auch zum Cloud Server umfunktionieren, das ist zwar bissel mit Kanonen auf Spatzen schießen
    wäre so es funzt, aber auch eine Lösung, der würde die Ports dann -direkt- bekommen, ohne Extraport.

    *hm*

  9. #39
    Registrierter Benutzer
    Registriert seit
    Apr 2009
    Ort
    Erde
    Beiträge
    2.814
    Nur mal kurz einige Anmerkungen:

    Man kann einfach prüfen, welche Ports für Anfragen zur Verfügung stehen und welche Programme dahinter stecken:
    Code:
    netstat -lnp # als root ausführen
    Da kannst du wenigstens mal nach vollziehen, ob so grundsätzlich alles im reinen ist, wenn nicht...
    Das Thema, wie finde Dateien, hatten wir auch schon
    Am Ende stehst du vor einem typischen Admin-Problem, denn die müssen am Ende ja dieses ganze Release-Wirrwar ausbaden, denn letztlich tust du gerade genau das - da gibt es jedenfalls mehrere Ansätze, die "Lösung" läuft für mich auf was in Richtung ansible hinaus, grober Daumen proprietäre Lösungen versagen...
    Weitere Themen sind http reverse proxy (aka load balancing), rewrite - vermutlich noch mehr (Isolation zB)
    Speed holt man raus, wenn man Abläufe vereinfacht.
    Nicht zu viel auf einmal machen - Backup ist zB ein eigenes Thema (Recovery und Isolation auch )

    Jedenfalls viel Spaß beim finden - Spaß auch sehr wichtig
    Geändert von nopes (16.01.17 um 03:14 Uhr) Grund: simplified
    Gruß nopes
    (,,,)---(^.^)---(,,,) /var/log/messages | grep cat

  10. #40
    Newbie and practicing Avatar von Newbie314
    Registriert seit
    Mar 2007
    Beiträge
    7.639
    Wenn ich dich richtig verstehe:
    -aus dem LAN funktioniert Owncloud wie es soll,
    - aus dem WWW erhältst du beim Versuch "login" durchzuführen manchmal "timeout"

    korrekt ?

    Nun ist zu sagen dass Owncloud per se nicht gerade das schnellste System ist. Deine Wahl mit MariaDB ist jedenfalls gut, damit ist es zuverlässiger. Du könntest noch googlen ob du MariaDB und python bzw. owncloud noch etwas umkonfigurieren kannst.

    Frage ist auch nach dem Anwendungsszenario: willst du wirklich von außen auf den Webclient ? Evtl. funktionieren webdav und der owncloud client ja ohne timeout....
    Bei Konsolenausgaben / Fehlermeldungen bitte immer Code Tags verwenden: [code] -Text- [/code]
    "Überzeugungen sind gefährlichere Feinde der Wahrheit als Lügen" (H. Lesch)

  11. #41
    Elefantenversteher Avatar von florian0285
    Registriert seit
    Jun 2016
    Beiträge
    1.054
    Zitat Zitat von florian0285 Beitrag anzeigen
    Innerhalb des LAN's funktioniert das dann einwandfrei? Dann melde dich mal dort an und schau mit
    Code:
    netstat -antp
    oder
    ss -antp
    welche Ports bei dieser Verbindung geöffnet sind. Hört sich nämlich eher so an als hättest du grundsätzlich HTTPS/SSL (Port 443?) aktiviert und am Router frei gegeben und ggf. is da irgendwo noch der Wurm auf nen anderen Port (80?) drin der dann natürlich nicht verfügbar ist.
    Das ganze solltest du am Client machen, damit du siehst welche Verbindung er aufbauen möchte. Nicht am Server, wo du eh schon weißt welche Ports offen sind.
    Und eben intern, wo es funktioniert, weil du da dann die vollständig aufgebaute Verbindung hast.

    Zitat Zitat von MasterofEnki Beitrag anzeigen

    D.h. habe ich derzeit folgenden "Aufbau".
    1. - Hautpserver, direkt durchgeschleift, keine fremdports (d.h. z.B. "80" geht direkt an 80, 3389 direkt an 3389 usw. )
    2. - Nebenserver: dort schleife ich RDP z.B. über Port Tiggering. beispiel: port 100 z.B. weist auf 3389 usw.
    3. Linux Server, selbes Thema dort. Die 443 z.B. ist (imaginär) über Port 5555 durchgeschleift

    darum gebe ich am ende auch den Port an.
    z.B.
    meinedomain.dyndns.org/owncloud/:5555
    Da du immer imaginär schreibst ist dann Port 80 nicht Weitergeleitet? Also wenn du
    Code:
    meinedomain.dyndns.org/owncloud/:5555
    eingibst verbindet sich der Browser auf Port 80 und findet keinen Server, meldet demnach nen timeout.
    Die Portangabe ist nämlich falsch.

    Code:
    meinedomain.dyndns.org:5555/owncloud
    Die genaue Fehlermeldung wäre auch interessant. Ist das z. B. ein "Verbindung zurückgesetzt" weil du mit "http://" auf SSL zugreifen möchtest oder ist das wirklich ein "Server nicht gefunden" weil eben nicht erreichbar? Oder ist Port 80 durch den anderen Server doch erreichbar und du bekommst ein "Seite nicht gefunden" bzw. ein "Gesicherte Verbindung fehlgeschlagen" weil du dann mit https:// auf nicht-SSL zugreifst? Kannst hoffentlich nachvollziehen?

    so komm ich auch auf den Login Screen.
    Wie zu erwarten, nervt mein selbstausgestelltes SSL Zertifikat dann: "(nicht vertrauenswürdig)"
    aber die Verschlüsslung ist aktiv (wird auch korrekt im Browser angezeigt) und wenn ich den Hinweis "skipee" komme ich normal weiter.
    Entweder speicherst du das Zertifikat dauerhaft oder erstellst dir ein kostenloses bei letsencrypt.

    Problem ist dann eben halt,das ich "mal" auf die Loginseite komme, "mal" nicht.
    dann habe ich ZUgriffszeitüberschreitung.
    Wenn du dann und an mal den Tippfehler mit dem Port drin hast wäre das nachvollziehbar. Andernfalls solltest du die DSL Verbindung noch nicht 100% ausschließen und mal vom Provider messen lassen. Kostet ja nix. Die Telekomiker haben nämlich nach wie vor noch Probleme bzw. in ländlichen Regionen oder in alten Gebäuden/Anlagen ist das nicht immer super Toll. Ich kenn sogar nen Neubau bei dem der Vermieter einfach ein paar Euro sparen wollte und dementsprechend funktioniert das Kabel-Internet entsprechend schlecht bzw. fast garnicht obwohl am Hausanschluss alles gut durchgemessen wird. Vom Hausanschluss zu den Wohnungen gibts eben manchmal auch nochmal ne letzte Meile. Wenn die anderen Server funktionieren wäre das aber unwahrscheinlich.

    also vermute ich 2 Dinge:
    1. - entweder kann ich mir mit den Ports "DIREKT" durchschleifen helfen ( der Hauptserver fährt keine Webanwendungen, außer RDP braucht
    der keinen Außenzugriff, der kann eigentlich vernagelt und verrammelt werden ).
    Wenn du da wirklich das Prot-Wirwarr drin hast... probieren....


    PS: besteht ggf. die Möglichkeit, eine art "beckup" System von der VM zu machen ? also ohne das ich erst alles neu installieren müßte ?
    eher weniger oder ?
    Also ich hatte bei regulärer Hardware bisher nie Probleme, wenn ich z. B. mit Clonezilla oder dd das Image aus ner VM auf nen PC/Laptop geknallt habe. Höchstens, dass ich mal nen Treiber fürs Netzwerkgerät oder was auch immer nachinstallieren musste.
    Also ein einfaches Festplattenimage erstellen und aufs Zielsystem bügeln dürfte gehen

    https://wiki.ubuntuusers.de/partimage/

    Wenn dein Imageformat sich in RAW konvertieren lässt kannst du das unter Umständen dann auch direkt mit dd auf die Zielplatte kopieren.
    Matthäus 7:3 Was siehst du aber den Splitter in deines Bruders Auge, und wirst nicht gewahr des Balkens in deinem Auge?

  12. #42
    Registrierter Benutzer
    Registriert seit
    Dec 2016
    Beiträge
    34
    Hallo alle miteinander

    Das Problem konnte Dank gutem mann der das Toturial erstellt hatte, gelöst werden.

    Schuldig war das Gateway des Owncloud Servers in der Konfiguration, es hat auf die lokale Schnittstelle / IP verwiesne
    muß aber korrekterweise (so etwas in der ARt dachte ich mir fast) auf die dyndns domain verweisen (ganz logisch)

    Nach Änderung der Parameter, steht die cloud nun.,
    Sie ist SSL verschlüsselt (eigenes Zertifikat) funktioniert wunderbar, und hat gleichzeitig auch 1a Zugang.
    Die Datenverzeichnisse befinden sich an sicheren Orten, und können nicht von Internet aus eingesehen werden.
    Sicherheitwarnungenoder ähnilches, gibt es keine.


    DSL ist bisel langsam, aber es ist okay

    Ich möchte mich auf diesem Wege HERZLICH bei ALLEN hier bedanken! Super Forum was Ihr habt, bleibt bloss wie Ihr seit.
    Daher:
    Riesen Dankeschön, an alle die hier mithalfen mir etwas Durchblick zu dem System zu geben

Ähnliche Themen

  1. Samba4 unter Centos 6.5 als PDC für Windows 8
    Von Schard im Forum Linux in heterogenen Netzen
    Antworten: 3
    Letzter Beitrag: 12.02.14, 07:34
  2. grafische Paktverwaltung unter CentOS
    Von dilindam im Forum System installieren und konfigurieren
    Antworten: 2
    Letzter Beitrag: 08.02.11, 11:34
  3. Apache absichern
    Von FRAD im Forum Linux Allgemein
    Antworten: 1
    Letzter Beitrag: 03.07.08, 14:31
  4. Apache: Zugriff 2-stufige absichern
    Von mfrieling im Forum Linux als Server
    Antworten: 2
    Letzter Beitrag: 30.07.07, 14:41
  5. [apache] absichern
    Von ccfritz im Forum Linux als Server
    Antworten: 9
    Letzter Beitrag: 05.02.04, 18:18

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •