Massive Serverangriffe - was tun?

[r00tie]

Hallo, mein Server ist zur Zeit leider massiven Angriffen ausgesetzt. Laut apache log sind es 1000ende verschiedene ips (vermutlich ein Botnetz?)
Gibts da irgendwelche mod's für apache 2.2 die das ganze verhindern können oder habt uhr andere Lösungsansätze wir ich der Lage Herr werde?

[oxygen]

runterfahren.

[r00tie]

runterfahren.

Vor den Problemen wegzulaufen ist für mich keine Lösung. Die Angriffe wiederholen sich täglich!

[wgot]

Hallo,

Die Angriffe wiederholen sich täglich!

in welchem Chat hast Du Dich denn unbeliebt gemacht? :lol:

Wie soll eine auf dem Server installierte Software verhindern, daß von außen Anfragen an den Server gestellt werden?

Man kann lediglich dafür sorgen, daß der Server nicht mehr antwortet.

Gruß, Wolfgang

[flo]

Wenn der Zugriff nur auf die IP geht, könnte es helfen, den ersten virtuellen Host zu entschlacken und damit das Responseverhalten zu optimieren - Schlimmstes Negativbeispiel wäre Confixx als Default-Seite ... ansonsten siehe oben :-(

flo.

[lord_pinhead]

Setz dich mit deinem Hoster in verbindung ob er am Router die Adresse sperren kann, auf deiner Kiste bringt es nix wenn du sachen wie mod_evasive und co. bei einem Botnetz versuchst. Alleine der Traffic müsste dir jetzt sorgen machen, nicht das du dein Kontingent sprengst.

[r00tie]

Setz dich mit deinem Hoster in verbindung ob er am Router die Adresse sperren kann

Welche Adresse? Die des Servers?..aber dann ist doch die Seite auch down

[r00tie]

Wenn der Zugriff nur auf die IP geht, könnte es helfen, den ersten virtuellen Host zu entschlacken und damit das Responseverhalten zu optimieren

hast du mir da evtl. einen kleinen input oder ein how-to oder etwas in der art... ein stichwort wär mir auch schon recht dann kann ich googlen

[lord_pinhead]

Ähm, sollte Adressen werden ;) Vielleicht am besten gleich die Adresse loggen und an den ISP weitergeben, aber würde erst den Support anrufen.

[flo]

hast du mir da evtl. einen kleinen input oder ein how-to oder etwas in der art... ein stichwort wär mir auch schon recht dann kann ich googlen

Auf ein leeres Verzeichnis schmeißen, z.B. ...

flo.

[wgot]

Hallo,

ein stichwort wär mir auch schon recht

Logfiles. :roll:

