Linux Server DDOs Fix 1.7.1

Hallo,

habe ich in der server.cfg drin, nach was für einem Eintrag muss ich da genau Ausschau halten ?

In der Datei steht enorm viel drin

Benutz Omnigenus Testtool

thx @ CartmanDSL







(Jotti Scan)

hmmm,

was genau willst Du mir mit Deinem beitrag sagen ?

habe das Tool runtergeladen und gestartet, dann IP und Port eingetragen und auf Enter, es kommt dann ständig ein Eintrag...

Was genau muss ich da machen ?

Danke für Hilfe



Edit:
Will doch nur dass dieser massige Upload aufhört

Wenn der Fix funktioniert kommt die Antwort nur einige mal (10, 20 - hab nicht nachgesehen was Luigi als Schmerzgrenze eingestellt hat) und dann antwortet der Server nicht mehr.

Wenn du 100+ Antworten bekommst funktioniert dein Fix nicht.

Ok,

habe das jetzt mal bei meinen beiden COD4 Servern getestet.

Bei dem einen kommt irgendwann die Meldung:

ERROR...something went wrong here (wrong IP or socket timeout?)
Press any key now...

Dieser läuft ohne Mod


Bei dem anderen (läuft mit promodlive211) kommt diese Meldung nicht

Hat das was zu bedeuten ?

Zitat:

ERROR...something went wrong here (wrong IP or socket timeout?)

Da ist die Falle angeschlagen, und er ignoriert jetzt deine Anfragen. Auf dem Server funktioniert es.

Auf dem anderen Server funktioniert es anscheinend nicht wenn du fortlaufend Antworten bekommst. An Promod liegt es eher nicht, das ist einige Ebenen darüber und hat erst einmal damit nichts zu tun.

Neustart? Sind es verschiedene Cod4_lnxded-bin für die jeweiligen Server?

Nein, habe die Datei bei beiden hochgeladen und umbenannt.

Dann den Eintrag in die server.cfg (auch von promod) und dann neugestartet

Halt den Promod an, lade nochmal neu die cod4_lnxded-bin hoch, Server starten, nochmal testen.

Hab ich gemacht, sowohl mit und ohne den Mod.... aber er zieht die tests vollgas durch


In der server.cfg sind die Einträge vorhanden.


Edit:
Habe die Nachricht noch nicht abgeschickt gehabt und den Server nun nochmal mit Mod gestartet und nun bricht er auch ab


Komisch, aber scheint nun zu klappen


Edit2:

Gerade nochmal getetestet und zieht nun wieder voll durch also bricht nicht mehr ab.... irgendwas passt doch da nicht

Edit3:
Nun bricht er wieder ab gibts doch nicht

So, habe heute eine Mail bekommen mit dem Betreff:

Subject: UDP Flood Attack From 84.200.xxx.xx

Der Fix geht nun schon wieder nicht bei mir.

Hat jemand einen 100%ig laufenden Fix bzw. ein fertiges Image wo das ganze schon drin läuft ?

Grüße und einen letzten schönen Weihnachtsfeiertag

Hallo,

wir wurde heute ebenfalls von unserem Serverhoster angeschrieben, da wir jemanden geddost haben.

Fanden schnell raus, dass es der Query-Flood-Exploit von CoD4 ist.

Das Problem habe wir durch folgende zwei Firewall-Einträge behoben:

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

Diese Zeilen habe ich in diversen Foren gefunden, doch leider versteh ich fast nix davon x_X

Ich verstehe nur, dass wenn der string "getstatus" über UPD in einem Zeitraum (welcher genau nun?) zu oft (wie oft genau?) gesendet wird, der Absender für eine Zeitlang (wie lange?) geblockt wird.

Mir wäre es recht, dass wenn der Typ den Query "gestatus" 5 mal pro Sekunde sendet, für 5 Minuten komplett geblockt wird.

Nur habe ich kein Plan wie =&

hallo,
ich hab den fix hochgeladen und die einstellungen in die startseq. mit eingebaut
und nach dem was in die logdatei geschrieben wird geht es...
dabei muss man es nicht in die server.cfg schreiben...
hab es so mit 4 cod4 servern gemacht und scheint zu klappen...
laufen alle mit einem mod...

den ersten befehl sollte man aber dann mal wieder abschallten da die log nach 12std schon 480mb hat...

"...... +set sv_queryIgnoreDebug 1 +set sv_queryIgnoreMegs 1 +set sv_queryIgnoreTime 2 +set sv_queryBounceIgnoreTime 1200"

Hi Murphy,

wie genau hast Du dann den Startbefehl ?

na die befehle einfach angehängt... etwa so

