Beiträge von Frazze

Kurz überflogen, sieht sehr gut aus!

1. Frage: Soll download nur wegen dirtrav aus sein, oder gibt es noch einen anderen Grund? (Du erwähnst das so oft, daher die Frage)

2. Frage: Was machen die admin-commands
-switch
-blockteam
das ist leider in deiner ReadMe nicht beschrieben?

3. Vorschlag: Du hast dieses Anti-Camp-System, und dort gibt es

//Punishment: 1 = Kill; 2 = Hurting; 3 = Disarming

.
Ich halte zwar nix von Anti-Camp-Systemen, allerdings finde ich die "Hurting" und auch die "Disarming" Funktion sehr interessant.
Du solltest definitiv vesuchen diese zwei Funktionen zu deinen neuen Admin-Commands hinzuzufügen, also z.B.:

/rcon adm hurt:rycoon

und

/rcon adm disarm:rycoon

Denn dann gibt es das für CoD was es schon ewig für CS gibt, nämlich "slapping" (ok, vll. nicht ganz slapping weil beim slappen in CS wird man auch noch durch die Gegend gehauen, aber vll. geht das ja auch per Befehl? )

Ansonsten definitiv eine Nützliche Bereicherung.
Hast du das ganze schon mit dem MAM getestet ob das klappt? Sollte ja eigentlich Problemlos

Zitat von Tremolo4

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.

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.

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

ok. das wissen wir schon. deine regeln würden genauso ohne den Patch von Luigi funktionieren, man müsste nur das Limit/sec. anpassen.

Könntest du vll. noch deine Gedanken zu meinen 2 Posts abgeben? Bezüglich: 1) Dem Eintragen von 127.0.0.1 statt der externen Server IP und 2) meiner Frage wie der ban konkret aussieht? (nur der udp Ziel-Port, oder alle Ports/Protokolle für die IP?)

Ok, wenn der MAM mit 127.0.0.1 läuft, dann sollte er so konfiguriert werden. Genauso sollte dann im iptables Skript die 127.0.0.1 stehen.

#EDIT:

Tut das Skript die IP nur für den jeweiligen CoD4 Server Port blockieren, oder global, sprich einfach die IP für alle Ports/Protokolle?
Beim drüber schauen ist mir das jetzt nicht ganz klar ersichtlich, aber wenn das Skript tatsächlich "global" bannen sollte muss das auch geändert werden, ansonsten ist es ein leichtes euren Server unbrauchbar zu machen indem z.b. gespoofte Abesender-Adresse von eurem DNS Server verwendet werden, dann wird nämlich der eigene DNS Server gebannt. Das selbe ließe sich mit eurer eigenen IP oder ganzen IP-Bereichen machen. Oder dem Activision-Master-Server usw.

Ok, dann wäre das iptables Skript in der Form Sinnlos da (D)DoS weiterhin problemlos möglich ist.
Sinnvoller ist es meiner Meinung nach den Patch von Luigi Auriemma anzuwenden http://aluigi.altervista.org/patches/q3rconz.lpatch , ein rcon mit maximaler Länge (ich glaube bei 24 oder 25 Zeichen ist schluss) und Komplexität und zusätzlich das Anti-Rcon-Flood plugin, dass nach einer fest definierten Anzahl an falschen rcon pw's die IP einfach per itables bannt. Problem gelöst.

Mal abgesehen davon dass das gepostete iptables script auch auf Servern ohne MAM funktioniert, was spricht dagegen einfach das Anti-Rcon-Flood plugin das MasterofLittle (oder so^^) für den MAM gemacht hat zu verwenden? Sollte eigentlich klappen.

#EDIT:

Folgende Zeile halte ich für gefährlich:

Zitat

... 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.

iptables -A Q3R-CHK -p udp -s <server-ip> -j RETURN

Dort sollte nicht die externe bzw.öffentliche IP des eigenen Servers stehen, dann ansonsten kann der Angreifer einfach die Source-Adresse der Pakete so spoofen das eure Server-Adresse als Absender drin steht -> schwupps-die-wupps klappt der DDoS.

Also sollte dort eher 127.0.0.1 oder localhost eingetragen werden! (Ich bin mir gerade nicht sicher ob man dann in der config.cfg des MAMs bei der Server IP auch lieber 127.0.0.1 verwenden muss/sollte, damit es klappt. Theoretisch sollte das aber auch funktionieren, denn über den Port kann der MAM ja immernoch eindeutig den richtigen CoD4 Server anspechen).

