Beiträge von Tremolo4

Das kann man ziemlich sicher mit dem logAction-Event abfangen. Bin aber auch zu faul, das zu machen

Wenn ich mich nicht irre, kackt das Plugin total ab, wenn zwei Spieler ohne GUID direkt hintereinander joinen.

genaugenommen ist das problem, dass die leute von gamed!de das modstuff-plugin zwei mal in den plugins-ordner gepackt haben (einmal modstuff.php und modstuff.old.php). der manuadmin lädt eben alle dateien im plugins-ordner und verreckt deswegen. ohne diese doppelte datei würde diese alte version vermutlich trotzdem noch funktionieren.

der MAM betreibt doch kein multi-threading bzw. multi-tasking, oder? beispielsweise werden rcon befehle inklusive ihrer 700ms stream-timeout-zeit hintereinander ausgeführt, und dann erst die nächste log-zeile verarbeitet, richtig? dann sollte es eigentlich keine probleme mit gleichzeitig joinenden spielern, in diesem fall bots ohne guid geben...

ach. doch, während des schreiben ist mir was eingefallen
guck mal in der server-logdatei nach, ob bot10 gejoint ist, bevor bot9 gekickt wurde; ob "J;...;bot9" und "J;...;bot10" vor "Q;...;bot9" eingetragen wurden.
dann sollte man das plugin umschreiben, eventuell mit dem logAction event, und da direkt alle J; zeilen auf eine leere (oder invalide) guid prüfen. dann direkt per rcon die PID, die ja auch in der logzeile steht, kicken.

edit: zur weiteren erläuterung: wenn zwei spieler (oder bots) mit gleicher guid joinen (eine leere guid "" zählt auch als guid), interpretiert der manuadmin das als namensänderung und PID-änderung (!) des ersten spielers in den namen und die PID des zweiten spielers. den erst-gejointen spieler kann man dann nicht mehr kicken, bannen etc. wenn also der manuadmin mit dem kicken der bots nicht hinterherkommt, tritt das beschriebene problem ein.

die meldung bekomme ich auch hin und wieder (selten), kenne keine lösung. passiert häufig, wenn man zwei spiele gleichzeitig laufen lassen will.
ich kann dir aber versprechen, dass es nichts mit dem manuadminmod zu tun hat.

Zitat

Nur wenn man den Patch von Luigi angewandt hat )was ja aber jetzt bereits von dir und mir erwähnt wurde), wenn man den Patch nicht hat, hat man Pech.

jenau.

Zitat

Also danke für das Script, es sieht gut aus

bitteschön

Dennis mysteriös. ich benutze immer Umschalt+Enter, um zeilenumbrüche zu machen und in diesem post hab ich mitten im satz weder enter noch umschalt+enter gedrückt naja egal, ich schreib jetz einfach im quellcode-modus, gefällt mir sowieso besser

sorry bin grad lesefaul.

1) das müsste eigentlich problemlos klappen. ich hab da nur irgendwas im hinterkopf ... könnte sein, dass "lokale" pakete, also loopback oder wie auch immer du es nennen willst, von iptables anders gehandelt werden. müsstest du mal testen. wahrscheinlich geht's so.
2) es werden nur "rcon"-udp-pakete "gebannt".

alle meine angaben sind übrigens ohne gewähr

edit: wo kommen eigentlich die ganzen zeilenumbrüche in meinen posts her?!

edit2: es werden nur rcon-pakete, allerdings alle, die an die angegebenen ports gehen (nicht "pro server") und von einer gebannten IP (source port egal) kommen, gedroppt.

edit3: außerdem: das einzige problem, was beim whitelisten der externen server-ip auftreten könnte, ist, dass der cod4-server bei extrem hoher flood-rate anfängt zu laggen, weil er mit dem paket-parsen nicht hinterherkommt. das kann ich mir aber beim besten willen nicht vorstellen.

voraussetzung dafür, dass die regeln sinnvoll sind, ist natürlich das
anwenden des rcon-limit-entfernungs-patches von aluigi. sorry, dass ichs
nicht explizit erwähnt hab. und das "whitelisten" der server-ip ist
eben für den manuadminmod gedacht, da man den sonst genau so (sogar noch
einfacher) aussperren kann wie auf servern ohne den genannten patch.

