Beiträge von Robert

  • Upload geht nicht

    Hier sind die Einstellungen von Suhosin erklärt: http://www.hardened-php.net/suhosin/configuration.html
    Einige der Einstellungen zielen ja speziell auf den Upload ab, die würde ich zuerst überprüfen: Nachlesen, ändern, Apache neustarten, testen. Möglicherweise sind auch mehrere Einstellungen in ihrer Kombination verantwortlich. Du könntest auch alle Einstellen möglichst wenig restriktiv einstellen und dann nach und nach die sichereren Werte wieder übernehmen.

  • Upload geht nicht

    Und als du sie umbenannt hattest, tauchte Suhosin nicht mehr in der phpinfo() auf? Es werden alle Dateien in /etc/php5/conf.d/ verwendet, also auch /etc/php5/conf.d/suhosin2.ini oder so. Wenn schon, musst du die Datei verschieben, sodass sie nicht mehr geladen wird. Du musst es ja nicht ausgeschaltet lassen - aber bevor du jede einzelne Einstellung austestet, kannst du damit testen, ob es überhaupt an Suhosin liegt.

  • Upload geht nicht

    Von den Extensions, die du installiert hast, fände ich es am nachvollziehbarsten, wenn Suhosin den Upload blockt. Du kannst ja mal versuchen, ob es geht, wenn du Suhosin kurzzeitig deaktivierst.

  • FTP beschränken

    Oder du machst einen über HTTP nicht erreichbaren Upload-Bereich, der dann entweder regelmäßig oder/und über eine Seite überprüft wird und nach dem Aschenputtel-Prinzip die Dateien in den öffentlichen Bereich verschoben bzw. gelöscht werden.

    Ansonsten gibt es ja noch Flash-Uploader, mit denen man auch recht bequem mehrere Dateien hochladen kann, ohne jede einzeln auswählen zu müssen. Bei ZIP-Dateien muss man ggf. das Upload-Limit hochsetzen, und man sieht nicht, wie weit der Upload vorangeschritten ist und kann ihn nicht später fortsetzen. Dafür kann man sie natürlich leichter kontrollieren.

  • Zertifikat pro Server oder für jede Domain

    Letztendlich ist das denke ich eine Entscheidung, bei der es darauf ankommt, was genau man machen will.

    Wenn ich hauptsächlich für mich selbst für verschiedene Administrationsseiten (Backend von WordPress, phpMyAdmin, ...) auf meinem Server eine verschlüsselte Verbindung haben möchte, ohne dass ich ständig über Warnungen stolpere, dann finde ich den Weg über Alternativnamen absolut legitim.

    Sobald mehr oder weniger fremde Personen ins Spiel kommen, muss man abwägen: wie oft müsste das Zertifikat geändert werden, kann man Besuchern zumuten, dass sie das Root-Zertifikat installieren (es macht einen Unterschied, ob der HTTPS-Zugriff an die Allgemeinheit oder an einen bekannten Personenkreis gerichtet ist), welche Browser werden eingesetzt usw.

    Vielleicht kann man auch beide Ansätze kombinieren - denn ich sehe schon ein, dass SNI sauberer ist, aber z.B. mein iPhone unterstützt das noch nicht. Und wenn ich dafür einige Sachen selbst kompilieren muss, anstatt sie über die Paketverwaltung zu beziehen, finde ich das auch nicht gut.

  • Zertifikat pro Server oder für jede Domain

    Jap. Bzw. könnte man schon, man müsste dann halt bei jeder Änderung ein neues Zertifikat erstellen, was sicher nicht gerade ideal ist. Zumal das auch nur geht, wenn man sich das Zertifikat selbst erstellt, eine fremde Zertifizierungsstelle wird sich darauf wohl nicht einlassen. Daher müssen Besucher der Seite dann sowieso beim ersten Versuch dem Zertifikat vertrauen. Wenn sie nur das Zertifikat selbst akzeptieren und sich das dann ständig ändert, könnte das nicht so gut ankommen. ;) Wenn sie allerdings das Root-Zertifikat (der eigenen Zertifizierungsstelle) als vertrauenswürdig einstufen, dürften sie den Übergang beim Zertifkatswechsel nicht merken.

  • Zertifikat pro Server oder für jede Domain

    Ich bin mir ziemlich sicher, dass ich das nicht habe. Es steht nicht so explizit im Artikel, aber der Ansatz müsste dem Namen nach so funktionieren, dass schon beim Verbindungsaufbau die Domain mitgeteilt wird und daher das passende Zertifikat ausgeliefert werden kann. Bei mir hingegen wird immer das gleiche Zertifikat ausgeliefert, aber das ist für mehrere Domains (bzw. IPs) gültig.

    http://www.openssl.org/docs/apps/x509…ternative_Name_

    [Blockierte Grafik: http://img9.imageshack.us/img9/6995/certv.jpg]

  • Zertifikat pro Server oder für jede Domain

    Das Zertifikat wird vom Apache ausgeliefert, sobald eine Verbindung aufgebaut wird - zu diesem Zeitpunkt wurde noch nicht übertragen, um welche Domain es gehen soll, daher kann es nur ein Zertifikat pro Kombination von IP und Port geben (aber verschiedene Zertifikate für Port 443 und 8443 wären z.B. möglich).

    Der Browser (bzw. allgemein der Client) vergleicht beim Aufbau der Verbindung den Namen, auf den das Zertifikat ausgestellt wurde, mit der Domain, die aufgerufen wurde. Wie schon gesagt wurde, hat das also nichts mit der IP oder dem internen Hostnamen zu tun. Wenn du beispielsweise deine Domain auf einen anderen Server umziehst, kannst du trotzdem das selbe Zertifikat weiterverwenden. Das heißt aber auch, dass der Name im Zertifikat genau mit der aufgerufenen Domain übereinstimmen muss. Wenn deine Seite sowohl über die IP als auch über eine Domain aufrufbar ist, das Zertifikat aber auf die Domain ausgestellt ist, kriegt man beim Aufruf über die IP eine Warnungsmeldung. Wenn man seine Zertifikate selbst erstellt, kann man das umgehen, indem man Alternativnamen ins Zertifikat schreibt. Damit funktionieren sogar mehrere Domains pro IP/Port-Kombination. Wenn du das Zertifkat irgendwo bestellen willst, hast du diese Möglichkeit sehr wahrscheinlich nicht, daher musst du dir überlegen, wie die Seite aufgerufen werden soll (IP, domain.tld oder https://forum.netcup.de/www.domain.tld) und das auch bei der Bestellung angeben.

  • Mal ne andere .bashrc

    Nachdem ich mehrfach Befehle auf dem falschen Server eingegeben hatte, habe ich auf den Servern unterschiedliche Hintergrundfarben für "root@server:" festgelegt. :) Ansonsten habe ich glaube ich nur den Alias "l" für "ls -lA" drin.

  • FTP beschränken

    Zitat von Mo3;19282

    Gut, damit werde ich wohl leben müssen :o

    Hm, sagen wir mal so.. du hast (zumindest, wenn du die Einstellungen aus dem anderen Thread verwendest) keinen Open Base Dir gesetzt, somit kann PHP auf die Dateien zugreifen, die der Apache erreichen kann. Selbst wenn du ihn setzt, geht das aufgrund der Dynamik höchstens auf /gallery zu beschränken. Wenn jemand eine showcase.php hochlädt, kann er also die Daten auch für andere Benutzer lesen/schreiben. Und Shell-Befehle ausführen. Ein Angreifer müsste also nur c99.php in showcase.php umbenennen... nicht so gut.

    Dann würde ich lieber zusehen, dass von http://example.gallery.tld/bild.jpg intern auf einen Unterordner weitergeleitet wird oder so.

  • FTP beschränken

    So vielleicht?

    Code
    <DirectoryMatch "^/gallery/[^/]+/images">
   php_admin_flag engine off
</DirectoryMatch>




<FilesMatch "^/gallery/[^/]+/showcase.php$">
   php_admin_flag engine on
</FilesMatch>

    Damit würde das für showcase.php wieder eingeschaltet werden... allerdings bleibt eine Lücke, denn ein Benutzer könnte ja selbst eine showcase.php hochladen. Deine Vorstellungen sind aber auch wirklich nicht einfach umzusetzen. ;) Und wenn du die beliebigen Dateien auch in ein Unterverzeichnis verschiebst? Dann wären die Dateien eben unter http://example.gallery.tld/files/bild.jpg erreichbar...

  • FTP beschränken

    Was heißt "normales Upload-Verzeichnis"? Ich verstehe grad leider nicht, was genau du da bauen willst. Liegt denn die PHP-Datei zur Anzeige der Bilder im gleichen Verzeichnis wie die Bilder selbst und ist somit auch über FTP veränderbar oder zumindest einsehbar? Davon würde ich abraten. ;) Also wenn du das eh selbst schreibst, solltest du vielleicht auch auf diese Aspekte achten, indem du ein Verzeichnis pro User anlegst, in das wirklich nur die hochgeladenen Dateien kommen. Das wäre für die Sicherheit und Wartbarkeit bestimmt von Vorteil.

  • FTP beschränken

    Ich wüsste gerade nicht, wie das im Voraus gehen sollte. Per Cronjob alle ungewünschten Dateien löschen zu lassen ist nicht so ganz im Sinne des Erfinders. Als erste Gegenmaßnahme kannst du aber das hier in die vHost-Einstellungen aufnehmen:

    Code
    php_admin_flag engine off

    Damit schaltest du für diesen vHost die Ausführung von PHP ab. Ggf. musst du das noch in einen Directory-Block o.ä. packen, wenn du für Teile des vHosts (die nicht veränderbar sind) doch PHP brauchst.

  • Apache2 wird teilweise als root gestartet

    Die Frage ist eher: Warum wird logrotate überhaupt so oft gestartet? Hast du die Logrotation direkt in Apache konfiguriert? Bei mir läuft das nämlich eigenständig per Cronjob - war auch standardmäßig so eingestellt, musste es nur leicht an meine Verzeichnisstruktur anpassen.