Zeig mal einen längeren Auschnitt mit intensiven Angriffen (als verlinkte Datei, nicht in's Forum kopieren).

Gruß, Wolfgang

[framp]

Sofern die IP mehr als 1 mal zuzugreifen versuchen -> iptables und limit

[daemotron]

Das hilft Dir auch nur bedingt - die Netzwerkschnittstelle wird trotzdem bombardiert und der Traffic läuft auf Dein Konto. Ist nur etwas weniger CPU-intensiv als mod_evasive, da schon auf Layer 3 gefiltert wird...

[framp]

Aber der traffic wird wenigstens weniger da keine Antworten mehr geschickt werden :lol:

[zyanklee]

unser aller Freund Microsoft hat ne tolle Methode entwickelt solche Probleme zu beseitigen:
Server-Cluster vergrössern und die Bandbreite durch zukaufen von weiteren Leitungen vergrössern. Und zwar so lange, bis das Botnetz dann doch nicht ausgereicht hat um alle Maschinen und Leitungen lahm zu legen :lol:

Wenn das keine Alternative ist ... es gibt Firmen die sich mit solchen Sachen beschäftigen und versuchen dann den Urheber ausfindig zu machen ... oder zumindest die Switches/Router so zu konfigurieren, dass diese Pakete - welche ja eine immer wiederkehrende Signatur haben - direkt am Switch oder Router gedropt werden.

Wenn auch das zu kostenintensiv ist: abschalten und warten bis es vorbei ist.

Letzter Gedanke: IP wechseln ?

[flo]

Wenn auch das zu kostenintensiv ist: abschalten und warten bis es vorbei ist.

Wie wäre es mit

Distributed
Dienial
Of
Botnet
Services?

Mieten einer UMTS-Flat und Schicken aller Bot-Zugriffe darauf ... Im Ernst - nicht ganz ernstzunhemen, weder die Sache mit der Bandbreite noch meinen bescheidenen Beitrag. Aussitzen ist wohl das beste, wenn es der Server mitmacht.

flo.

[debianneuling]

Evtl. auch mal deinen Server auf Sicherheitslücken und ähnliches überprüfen. Evtl. "bedankt" sich da jemand für SPAM oder Co., der über deinen Server versendet wird.

[lord_pinhead]

Wer sich für Spam bedankt mit einem DDoS dürfte nicht ganz sauber sein, das eintragen in Blacklists ist da intelligenter. Wenn wir mal die Logfiles sehen könnte, wäre es einfacher rauszufinden was da los ist. Wer richtig geübt ist, der grept noch den IP Adressen und macht ein massenabuse, dann sollte das Botnetz nach und nach abnehmen. Ein Perlscript wo das automatisch macht für so eine Situation wäre ganz praktisch, kennt jemand eines?

[mr_vista]

solche attacken sind echt fies, kenne sowas auch noch... bei uns war es damals eine reine DoS attacke bei der, der urheber ausfindig gemacht werden konnte. da es bei dir aber verschiedene IPs sind, ist das schwieriger... ... was du versuchen kannst ist stichprobenartig ips aus der log zu nehmen und über ripe.net herauszufinden wem diese ip gehört (zum beispiel serverbesitzer wäre ideal) ... dann könnte man mit dessen hilfe den verursacher vielleicht herausfinden und anzeige gegen unbekannt erstatten... eine serverseitige lösung habe ich leider auch nicht für dich (ausgenommen der genannten, aber wohl auch nicht optimalen vorschläge)

lg

[daemotron]

Eine Firewall (egal ob auf Layer 3 oder drüber) muss die eingehenden Pakete (oder Requests) auch erst mal verarbeiten. Dabei gilt die Faustregel: Je höher der Layer, auf dem die Filterung erfolgt, desto mehr Ressourcen werden pro Paket oder Request benötigt.

Ein Proxy ist nichts anderes als ein Filter auf dem Application Layer - also der höchsten Schicht im TCP/IP Protokollstapel. Genau wie ein gewöhnlicher HTTP-Server (Apache, Lighty) muss der Proxy den kompletten Request verarbeiten und verbrät damit genau dieselbe Leistung wie ein schlank konfigurierter Webserver, der anhand des Requests entscheidet, ob und was er antwortet (insbesondere im Hinblick auf Network I/O, was in vorliegendem Szenario i. d. R. den Flaschenhals darstellt).

Von daher wäre das günstigste in einem solchen Fall bereits das Abfangen der Pakete auf der niedrigsten Ebene (Layer 2, sprich: Mac-Adressen ) Diese Aufgabe kann aber auch bereits an ein dem Server vorgeschaltetes Gerät übertragen werden (im simpelsten Fall ein programmierbarer Switch...)

Allerdings helfen solche Maßnahmen bei DoS-Angriffen - nicht aber bei DDoS-Angriffen. Eine ernsthafte DDoS-Atacke bindet so viele Clients mit ein, dass allein die Identifizierung dieser Clients die Ressourcen eines einzelnen Rechners (sprich: Netzwerk-I/O) ziemlich in Anspruch nehmen dürfte. Das einzige, was einen Server in einem solchen Fall schützt, ist ein vorgeschalteter Filter, der verhindert, dass die Paket-Massen überhaupt erst bis zum Server gelangen...

[nyxus]

Von daher wäre das günstigste in einem solchen Fall bereits das Abfangen der Pakete auf der niedrigsten Ebene (Layer 2, sprich: Mac-Adressen ) Diese Aufgabe kann aber auch bereits an ein dem Server vorgeschaltetes Gerät übertragen werden (im simpelsten Fall ein programmierbarer Switch...)

Der PC sieht auf L2 nur eine MAC-Adresse, nämlich die des Routers. (Angenommen der Angriff kommt nicht aus dem selben Netz des Opfers).

[lord_pinhead]

Eine Firewall (egal ob auf Layer 3 oder drüber) muss die eingehenden Pakete (oder Requests) auch erst mal verarbeiten. Dabei gilt die Faustregel: Je höher der Layer, auf dem die Filterung erfolgt, desto mehr Ressourcen werden pro Paket oder Request benötigt.

Ein Proxy ist nichts anderes als ein Filter auf dem Application Layer - also der höchsten Schicht im TCP/IP Protokollstapel. Genau wie ein gewöhnlicher HTTP-Server (Apache, Lighty) muss der Proxy den kompletten Request verarbeiten und verbrät damit genau dieselbe Leistung wie ein schlank konfigurierter Webserver, der anhand des Requests entscheidet, ob und was er antwortet (insbesondere im Hinblick auf Network I/O, was in vorliegendem Szenario i. d. R. den Flaschenhals darstellt).

Von daher wäre das günstigste in einem solchen Fall bereits das Abfangen der Pakete auf der niedrigsten Ebene (Layer 2, sprich: Mac-Adressen ) Diese Aufgabe kann aber auch bereits an ein dem Server vorgeschaltetes Gerät übertragen werden (im simpelsten Fall ein programmierbarer Switch...)

Allerdings helfen solche Maßnahmen bei DoS-Angriffen - nicht aber bei DDoS-Angriffen. Eine ernsthafte DDoS-Atacke bindet so viele Clients mit ein, dass allein die Identifizierung dieser Clients die Ressourcen eines einzelnen Rechners (sprich: Netzwerk-I/O) ziemlich in Anspruch nehmen dürfte. Das einzige, was einen Server in einem solchen Fall schützt, ist ein vorgeschalteter Filter, der verhindert, dass die Paket-Massen überhaupt erst bis zum Server gelangen...

Theoretisch kann man versuchen ein ICMP Host unreachable zurückzuschicken, was aber den meisten Bots egal ist, die senden weiter. Von daher ist jede Firewall Lösung inakzeptabel. Es gibt nur eine Lösung, und da muss der ISP helfen.

Kollege hat mir letzte Woche mal die Hackin9 vorbeigebracht, dort wurde das Thema IP Sinkhole bzw. Darknets besprochen. Wenn den ISP die möglichkeit hat, ein solches Sinkhole einzurichten, dürfte der DDoS innerhalb kürzester Zeit vorbei sein. Sprich, du sagst deinem ISP das dein Server unter einem DDoS leidet und bittest sie (vielleicht mit einer Tabelle der IP Adressen) diese zu blockieren, dann werden sie nicht mehr zu Server durchgestellt, allerdings wird wahrscheinlich der Traffic weiterhin gezählt. Wenn dein ISP gut ist richtet er ein solchen Abfluß ein und der Traffic wird schon vor dem ISP Router geblockt und von dort weiter bis zum Zugangsrouter (theoretisch). Wer bei einem ISP Arbeitet kennt vielleicht diese Methode, aber einigen dürfte das hier ja neu sein.

Glaub keiner hier wird auch nur annährend einen solchen Zugang zu seinem ISP bekommen, das er Routingeinträge erstellen kann. Aber das ist die einzig wirksame Methode einen DDoS zu unterbinden, alles andere ist Flickwerk. Der ISP selber würde sich einen gefallen machen wenn er den DDoS aktiv unterbindet, es sind seine Ressourcen die mit aufgebraucht werden und das Peering der meisten ISP ist schon genug ausgelastet.

Ausserdem ist die Chance, einem Botnetz Betreiber auf die schliche zu kommen, bei sovielen IP´s, extrem schwierig. Und selbst wenn ich das Botnetz lahmlege indem ich den Chat Channel (wenn das Netz darüber gesteuert wird) schliessen lasse, ist die Chance dem echten Täter auf zu schliche zu kommen winzig und die Server laufen weiter mit dem Script. Probieren kann man es ja weiter, die Server sind ja nicht vom Netz, die Anfragen werden ja nur bei dieser bestimmten IP nicht weitergeleitet.

http://rfc.net/rfc3882.html
http://www.linux.it/~md/text/blackholing.html

So Long
Lord Pinhead

[nyxus]

Kollege hat mir letzte Woche mal die Hackin9 vorbeigebracht,

Die habe ich mir bisher dreimal gekauft und jedes Mal geärgert weil die Qualität der Beiträge die mich interessiert haben einfach nur unterirdisch schlecht waren.

dort wurde das Thema IP Sinkhole bzw. Darknets besprochen. Wenn den ISP die möglichkeit hat, ein solches Sinkhole einzurichten, dürfte der DDoS innerhalb kürzester Zeit vorbei sein.

Was normalerweise nicht ser Sinn eines Sinkholes ist. Das dient meist dazu unbenutzte IP-Bereiche anzukündigen um dort Angriffe oder sonstigen IP-Müll anzuziehen und ihn dann analysieren zu können. Sinkholes schmeißen den Traffic nicht weg.

Sprich, du sagst deinem ISP das dein Server unter einem DDoS leidet und bittest sie (vielleicht mit einer Tabelle der IP Adressen) diese zu blockieren, dann werden sie nicht mehr zu Server durchgestellt, allerdings wird wahrscheinlich der Traffic weiterhin gezählt.

Was Du beschreibst ist Blackhole-Routing, was in der normalen Form leider den Nachteil hat, daß der Kunde nicht mehr erreichbar ist da Blackhole-Routing eine Destination-Adresse blockt.
Die Sache mit der Tabelle der IP-Adresse wäre hingegen "Source based Blackhole Filtering", was aber bei einem DDOS so gut wie unmöglich ist.

Wenn dein ISP gut ist richtet er ein solchen Abfluß ein und der Traffic wird schon vor dem ISP Router geblockt und von dort weiter bis zum Zugangsrouter (theoretisch).

Vor dem ISP-Router kann man nicht blocken. Denn das müßte der Router des Nachbar-ISPs machen damit der Traffic nicht erst ankommt. Man kann zwar per BGP Filter zu einem Nachbar-ISP übertragen, aber diese Filter arbeiten in die andere Richtung. Vom ISP des Angegriffenen aus könnte man höchstens aufhören die entsprechende Route anzukündigen, aber das wird sich der ISP schön verkneifen.

(Edit:) Habe mir eben noch ein paar neuere BGP-Policies von ISPs angeschaut und gesehen, daß ein paar schon die Konfiguration für Remote-Triggered Blackholes anbieten. Damit ist dann schon das Blocken im Upstream möglich.

Glaub keiner hier wird auch nur annährend einen solchen Zugang zu seinem ISP bekommen, das er Routingeinträge erstellen kann.

Ein Glück aber auch ... ;-)