Ich verstehe zwar nicht warum man von den guten alten config Dateien weg muss und hin zu einer weit komplexeren Struktur mit Datenbank, Webinterface nur zum konfigurieren usw.
Keep it simple, stupid!

So gut wie jeder Unix service schafft das alles mit normalen configs. Aber ok, ich lass mich überraschen.

was ist den der große teil seines "werks"?

Update:

Zitat

> Indeed it is weird he did never release a fix for the bug
I have sent him a mail just now.

---
Luigi Auriemma
http://aluigi.org

Bin mal gespannt

45 € einmalig für dauerhaft GBit, na dass zahl ich doch gerne :D:D:D:D:D
Viel spass auf jedenfall bie Hetzner, wann gehts los?

Du weißt schon was von dir dann erwartet wird? Mein Netzwerkkabel möge doch bitte in das 1GBit Switch gesteckt werden

Meines Wissens nicht. Du kannst aber das Serverstartscript in etwa so aussehen lassen:

./bin-file +log 0 +rcon_password megageheim +log 1 ...

Somit wird das rcon bei Serverstart in kein Log geschrieben

Soul:

Falls du dich für einen EQ4 von Hetzner entscheidest (sehr gutes Teil btw.) dann lass es mich wissen, weil ich hätte einen EQ4 von Hetzner abzugeben.

Das besondere an meinem: Es ist ein Altvertrag, solche Verträge bekommst heute nicht mehr bei Hetzner, da sind noch 3 zusätzliche IP's dabei umsonst! Heute würdest für jede IP +1 € / Monat extra zahlen! Also melde dich bei mir falls du den EQ4 willst, je nachdem wann du ihn übernehmen würdest wäre er auch noch einige Tage/Wochen bezahlt.

Du darfst/sollst das trotzdem gerne testen Luk je mehr desto besser

Okay, alles klar danke. Ich werde das dann mal so mit den zwei Herren kommunizieren, hoffe das wird was

http://www.opferlamm-clan.de/wbb2/thread.php?threadid=16895&threadview=0&hilight=&hilightuser=0&page=1

Update:

Zitat

Thanks for the clarification, so it is as bad as I thought :\

Yeah, chroot() could work, but it will break so many other things like
admin-mods, web-interfaces for server management and other daemons
that in the end it's not a satisfying solution.

I am really surprised this has not been exploited other than "only"
getting the server config files, as indeed other files on the system
could be way more lucrative...

Regarding the fact that in the past CoD4 servers have been largely
abused to participate in reflected DDoS attacks and Ryan C. Gordon
from icculus.org has released a patch for that issue (he ported the
dedicated servers code to Linux and manages the code I think), do you
think it would be possible to contact him and speak about the
directory traversal bug so he might consider fixing it?
I will try to contact him too, but I am quite sure if you would talk
to him it would have 'another' importance than if only I would

Him having the code at hand it should be more easy to fix than if one
had to do some binary patching (like you had to do with the Windows
version?) I guess.

Ryan's homepage:
http://icculus.org/

But I am sure you two might already know about each others, he porting
a lot of game servers to Linux, you finding bugs and releasing PoC's
and patches

Thanks again for your time,

Alles anzeigen

Seine Antwort:

Zitat

> Ryan C. Gordon from icculus.org has released a patch for that issue
I have checked the dates and the bug has been made public in the far
2006 while this patch has been written in 2011.
are you really really sure that the fixed executable doesn't already
implement a fix for the directory traversal bug?

I have ssen that all the other executables have been released from the
2008:

http://treefort.icculus.org/cod/

it would be really weird that a so critical bug has not been fixed by
Ryan in all this time and with the full source code in his hands.

---
Luigi Auriemma
http://aluigi.org

Alles anzeigen

WICHTIG: Kann jemand der die aktuelle Version 1.7.1 (die mit dem DDoS fix von Ryan / Icculus _IN_ der binary) hat bitte schnell testen ob man immer noch configs runterladen kann? Damit ich Aluigi was sagen kann. Ich hab z.Z. keine CoD4 server am laufen, beobachte das ganze aber schon ne weile da ich bald wieder welche haben werde.

Also: Wer Version 1.7.1 auf linux hat, bitte den q3dirtrav exploit bei sich testen und hier Rückmeldung geben. danke!

