Was tun bei DDOS

[flofri]

Hi!

Ich habe ein riesiges Problem.
Ich werde schon seit etwa einem halben Monat mehrmals täglich von einer DDOS-Attacke über alle Ports verteilt aus Polen attackert, habe es aber erst heute gesehen, da mein traffic-mess-programm gesponnen hatte.

Laut den Messungen im config-menu bei puretec dürfte ich kurz dafor stehen mein traffic-limit zu überziehen.

Kann mir jemand raten, was ich machen soll? Ich habe die IPs vorerst per IPTables gesperrt, was aber zum einen nur von kurzer dauer sein wird (sobald sich deren Ips ändern sind die ja wieder da) und ausserdem dennoch ja zumindest eingehenden traffic verursacht.

Kann mir jemand einen Tip geben, was ich machen soll? Bringt es etwas, Puretec zu kontakten? Oder soll ich lieber den Server runterfahren, obwohl da ein paar Kunden drauf sind?

[Joe User]

Bringt es etwas, Puretec zu kontakten?

Eventuell, wenn Du den DDoS (sachlich) "nachweisen" kannst.

Oder soll ich lieber den Server runterfahren, obwohl da ein paar Kunden drauf sind?

Sofern es keine wichtigen Kunden sind...

PS: Traffikfax für's nächste Mal nicht vergessen.

[flofri]

Nun ja, wie kann ich einen DDOS sachlich nachweisen, aus dem tcpdump ist ersichtlich, dass 3 polnische ip-adressen versucht haben mehrere dutzend mal pro sekunde verschiedenste ports zu connecten.

[Joe User]

Portscan != DDoS

Behalte mal http://www.zone-h.org/en/defacements im Auge...

[flofri]

aber so oft portscans und vor allem produzieren die bei mir gigabytes an traffic pro tag

habe auch eben gesehen, dass ich bereits am 30.08. meinen freitraffic um 3,5GB überschritten habe. Macht nach Adam Puretec: über 18â?¬ zuzahlung. Und da fehlen bis heute noch 2 Tage

[tomek]

aber so oft portscans und vor allem produzieren die bei mir gigabytes an traffic pro tag

Bitte? Kannst du das belegen? Ich bezweifel das doch sehr.

[flofri]

Mein Statement war eher so gemeint, dass ich bezweifel, dass es portscans sind, da die attacken immer von mehreren host gleichzeitig kommen und gigabyte an traffic verursachen.

Hier ist zum beispiel die portstatistik von heute:

http://www.server-koalition.de/cgi-bin/ ... y=01&hour=

Der Traffic dort von heute morgen ab 10 Uhr.
Wie man da sieht, produzieren standartports kaum traffic, aber der rest "Default" produziert gigabyteweise traffic.

[tomek]

Es gibt genug Software zum Ã?berwachen/Protokollieren von Traffic. ntop, iptables etc.

[flofri]

die webseite, die ich da gepostet habe ist ja so etwas, nur die lief längere zeit nicht.