Aber das ist die einzig wirksame Methode einen DDoS zu unterbinden, alles andere ist Flickwerk.

Es gibt noch andere Lösungen, die den DDOS-Traffic "reinigen", aber die sind teils recht neu und ausserdem sehr teuer, so daß die meisten ISPs das noch nicht haben.

[flo]

Wenn man DDOS einfach als Kunde über den ISP sperren könnte, wären drei Viertel aller deutschen Einwahlbereiche tot ... SCNR ;-)

flo.

[lord_pinhead]

Wenn man DDOS einfach als Kunde über den ISP sperren könnte, wären drei viertel aller deutschen Einwahlbereiche tot ... SCNR ;-)

Wo ist das Problem? Ich hätte damit keines, im gegenteil, es wäre gut und spült Geld in die Kassen der IT Dienstleister die dann schon fast überstunden mit den Kisten machen müssen. Da wären auch Virenschreiber wirklich willkommen weil man dann Geld macht *G*

@Nyxus
Ich kauf sie mir nicht, ich bekomm sie von jemanden ;) Und das Geld ist wirklich nicht gut angelegt, aber mal zum überfliegen reicht es schon.

Was normalerweise nicht ser Sinn eines Sinkholes ist. Das dient meist dazu unbenutzte IP-Bereiche anzukündigen um dort Angriffe oder sonstigen IP-Müll anzuziehen und ihn dann analysieren zu können. Sinkholes schmeißen den Traffic nicht weg.

