Linux Server DDOs Fix 1.7.1

hi exilim,

wenn du die einträge wieder löschen willst einfach die zeilen nochmal mit iptables -D INPUT ...... eingeben.

ja das in hlsw jetzt hin und wieder timeout kommt ist klar... da hlsw auch udp abfragen macht... ich hab in "einstellungn/verschiedenes" die aktualisierungsrate runtergeschaubt... (500)
dann geht es wieder... hängt aber auch von der version ab die benutzt wird...
die 1.4.0.2 + 1.4.0.3 gehen noch die 1.4.0.5 geht garnicht mehr... ist aber auch noch beta....

aber damit muss man dann leben das alle udp anfragen eingeschränkt werden...
besser als die beschwerden über die ddos atacken und den traffic verbrauch

mal allgemein zur info...
nur der patch 1.7.1 hat zwar geblockt wie man in der liste oben sieht...
aber der traffic verbrauch war immer noch sehr hoch...(in 6std ca. 8bg)
mit dem iptables eintrag ist er nun weit unten...(in 6std ca 3gb)

und die console_mp.log zeigt nur noch einträge die erlaubt werden... keine geblockten mehr dabei...

ok danke

Also mein Traffic Verbrauch ist auch nach unten.... perfekt dann lass ich das mal so

Gibt es auch nen Fix für Windows??? Hatte heute ne nette Mail von meinem Server Anbieter... Auf dem Server Sind nur COD4 Server am laufen sonst nix.

"Subject: UDP Flood Attack From xxx.xxx.xxx Our network has been repeatedly attacked from this above marked IP with
UDP attacks. Please take actions to secure this machine, and prevent it
from attacking us (or anyone else). Attached are some truncated logs from
when we were under an attack from this IP."

hi,

schau mal hier: Windows Server DDoS Fix
da wurde es schon mal angesprochen...
es ist immer nur ein kompromiss die attacken zu unterbinden da nicht nur die bösen udp anfragen stellen.
durch die einschränkung der zu beantwortenden anfragen wird nicht alles geblockt...
aber es legt nicht mehr den anderen rechner lahm...
da server unter windows nicht so verbreitet sind wird da wohl auch nicht so geforscht...

wer ein sicheres system haben will muss den i-net stecker ziehen ....
kleiner schertz....

Zitat:

Original von Murphy
hi,

schau mal hier: Windows Server DDoS Fix
da wurde es schon mal angesprochen...

Danke für die Antwort nur bringt mir das nix, ich werd mir bestimmt net irgend welche dll Dateien aus irgend einem Russischem Forum auf meinen Root hauen... Gibt es keine andere Lösung??? Am besten via Firewall.

ja ich wäre da auch nicht so angetan von den dll...
aber sie sollen ja laufen... nur ob es da hintertüren gibt ist die frage...
wenn du aber den server isoliers vom system sollte da auch nicht viel passieren...

wie die firewall von windows dazu gebracht wird udp abfragen mit mehr als 10/sec von einer ip zu filtern weiss ich so auch nicht...

fragen wir mal google und so...

Gibts auch ne möglichkeit das mit den Cracked Serverfiles zu machen?

Wenn ich das mit den Iptables eingeben will kommt bei mir immer folgender fehler

Kann mir jemand sagen was ich falsch mache?

______________________________________________________

Edit by bangingbernie:Nicht Dein Ernst?! Oder? User gesperrt.

Gibt es diesen Fix auch für COD2 ?

Wieso ist denn COD überhaupt so anfällig ?!

für cod2 ist mir nicht bekannt...
der bug ist in allen quacke 3 basierenden eng.
zb. cs und so... aber da wurde schon vor jahren die tür zugemacht...

mit den iptables einstellungen kannste alle codx schützen... wenn sie auf linux laufen.

Das ist ja das merkwürdige... habe folgende Befehle eingetragen aber es funktioniert nicht


iptables -A INPUT -p UDP -m length --length 42 -m recent --set --name getstatus_cod
iptables -A INPUT -p UDP -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP


iptables -A INPUT -p UDP -m length --length 41:45 -m recent --set --name getstatus_cod
iptables -A INPUT -p UDP -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP


Sobald ich den COD2 Server starte und er online ist gehts wieder los mit dem Outgoing Traffic

geb mal iptables -L -v -n in putty ein und schau ob das auch geht...
es werden ja nicht alle udp abfragen blokiert...

sollte dann so aussehen...

> iptables -L -v -n
Chain INPUT (policy ACCEPT 84M packets, 6187M bytes)
pkts bytes target prot opt in out source destination
842M 35G udp -- * * 0.0.0.0/0 0.0.0.0/0 length 42 recent: SET name: getstatus_cod side: source
2881M 123G DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 STRING match "getstatus" ALGO name bm TO 65535 recent: UPDATE seconds: 1 hit_count: 20 name: getstatus_cod side: source
36M 1540M udp -- * * 0.0.0.0/0 0.0.0.0/0 length 41:45 recent: SET name: getstatus_cod side: source
1748K 73M DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 STRING match "getstatus" ALGO name bm TO 65535 recent: UPDATE seconds: 1 hit_count: 20 name: getstatus_cod side: source

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 103M packets, 19G bytes)
pkts bytes target prot opt in out source destination