Ich habe schon angst vor der puretec-rechnung, der server sollte eigendlich bereits seit 2 monaten weg sein, aber der umzug auf den neuen dauert so lange. und jetzt steht mir eine rechnung von bestimmt über 150â?¬ ins haus :(

[flofri]

Noch eine Frage:

Kennt eigendlich jemand ein Programm, welches solche Attacken erkennt und die IP-Addressen automatisch sperrt? Will nähmlich jetzt nicht die ganze Nacht aufpassen und die IPs von Hand sperren :-/

[dodolin]

Kennt eigendlich jemand ein Programm, welches solche Attacken erkennt und die IP-Addressen automatisch sperrt?

<Gebetsmühle>
Selbst wenn es das gäbe, würde dir das nix bringen, weil der Traffic am Switch/Router vor deinem Rechner gezählt wird und er bereits entstanden ist, wenn dein iptables ins Spiel kommt.
</Gebetsmühle>

[flofri]

Ich hab mal portsentry installiert.

Und das mit dem iptables sperren bringt mehr als man glauben mag. Ich gehe mal dafon aus, dass tcpdump an iptables vorbei direkt an der netzwerkkarte lauscht.

Und laut tcpdump sind nach der sperre nur noch ganz vereinzelte pakete von den gesperrten ips am server.

[Roger Wilco]

Ich hab mal portsentry installiert.

Und das mit dem iptables sperren bringt mehr als man glauben mag. Ich gehe mal dafon aus, dass tcpdump an iptables vorbei direkt an der netzwerkkarte lauscht.

Und laut tcpdump sind nach der sperre nur noch ganz vereinzelte pakete von den gesperrten ips am server.

tcpdump setzt nach den iptable-Regeln an. Ausserdem musst du den Traffic ja trotzdem bezahlen, auch wenn du ihn nicht mehr sehen kannst/willst, weil er wie schon geschrieben am Switch gezählt wird.

[flofri]

gibt es etwas, was den traffic vor iptables lesen kann? ich will nähmlich wissen ob der angriff noch andauert, vieleicht denken ja auch die angreifer, dass der server jetzt down ist (währe ja die logische schlussfolgerung, wenn kein paket mehr zurück kommt)

[flofri]

Eine Wichtige Frage, habe ich noch, ich hoffe, ihr könnt sie positiv beantworten:

Wenn ich mir mit:

Code: Select all

iptables -L -v -n

Die Chains anschaue, ist da dann der Traffic drinnen, der auch tatsächlich an der Netzwerkkarte angefallen ist, oder sperrt sich da iptables quasi auch selbst (mit tcpdump kann man ja (wie oben geschrieben) z.B. nicht den Traffic von gesperrten IPs sehen)

[Joe User]

Code: Select all

.------------.     .--------.     .----------.
| RootServer | <-> | Switch | <-> | Internet |
`------------´     `--------´     `----------´

Verständlicher?

[flofri]

das ist klar, ich weis schon, dass an der netzwerkkarte gemessen wird (ok, eigendlich am switch, aber eben der traffic, der auch zur netzwerkkarte geht).

aber der rootserver selbst muss ja auch allen traffic, der am switch gemessen wird sehen können (da er ja an der netzwerkkarte ankommt).

nun, mit tcpdump kann man ja nicht alles sehen, da ja schon von iptables her, die pakete von gesperrten ip-adressen verworfen werden.

meine frage ist jetzt nur: sehe ich bei iptables selbst allen traffic, der an der netzwerkkarte ankommt?

[Joe User]

Code: Select all

Messpunkt 1&1 ------------------.
Messpunkt FloFri-.              |
                 |              |
 .------------.  V  .--------.  V  .----------.
 | RootServer | <-> | Switch | <-> | Internet |
 `------------´     `--------´     `----------´

[flofri]

hm, ok, ich gehe einfach mal dafon aus, dass (fast) alles was am puretec-messpunkt gemessen wird auch an der netzwerkkarte ankommt und dadurch auch von iptables gemessen wird.

[flofri]

Hi
Entschuldigt, wenn ich noch eine Frage hinterherschicke, aber mir ist da noch etwas eingefallen, was mir bei meinem Problem sehr helfen kann.

Ist es möglich iptables so einzurichten, dass, wenn jemand versucht, einen "geschlossenen" port zu connecten, ein DROP ausgelöst wird und kein REJECT? Das würde nähmlich zumindest den Ausgehenden Traffic ausschalten und der angreifer denkt, der server ist weg.

[Roger Wilco]

Ist es möglich iptables so einzurichten, dass, wenn jemand versucht, einen "geschlossenen" port zu connecten, ein DROP ausgelöst wird und kein REJECT? Das würde nähmlich zumindest den Ausgehenden Traffic ausschalten und der angreifer denkt, der server ist weg.

Nein, denkt er nicht. Das ist ungefähr so, wie wenn du dir die Augen zuhältst und schreist "Ich bin unsichtbar! Ihr seht mich nicht!" ;)