./cod4_Inxded +set fs_game mods/xxxx +set fs_basepath /home/cod/cod4 +set fs_homepath /home/cod/cod4 +set loc_language 2 +set dedicated 2 +set sv_punkbuster 1 +exec server.cfg +map_rotate +set net_port 27015 +set sv_queryIgnoreDebug 1 +set sv_queryIgnoreMegs 1 +set sv_queryIgnoreTime 2 +set sv_queryBounceIgnoreTime 1200

in der logdatei sieht es dann so aus...

QUERY LIMIT: (300) Allowing query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Allowing query from 199.204.18.162
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Allowing query from 72.8.190.61
QUERY LIMIT: (300) Allowing query from 74.84.221.75
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 72.8.190.61
QUERY LIMIT: (300) Blocking query from 72.8.190.61
QUERY LIMIT: (300) Blocking query from 199.204.18.162
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 199.204.18.162
QUERY LIMIT: (300) Blocking query from 74.84.221.75
QUERY LIMIT: (300) Blocking query from 199.204.18.162
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 199.204.18.162
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 72.8.190.61
QUERY LIMIT: (300) Blocking query from 72.8.190.61
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 74.84.221.75
QUERY LIMIT: (300) Blocking query from 199.204.18.162
QUERY LIMIT: (300) Blocking query from 199.204.18.162
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 72.8.190.61
QUERY LIMIT: (300) Blocking query from 199.204.18.162
QUERY LIMIT: (300) Blocking query from 72.8.190.61
QUERY LIMIT: (300) Blocking query from 212.223.66.85
QUERY LIMIT: (300) Blocking query from 199.204.18.162
...

leider frisst die log dann viel speicher... 3std = 450.xxx.xxx kb

Da ich seit einiger Zeit ebenfalls mit diesen Attacken zu tun habe, bin der beschriebenen Anweisung gefolgt. Der Traffic ist dramatisch gesunken. Allerdings steigt auch das Volumen der console_mp dramatisch an. Von einen Tag auf den anderen ist sie von ca. 40 MB auf über 2 GB gewachsen.
Lesen kann ich den Inhalt nun wohl nicht mehr. Selbst nach dem Download auf den heimischen PC lässt sich die Datei nicht öffnen, weil einfach zu groß.
----
Während ich dies hier gerade schreibe, sehe ich die Start-Shell von Murphy. Die rot markierten Einträge habe ich allerdings nicht. Macht es Sinn? Oder sollte man diese Befehle auch eintragen. Allerdings stand in der Installationsanleitung des Patches nichts davon.

Beste Grüße

Hallo Hauptmann Kloss,
wenn du den befehl "set sv_queryIgnoreDebug 1" auf 0 setzt werden die query limit logs nicht mehr in deine console.log geschrieben...
dann werden nur die standart cod infos eingetragen und die log ist wieder normalgross...
das ist nur zum testen gut ob es auch fuktioniert...


ob du die befehle in die server.cfg oder in die start-shell schreibst ist eigentlich egal....
ich wollte nur sicher gehen das es auch läuft egal mit welchem mod ich den server starte...
ohne das ich es in jeder server.cfg einbauen muss

Besten Dank Murphy,

jetzt haut auch der Traffic wieder hin. Habe den Befehl auf 0 gesetzt und die Datei verhält sich normal.
Andererseits wäre doch der Befehl in der Firewall nicht besser? Dann sind gleichzeitig alle CoD-Server abgesichert.
---

Im übrigen habe ich mal einige log-Dateien vom System durchgeschaut. Ist schon interessant wer von wo versucht in das System einzudringen. Selbst der eigene Hoster versucht es.

---

Naja. Jedanfalls besten Dank Leute für die gute Arbeit. Ich wünsche euch allen einen guten Rutsch ins neue Jahr.

Gruß
Thomas

frohes neues jahr!

Zitat:

Original von Hauptmann Kloss

Andererseits wäre doch der Befehl in der Firewall nicht besser? Dann sind gleichzeitig alle CoD-Server abgesichert.
---

ja die zeilen in iptables hatte ich getestet....

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

aber die log von den server hat weiterhin fleissig blocken müssen...
und die log wächst bedrohlich...

hab dann folgendes in die iptablets geschrieben... (oder besser beides)

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

und es erscheint nicht eine ip die geblockt werden muss...
die console_mp.log wird nun auch nicht mehr so rasend schnell grösser...

also so sollte es gehen... werde mal sehen was in den nächsten tagen passiert...

Hi Murphy,

ich muss das jetzt auch mal ausprobieren.
Ich hab leider immer noch das Problem mit dem Traffic obwohl der Block drin ist, im Startbefehl die Zeilen sind und der Block hin und wieder geht

Ich verzweifel bald.....

Wie und wo genau muss ich dies mit der iptables Geschichte machen ?


Und wie würde ich das wieder rausbekommen sollte es zu problemen kommen ?



Wünsche euch allen auch ein Frohes Neues Jahr

habe den Eintrag nun über ssh eingegeben.
Seitdem hab ich in HLSW in regelmäßigen Abständen Timeouts....