Hallo,
Bekannte von mir haben einen Server gemietet und noch weniger Ahnung als ich ;-)
Zitat: Aufgrund von DoS-Attacken (Denial of Service) war der Server gestern kaputtgeschossen.
Da dies nicht der erste Vorfall war, brauchen sie nun Hilfe, den Server vor derartigem zu schützen.
Kann mir hier jemand ein paar Hinweise geben?
Zum Server: Apache 2.0.49 auf SuSE Linux 9.0 (i586) cat /proc/version: Linux version 2.6.8-022stab078.1-enterprise (root@kern268.build.sw.ru) (gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 SMP Thu May 11 13:51:08 MSD 2006 Weitere Infos gern auf Anfrage.
Zu mir: SuSE-Kenntnisse seit Version 6 (zwischen 0/DAU und 9/Guru vielleicht 3-4)
Gruß René Thiel (Rennkuckuck) mailto:reti@rennkuckuck.de -- http://rennkuckuck.de - Die Rumänien-Seiten http://rtol.de - Dynamische Webseiten mit PHP, mySQL und CSS
René Thiel schrieb:
Bekannte von mir haben einen Server gemietet und noch weniger Ahnung als ich ;-)
Zitat: Aufgrund von DoS-Attacken (Denial of Service) war der Server gestern kaputtgeschossen.
Da dies nicht der erste Vorfall war, brauchen sie nun Hilfe, den Server vor derartigem zu schützen.
Kann mir hier jemand ein paar Hinweise geben?
Wäre es nicht zuerst einmal angebracht, die DoS-Lücke zu finden? Wie willst du sonst Gegenmaßnahmen (jedweder Art) ergreifen?
MfG Daniel
Naja, das IP Protokoll ist ziemlich anfaellig fuer eine konzertierte DOS-Attacke. (SYN-Flooding mit gefaelschten sourceadressen etc) Allerdings wird sowas in der Regel im Zuge einer Erpressungsaktion durchgefuehrt. (Wozu sonst die Attacke ?). Und dann kann oft die Polizei helfen.
ALLERDINGS: War das wirklich eine DOS-Attacke ??
On 10/13/06, René Thiel reti@rennkuckuck.de wrote:
Hallo,
Bekannte von mir haben einen Server gemietet und noch weniger Ahnung als ich ;-)
Zitat: Aufgrund von DoS-Attacken (Denial of Service) war der Server gestern kaputtgeschossen.
Da dies nicht der erste Vorfall war, brauchen sie nun Hilfe, den Server vor derartigem zu schützen.
Kann mir hier jemand ein paar Hinweise geben?
Zum Server: Apache 2.0.49 auf SuSE Linux 9.0 (i586) cat /proc/version: Linux version 2.6.8-022stab078.1-enterprise (root@kern268.build.sw.ru) (gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 SMP Thu May 11 13:51:08 MSD 2006 Weitere Infos gern auf Anfrage.
Zu mir: SuSE-Kenntnisse seit Version 6 (zwischen 0/DAU und 9/Guru vielleicht 3-4)
Gruß René Thiel (Rennkuckuck) mailto:reti@rennkuckuck.de -- http://rennkuckuck.de - Die Rumänien-Seiten http://rtol.de - Dynamische Webseiten mit PHP, mySQL und CSS
Lug-dd maillist - Lug-dd@mailman.schlittermann.de http://mailman.schlittermann.de/mailman/listinfo/lug-dd
Falls es sich um einen exploit handelte gibt es keine Alternative zum patchen der Bugs (sprich update auf den letzten patchlevel). Ausser.... man grenzt die Menge der erlaubten IP-Adressen per firewall-regel ein, aber das geht natuerlich nicht, wenn viele Leute darauf zugreifen koennen sollen....
Frank Gerlach schrieb:
Ausser.... man grenzt die Menge der erlaubten IP-Adressen per firewall-regel ein...
OK, Firewall erstmal aktiviert. Nur funktioniert jetzt Shoutcast nicht mehr :-( (8092, 8090 und 8064 sind die Shoutcast-Ports) Hat dafür jemand eine Erklärung?
iptables -L -n
Chain INPUT (policy ACCEPT) target prot opt source destination ip-xxx.xxx.xxx.xxx all -- 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain ip-xxx.xxx.xxx.xxx (1 references) target prot opt source destination ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:21 ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:25 ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:110 ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:143 ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:465 ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:993 ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:995 ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:8443 ACCEPT udp -- 0.0.0.0/0 xxx.xxx.xxx.xxx udp spt:53 ACCEPT udp -- 0.0.0.0/0 xxx.xxx.xxx.xxx udp spt:123 ACCEPT icmp -- 0.0.0.0/0 xxx.xxx.xxx.xxx ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp spt:25 flags:!0x16/0x02 ACCEPT tcp -- xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx tcp spt:5224 ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:113 ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:8090 ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:8092 ACCEPT tcp -- 0.0.0.0/0 xxx.xxx.xxx.xxx tcp dpt:8064 ACCEPT udp -- 0.0.0.0/0 xxx.xxx.xxx.xxx udp dpt:8092 ACCEPT udp -- 0.0.0.0/0 xxx.xxx.xxx.xxx udp dpt:8090 ACCEPT udp -- 0.0.0.0/0 xxx.xxx.xxx.xxx udp dpt:8064 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spts:0:1023 flags:!0x16/0x02 DROP all -- 0.0.0.0/0 xxx.xxx.xxx.xxx
Gruß René Thiel (Rennkuckuck) mailto:reti@rennkuckuck.de -- http://rennkuckuck.de - Die Rumänien-Seiten http://rtol.de - Dynamische Webseiten mit PHP, mySQL und CSS
Am Freitag, 13. Oktober 2006 18:28 schrieb Ren� Thiel:
Hallo,
Bekannte von mir haben einen Server gemietet und noch weniger Ahnung als ich ;-)
Das ist wie Auto fahren ohne Führerschein. Es geht immer eine gewisse Zeit lang gut (etwa bis zur Hausausfahrt).
Zitat: Aufgrund von DoS-Attacken (Denial of Service) war der Server gestern kaputtgeschossen.
Gegen DoS hilft QoS. Da kann man clevere Dinge machen, z.B. eine SSH-Verbindung nur per Portknocking auf einem freien Port öffnen und dieser dann per QoS-Parametrisierung mehr Priorität geben als den vermutlich "beschossenen" Ports wie HTTP etc. Da sollten wir mal einen LUG-Workshop zu machen :-)
Ohne quantitative Informationen kann man dazu jetzt erstmal nicht viel sagen. Die AGBs mit dem Provider spielen hier auch mit rein, v.a. wenn es auch andere Nutzer betraf und die Anfragen erkennbar bösartig waren. Mehr als abschalten wird ein Provider auch nicht können, aber mehr würde der Servereigentümer im Normalfall auch nicht tun wollen, nehme ich an. Ich bezweifle, dass gerade bei DDoS überhaupt ein wirksamer Schutz ohne Kooperation des Netzbetreibers möglich ist (und der verdient an solchen Attacken).
Zum Server: Apache 2.0.49 auf SuSE Linux 9.0 (i586) cat /proc/version: Linux version 2.6.8-022stab078.1-enterprise (root@kern268.build.sw.ru) (gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 SMP Thu May 11 13:51:08 MSD 2006 Weitere Infos gern auf Anfrage.
Das spielt keine Rolle. Da kann noch so oft "enterprise", "hardened" etc. drinstecken, wenn der Fehler auf Layer 8 liegt, sollte man ihn auch dort beheben. Und wenn es kriminelle Angriffe sind, kann man ohnehin nur bis zu einem bestimmten Grad dagegen vorsorgen. Ist wie mit verschlossenen Haustüren vs. dem Einsatz von Rammböcken.
Josef, paraphrasierend
lug-dd@mailman.schlittermann.de
-
Daniel Leidert -
Frank Gerlach -
Josef Spillner -
Ren� Thiel