Das möchte ich euch nicht vorenthalten (für alle die dachten MAM außerhalb des gameserver Ordners usw.), es ist - wie ich befürchtet hatte - weit weit schlimmer, es wundert mich sehr dass das nicht ausgenützt wird. Aber das liegt scheinbar daran das die ganze Kids alle gar nicht auf die Idee kommen mal außerhalb des gameserver Ordners zu suchen.

Hier zwei Mails:

Zitat

Hey Aluigi,

First of all I want to thank you for the excellent information you
release regarding your exploits and stuff and even more for the fixes
you make public available!

I don't want to steal your precious time, so just a quick question
regarding the q3dirtrav directory traversal exploit:

As there doesn't seem to be any bugfix for the linux server files for
CoD4 servers, I need to know if the directory traversal exploit is
limited to the CoD4 servers' root folder, or if an attacker could also
read files above the gameservers root directory?
In the advisory there is a referrence to
"../../../../../../../etc/passwd" which would mean an attacker could
read any file the server-running user has access too. But while
researching on the internet I could not find any information about
CoD4 servers regarding this specific issue, I only read about getting
any files inside the gameservers root directory structure.

Why I am asking this? I am going to have to setup a CoD4 server for
some people on Linux with sv_download enabled, I also will redirect to
a webserver for fast downloads, but as the client can simply deny
www-redirection he can still use the q3dirtrav exploit.
So is the attacker limited to the gameservers root directory
structure? Because that I can handle by changing config files names,
putting passwords only in startup parameters and disable logging on
startup and re-enable it later so the rcon doesn't show up inside
console_mp.log.
But if the attacker can read though the whole filesystem I would need
to find a more secure solution.

Altogether after a bit of research CoD4 servers seem to be a pain in
the ass to secure properly - my list now consists of 4 specific
exploits / things to fix anyways ...

Thanks for your time Aluigi, I hope I made my question clear, I would
be really glad if you would answer

Best regards,
Leonardo

Alles anzeigen

Antwort:

Zitat

> In the advisory there is a referrence to
> "../../../../../../../etc/passwd"
being a directory traversal bug you can download any file in the system
that can be accessed by the user running the vulnerable software (cod4
server).

so if that user can read /etc/passwd it can be get remotely too like
explained in bug B here:
http://www.securityfocus.com/archive/1/arch…/100/0/threaded

usually people don't talk about this fact because they are interested
only to the server config file of the game ignoring this worst scenario.

maybe chroot can do what you need, I have never tried it but it looks
like it's just its job.

---
Luigi Auriemma
http://aluigi.org

Alles anzeigen

Zum kotzen... muss man jetzt tatsäclich versuchen seine CoD4 server in einer chroot Umgebung laufen zu lassen... das wird so unglaublich viele Probleme mit sich bringen das ich jetzt schon das Kotzen im Quadrat bekomme -.-

setz den sv_base und sv_homepath im start script der server. dann werden die logs nicht mehr im dämlichen versteckten ordner angelegt.

wenn du bestimme gametyps nur auf bestimmten maps hast sollte es eigentlich gehen.

angenommen du spielst immer auf crash S&D und auf shipment TDM dann kannst du doch im /config/maps/ ordner eine .rcon datei anlegen.

z.b: mp_crash.rcon, dort packst du dann den rcon befehlt für deinen spec type rein in die erste zeile, in die zweite zeile packst du einen map restart oder einen fast_restart, je nachdem was nötig ist.
das ganze jetzt eben für jede map in deiner rotation sollte klappen

EDIT: oder sogar noch besser (und komplexer xD), du machst das schon vorrausschauend für die nächste map, also z.b. wenn:
S&D crash wird geladen, die nächste map wird shipment TDM sein. jetzt setzt du bei crash den spec mode welcher auf shipment (der nächsten map) geladen werden soll, er wird auf crash gesetzt aber nicht ausgeführt da kein map restart fold. nun wird shipment geladen und der spacmode aus der crash.rcon sollte geladen werden. einziger hacken hierbei der mir einfällt könnte sein dass wenn du in deiner server.cfg einen spec mode gesetzt hast und diese wird beim map laden ja auch geladen das dann der spec mode aus der server.cfg den aus der crash.rcon dahei wieder überschreibt weil, das müsstest du testen (oder mal gar keinen spec mode setzten in der server.cfg)