Sie Routen den Traffic in ein Privates Netz oder in ein abgeschlossenes Netz wenn sie Ihn analysieren wollen. Wo wäre also das Problem DDoS Packete auch als IP-Müll zu klassifizieren und umzuleiten. Der ISP spart auf jeden Fall last auf anderen Routern und auch seinen eigenen. Vom Prinzip her ist es das einfachste der Welt.

Sprich, du sagst deinem ISP das dein Server unter einem DDoS leidet und bittest sie (vielleicht mit einer Tabelle der IP Adressen) diese zu blockieren, dann werden sie nicht mehr zu Server durchgestellt, allerdings wird wahrscheinlich der Traffic weiterhin gezählt.

Es sollte nicht nur das Ziel geblockt werden, das wäre schwachsinn und du kannst da ja gleich shutdown -h now eintippen ;)

The latter technique
results in taking down the services offered on the targeted/attacked
IP addresses. Inter-AS traffic will be sucked into the sinkhole,
along with Intra-AS traffic. Packet level analysis involves
redirecting traffic away from the destination host to a sniffer or a
router. As a result, if the traffic being examined includes
legitimate traffic, that legitimate traffic will never make it to the
destination host. This will result in denial of service for the
legitimate traffic.

Das ist der einzige Nachteil der Methode die du aber schon angesprochen hast.

