Moin!

Und dann möglichst den nicht verschlüsselten FTP-Zugang schließen und nur noch sftp oder ähnlich übertragen. Wir hatten hier erst im letzten Jahr auf einem Server ständig gehackte FTP-Zugänge. Das geht per Wörterbuch i.d.R. relativ leicht.

Nö, wenn das per Wörterbuch geht, gehören die User, die solche Passworte verwenden, geteert und gefedert.

Gegen SFTP ist absolut nichts einzuwenden. Das sollte man unbedingt mal versuchen zu nutzen, selbst wenn man nur Kenntnis von einem FTP-Zugang hat. 1&1 beispielsweise bietet FTP an, spricht auch in der Konfiguration nur von FTP (das letzte Mal, als ich da rein geschaut habe), aber SFTP funktioniert mit denselben Zugangsdaten (Servername, User, Passwort) ebenfalls - und vermeidet auf jeden Fall, dass man das Passwort im KLARTEXT abhörbar für jeden überträgt.

Gegen das Hacken von FTP-Zugängen hilft nur ein vernünftiges, zufällig generiertes Passwort.

Ich habe damals die Frage aufgeworfen, wie man sowas (Fehlversuche beim FTP-Login, Eindringlinge) vernünftig loggen und überwachen könnte. Die Frage ist leider immer noch offen.

Fail2Ban ist dafür eine mögliche Lösung. Fehlversuche einer IP werden ab einer gewissen Anzahl dann in eine Sperr-Regel in der Firewall des Servers umgesetzt.

Mir persönlich gefällt diese Lösung allerdings nicht so sehr. Damit kann man sich eher prima aussperren, anstatt bösen Botnetzen (mit per Definition unendlich großem IP-Vorrat) das Leben schwer zu machen.

Auf jeden Fall sollte dafür ein separater Logserver benutzt werden.

Nicht jeder hat den Luxus, mehr als einen Server betreiben zu können bzw. zu müssen. Das ist ganz erheblich eine Kostenfrage.

- Sven Rautenberg

Hi,

* Erzeuge mit einem Programm deiner Wahl darin einen EXIF-Eintrag mit folgendem Inhalt:
  <?php header("Content-Type: image/jpeg"); fopen("0","w"); ?>
Das liest sich spannend. Hast Du es auch ausprobiert?

ja, allerdings mit Einschränkung: Ich hatte kein Programm zur Hand, das EXIF-Daten bearbeiten kann, musste also mit einem vorhandenen EXIF-Eintrag in einer JPEG-Grafik vorlieb nehmen, den ich einfach mit einem Hex-Editor modifiziert habe. Der war aber nicht lang genug (der EXIF-Eintrag, nicht der Hex-Editor *g*), so dass nur für
 <?php fopen("demo","w"); ?>
genug Platz war. Damit wurde das Bild natürlich mit dem fehlerhaften Content-Type "text/html" ausgeliefert, das war meinem IE aber egal. Er erwartete ein Bild, also hat er die ankommenden Daten als Bild interpretiert.

Was sagt der PHP-Parser dazu, wenn er im vermeintlichen Nicht-PHP-Teil nicht druckbare Zeichen, insbesondere < 32d oder > 127d vorgesetzt bekommt?

Nichts, warum sollte er? Er reicht sie genauso durch, wie er jedes auch andere Nutzzeichen außerhalb eines PHP-Blocks einfach durchreicht.

Interessiert ihn das überhaupt, solange nicht seine Start- oder Stoppsequenz darin enthalten ist?

Nicht die Bohne.

Vermutlich hast Du Recht.
Das ist dann ja *ibäh*

Allerdings. Das ist mir aber auch erst seit relativ kurzer Zeit so klar. Daraus habe ich schon die Konsequenz gezogen, dass bei einem Bildupload die von mir bisher so gelobte Plausibilitätsprüfung mit getimagesize() nicht ausreichend ist; ich muss zusätzlich noch sicherstellen, dass in dem Verzeichnis, wo die Bilder letztendlich liegen, kein PHP oder etwas Vergleichbares ausgeführt wird. Das Beschränken der erlaubten Datei-Extensions auf typische Werte wie "jpeg", "jpg", "gif" oder "png" wäre eine Möglichkeit, aber nicht immer die günstigste.

Ciao,
 Martin