sieht bei mir so aus :

Chain INPUT (policy ACCEPT 10M packets, 472M bytes)
pkts bytes target prot opt in out source destination
12963 976K fail2ban-proftpd tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 21,20,990,989
1534K 1961M fail2ban-ssh tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22
5374 226K udp -- * * 0.0.0.0/0 0.0.0.0/0 length 42 recent: SET name: getstatus_cod side: source
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 STRING match "getstatus" ALGO name bm TO 65535 recent: UPDATE seconds: 1 hit_count: 20 name: getstatus_cod side: source
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 STRING match "getstatus" ALGO name bm TO 65535 recent: UPDATE seconds: 1 hit_count: 20 name: getstatus_cod side: source
950 39900 udp -- * * 0.0.0.0/0 0.0.0.0/0 length 42 recent: SET name: getstatus_cod side: source

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 598K packets, 72M bytes)
pkts bytes target prot opt in out source destination

Chain fail2ban-proftpd (1 references)
pkts bytes target prot opt in out source destination
12963 976K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0

Chain fail2ban-ssh (1 references)
pkts bytes target prot opt in out source destination
1496K 1959M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0






Der COD2 Server ist im Moment aus. Soll ich ihn nochmal anschalten und wenn der Outgoing Traffic wieder so krass hoch ist nochmal den Befehl ausführen ?

bei dir scheint nur der erste befehl zu laufen... und das mit fehler... DROP zeigt ja nix an.


geb die zeilen mal nacheinander in putty ein...

1. iptables -A INPUT -p UDP -m length --length 42 -m recent --set --name getstatus_cod

2. iptables -A INPUT -p UDP -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP

3. iptables -A INPUT -p UDP -m length --length 41:45 -m recent --set --name getstatus_cod

4. iptables -A INPUT -p UDP -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP

dann nach ner minute mit "iptables -L -v -n" das ergebnis abfragen....

es sollten in allen zeilen werte angezeigt werden.. nur du hast anscheinend die die zeile 1 zweimal eingegeben... denn die werte für zeile 3 fehlen...

ach und proftp würde ich nur anschalten wenn es gebraucht wird und dann wieder ausmachen ist eine feine sicherheitslücke...
besser man nimmt "winscp" ... aber das nur am rande

Gib mal bitte
modinfo xt_string ipt_string
ein.

Jetzt kommt das hier:

Chain INPUT (policy ACCEPT 59275 packets, 5948K bytes)
pkts bytes target prot opt in out source destination
14483 1068K fail2ban-proftpd tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 21,20,990,989
1538K 1961M fail2ban-ssh tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22
7122 299K udp -- * * 0.0.0.0/0 0.0.0.0/0 length 42 recent: SET name: getstatus_cod side: source
20 850 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 STRING match "getstatus" ALGO name bm TO 65535 recent: UPDATE seconds: 1 hit_count: 20 name: getstatus_cod side: source
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 STRING match "getstatus" ALGO name bm TO 65535 recent: UPDATE seconds: 1 hit_count: 20 name: getstatus_cod side: source
2688 113K udp -- * * 0.0.0.0/0 0.0.0.0/0 length 42 recent: SET name: getstatus_cod side: source
0 0 udp -- * * 0.0.0.0/0 0.0.0.0/0 length 42 recent: SET name: getstatus_cod side: source
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 STRING match "getstatus" ALGO name bm TO 65535 recent: UPDATE seconds: 1 hit_count: 20 name: getstatus_cod side: source
19871 837K udp -- * * 0.0.0.0/0 0.0.0.0/0 length 41:45 recent: SET name: getstatus_cod side: source
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 STRING match "getstatus" ALGO name bm TO 65535 recent: UPDATE seconds: 1 hit_count: 20 name: getstatus_cod side: source

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 103K packets, 12M bytes)
pkts bytes target prot opt in out source destination

Chain fail2ban-proftpd (1 references)
pkts bytes target prot opt in out source destination
14483 1068K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0

Chain fail2ban-ssh (1 references)
pkts bytes target prot opt in out source destination
1500K 1959M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0

Zitat:

Original von Kellerkind
Gib mal bitte
modinfo xt_string ipt_string
ein.

für was genau ist das gut ?

irgendwie ist bei dir zu oft das gleiche ....
solltest mal alle wieder entf. und neu machen...
den cod server musste dann starten um zu sehen ob es auch geblockt wird...

Also geblockt wird es nun

Ich glaub ich entfern da lieber nichts mehr *g*

ja fein... wenn der traffic sich verbessert sollte es so bleiben
bei unserem root haben sie aufgegeben... die geblockten udp packete
sind nun wieder fast auf null... dauerte zwar 3-4 wochen bis die gerafft haben
das hier nix mehr geht... aber nun ist ruhe...