also nochmal: meine regeln sind dazu gedacht, rcon brute-forcing zu verhindern, wenn man den q3rconz patch von aluigi verwendet.

edit: zur klarheit: diese regeln sind dazu gedacht, rcon-bruteforcing zu verhindern, wenn man den q3rconz-patch von aluigi verwendet. sie lassen sich in leicht veränderter form auch zum abwehren der getstatus-ddos attacken verwenden, allerdings sollte dann die zeile mit der <server-ip> (siehe unten) weggelassen werden.

ich hab mir die geposteten lösungen nicht genau angeguckt, sorry, aber ich hab mal die regeln, die ich erfolgreich zum abwehren der ddos attacken verwende, etwas umgewandelt.
das ganze ist ungetestet, müsste aber so klappen. edit: Luk hats getestet, funktioniert
zur funktionsweise:
alle udp-pakete, die an die gameserver-ports gehen, kommen in die Q3R-CHK chain. dort wird zunächst geprüft ob die absender-adresse die eigene IP ist (achtung platzhalter), also z.b manuadmin. diese pakete werden dann immer durchgelassen. dann erst wird überprüft ob es sich um ein paket mit dem string "rcon" beginnend an 32ster-stelle (hinter dem header und den 4 FF bytes) handelt. wenn ja, wird gecheckt ob sich die absender-IP schon in der liste "rcon-flooders" (die listen verwaltet das recent-modul) befindet und der last-received timestamp dieser IP nicht "älter" als 10 sekunden ist. wenn ja, wird dieser timestamp aktualisiert (auf *jetzt* gesetzt) und das paket wird gedroppt. ansonsten geht das paket weiter zum hashlimit-modul, welches dafür sorgt, dass die absender-IPs, welche zu oft (mehr als 5 pro sekunde) pakete an denselben zielport (gameserverport) senden (auch gespoofte logischerweise), in die liste "rcon-flooders" kommen (durch -j Q3R-BLOCK).
genug gelabert, probiert's aus wenn ihr wollt
ihr solltet dann eure (externe) <server-ip> und eure gameserver-ports (ganz unten) eintragen.

#!/bin/sh




iptables -N Q3R-BLOCK
iptables -A Q3R-BLOCK -m recent --set --name rcon-flooders -j DROP




iptables -N Q3R-CHK
iptables -A Q3R-CHK -p udp -s <server-ip> -j RETURN
iptables -A Q3R-CHK -p udp -m string ! --string "rcon" --algo bm --from 32 --to 33 -j RETURN
iptables -A Q3R-CHK -m recent --update --name rcon-flooders --seconds 10 --hitcount 1 -j DROP
iptables -A Q3R-CHK -m hashlimit --hashlimit-mode srcip,dstport --hashlimit-name rcon-limit --hashlimit-above 5/second -j Q3R-BLOCK




# look at all packets going to gameservers
iptables -A INPUT -p udp -m multiport --dports 21337,28960:28969,23456 -j Q3R-CHK




exit

If you use the patch linked by belstgut make sure to get some firewall rules to prevent rcon brute-forcing, as you are vulnerable to that then.
I have no idea how to do that on a windows server though.

Zitat von Luk

Wie ich gestern erfahren musste, kann es manchmal auch einfach an der Config liegen XD (Macht keinen Sinn, ist aber so... dachte zumindest mein RotU Server).

Oh ja.

danke, da ist bei mir wohl irgendne sicherung durchgebrannt

weiß nicht, ob das problem noch aktuell ist, aber als allererstes würd
ich mal die cpu-priorität von den gameserver-prozessen hochschrauben:

# chrt -r -p <priorität> <PID>

als priorität z.b 40. die PID ist eben die prozess-ID des jeweiligen
gameserver-prozesses. wenn du mindestens so viele gameserver laufen
lässt, wie du kerne hast, würd ich sicherheitshalber noch mit taskset dafür sorgen, dass die gameserver nicht u.U die ganze leistung fressen (also einen kern "freilassen"), auch wenn das eigentlich nicht vorkommen sollte.

außerdem auf jeden fall das console-log mit set logfile 0 ausstellen, es sei denn du brauchst es (MAM braucht es nicht).

weiterhin kann ich nur bestätigen, dass server4you kein guter Hoster
ist. hab schon von mehreren leuten gehört und selbst bemerkt, dass die
performance bezogen auf lags ziemlich dürftig ist.