[flofri]

Naja, ich habe es jetzt per IPTables-Firewall realisiert.

Nur noch die ports sind offen, die benötigt werden.

Was mir nähmlich aufgefallen ist, dass, wenn ich eine IP gesperrt hatte (DROP) der Traffic dieser IPs zu meinem Server nur noch im byte pro minute bereich gelegen haben. Ich gehe einfach mal davon aus, dass das daher kommt, da das angriffsprogramm wartet, bis etwas passiert ist um einen erneuten versuch zu starten. Normalerweise passiert sofort etwas (REJECTED). So aber dauert es manchmal minutenlang, bis was passiert (request timed out).

Einen anderen "vorteil" den man daraus zieht ist, dass der server nicht mehr auf pings reagiert. die meisten programme (habe selber mal portscans und ähnliches gemacht, daher mein wissen). pingen nähmlich erst einmal den server an, befor sie etwas unternehmen (währe ja sinnlos einen portscan an einer ip durchzuführen, an der kein rechner hängt).
Und ich glaube auch kein script-kiddie der welt macht sich die mühe und schaut nach ob auf einer ip ein webserver läuft, wenn er keinen ping bekommt.

Ich glaube, dass die Angriffe jetzt endlich ein ende haben werden (oder zumindest weiter im byte pro minute bereich bleiben).
Naja, auf den Kosten werde ich wohl sitzen bleiben (werden wohl über 200Euro allein an zusatztraffic sein, wenn 1und1 mir da nicht entgegenkommt).

Aber: aus fehlern wird man klug. bei meinem neuen server kommt gleich eine firewall drauf.

[Anonymous]

Aber: aus fehlern wird man klug. bei meinem neuen server kommt gleich eine firewall drauf.

1. Ist ein Paketfilter (iptables) _keine_ firewall
2. Ist deine Methodik genauso zuverlässig wie Stochastik .. ein Scriptkiddie wird genauso nen scan durch nmap/nessus/$sonstwas machen wenn es kein Ping reply gibt.
3. Der einzige *Vorteil* den man am 'DROP' sehen könnte wäre der, dass es keinen 'Antwort Traffic' mehr gibt, was ich aber als trivial einstufen würde.

[captaincrunch]

Der einzige *Vorteil* den man am 'DROP' sehen könnte wäre der, dass es keinen 'Antwort Traffic' mehr gibt, was ich aber als trivial einstufen würde.

Falsch: beim "drop" weiß jeder, der auch nur einen Hauch von Ahnung hat, dass sein Gegenüber herzlich wenig von Netzwerken / Paketfiltern versteht.

[cjhbabel]

Falsch: beim "drop" weiß jeder, der auch nur einen Hauch von Ahnung hat, dass sein Gegenüber herzlich wenig von Netzwerken / Paketfiltern versteht.

Oder dass die verwendete Software nur ACCEPT und DROP zuläßt (die eRIC von peppercon ist so ein Kandidat) ;). Mit anderen Worten ist es ziemlich egal ob REJECT oder DROP imho. Wichtiger ist doch, dass die Dienste dahinter sicher sind. Was bringt es mir alle Ports dichtzumachen, wenn ich einen Apache mit einem phpnuke am Start habe wo bereits div. Exploits bekannt sind?

Für mich macht ein Paketfilter auf einem Rootie nur Sinn um das weak end host Problem zu entschärfen. Sonst könnten zumindest die Nachbarn relativ leicht dort "herumspielen".

Ich selber habe nur ein paar ICMP Limitskonfiguriert und sonst keinen Paketfilter aktiv. Allerdings gibt ausser exim, apache, jabber & openvpn nichts was von aussen erreichbar ist.