A better alternative would be to use a sinkhole tunnel. A sinkhole
tunnel is implemented at all possible entry points from which attacks
can pass into the destination/attacked AS. Using the BGP community
technique, traffic destined to the attacked/targeted host could be
re-routed to a special path (tunnel) where a sniffer could capture
the traffic for analysis. After being analyzed, traffic will exit
the tunnel and be routed normally to the destination host. In other
words, the traffic will pass through the network to a sniffer without
altering the next hop information of the destination network. All
routers within the destination/attacked AS iBGP domain will have the
proper next hop address. Only the entry point router will have the
altered next hop information.

To detail the procedure, a sinkhole router with an optional sniffer
attached to its interface is installed and configured to participate
in the IGP and iBGP of the attacked AS. Next, a tunnel is created,
using MPLS Traffic Engineering as an example, from all border routers
attacks can potentially enter from (Inter-AS traffic) to the sinkhole
router. When a host or network is under attack, a customized iBGP
advertisement is sent to announce the network address of the attacked
host(s) with the proper next hop that insures traffic will reach
those hosts or networks. The customized advertisement will also have
a community string value that matches the set of border routers the
attack is entering from, as described in section 2. The new next hop
address configured within the route policy section of all border
routers should be the sinkhole IP address. This IP address belongs
to the /30 subnet assigned to the tunnel connecting the border router
to the sinkhole router.

Ein solches Blackhole sollte erst aufgesetzt werden, wenn der Traffic analysiert wurde. Das sind allerdings sachen die der ISP macht.

Ein Glück aber auch ... Wink

route add 207.46.250.119 tunnel0 ;)

So Long