hetzner kann ich indes nur empfehlen.

hat beides seine vor- und nachteile würd ich sagen
wär natürlich super wenn der exploit jetzt semi-offiziell (activision hatte auch mit dem query-limiting patch nix mehr zu tun) gefixt würde.
seit n paar tagen hab ich dafür schon nen linux-fix, von jemandem, der richtig viel ahnung von assembler etc. hat.
besagte person hat mich allerdings gebeten, es nicht im internet zu verbreiten (der q3dirtrav-fix ist nur ein kleiner teil von seinem werk).
falls sich ryan also nicht darum kümmert, werd ich ihn nochmal drängen, wenigstens den fix zu veröffentlichen

wenn man das console log nicht unbedingt braucht würd ich es mit set logfile 0 ausstellen. manuadmin braucht das schließlich nicht. edit: das verbessert auch die performance, denn der server lagt bei einem I/O-block (was btw ziemlich bescheiden programmiert ist).
wenn doch, kann man mit einem beliebigen binär-fähigen text-editor (notepad++, programmers notepad etc.) in der executable einfach nach "console_mp.log" suchen und dort einen anderen, gleichlangen namen hinschreiben.
z.B. "bu3mjc8giw.log". um zu verhindern, dass jemand dann einfach die cod4_lnxded-bin runterlädt, sollte man die ebenfalls umbenennen ^^.

steht das in den AGBs? ;D

ich verspreche, dass durch diese modifizierung keine unerwarteten nebeneffekte auftreten.

ist eigentlich nur ein einzeiler.. quick-and-dirty

hab dir meine veränderte pingkicker.php als zip angehängt. einfach damit die vorhandene pingkicker.php im adminmod/plugins ordner ersetzen und manuadmin neustarten.
die veränderung sorgt dafür, dass alle spieler, die nicht in der "default"-gruppe sind, nicht vom pingkicker gecheckt werden.

ja, über die skriptsprache kann man leider gar nicht darauf zugreifen...
das download-system der cod engine ist, meine ich, etwas anders als beim original quake3, weswegen sich ein assembly fix schwieriger gestaltet als bei anderen quake3 games (schließlich ist der quake3 source code öffentlich).

dass man den server mit cl_wwwdownload zum abstürzen bringen kann, wäre mir neu.
aber wenn man den exploit mit cl_wwwdownload 1 benutzt, funktioniert es nicht, und man fliegt raus (impure client detected).

ich verfolge die cod linux mailing list von icculus und da hat schon mal jemand gefragt, ob er das nicht fixen könnte; da hat er iirc nicht geantwortet.
auch sonst schreibt er da recht wenig (ist ja auch nicht seine pflicht); den ddos fix könnte man ausnahme nennen.

für windows gibt es einen fix von aluigi selbst.

es hat auch jemand einen fix für die linux-version von enemy territory gemacht: http://s4ndmod.com/phpBB3/viewtopic.php?f=34&t=53
scheinbar hast du das auch schon gefunden, Frazze ;D

also bis jemand sich die mühe gemacht hat, das mit nem disassembler für cod4 linux zu fixen, müssen wir uns wohl mit nem log-scanner begnügen.
außerdem kann man auf punkbuster-geschützten servern einfach die client-dvar cl_wwwdownload überprüfen lassen.
man könnte auch den laufenden mod (nur auf gemoddeten servern sollte schließlich sv_allowdownload an sein) um eine client-dvar-set schleife erweitern (per gsc).
diese cvar-begrenzung sollte zumindest die gröbsten script kiddies aufhalten.

achja: leuten, die eine lösung mit chroot in betracht ziehen, kann ich jailkit als stichwort geben.

Folgende Dateien wurden seit 0.11.3 gepatcht, also sind bei 0.11.4 anders:

adminmod\daemon.php
adminmod\classes\mod.class.php
adminmod\internals\functions.php
adminmod\languages\de\main.lng
adminmod\languages\en\main.lng
adminmod\plugins\basiccommands.php
adminmod\plugins\modstuff.php
adminmod\plugins\weaponrestrictions.php

Dazu kommen natürlich noch die MW2-Standard-Config-Dateien...

(Für den unwahrscheinlichen Fall einer CRC32-Kollision berichtigt mich bitte )