Quake 3 dedicated server auf sarge?

[joshi]

hallo!

mit meinem 1. post wende ich mich gleich mit einem größeren problem an euch:
ich hab nen kleinen rooty mit sarge, und will damit nen privaten q3ded server für mich und meine kumpels installieren.

als erstes hab ich mal mit apt-get update + upgrade das system auf den neuesten stand gebracht.
dann die pak.0 datei rauf und das pointrelease rauf.
aber ein paar konzeptionelle fragen hab ich:
1. ist es ok, den server her und so upzudaten, oder gibt es da gewisse pakete o.ä., die ich nicht auf den neuesten stand bringen sollte (bekannte bugs, usw)?

2. der server soll nicht immer laufen, sondern nur z.b. jeden freitag oder so. deshalb will ich den bei ankündigung in meinem forum starten. ist es besser, mich da als root einzuloggen und den server zu starten, oder sollte ich mir einen eigenen user zulegen, mit dem ich das mache?

3. falls ich bei 2. den normalen user anlege, sollte ich den dann jailen?

und last but not least: wer kann mir genauere infos geben, wie ich den server am besten administrieren kann? gibt es da remotetools oder sowas? ich hab schon lange im netz gesucht, aber nix richtiges gefunden...

vielen vielen dank derweil schon mal...

mfg
joshi

ps.: ich würde euch bitten, die antworten anfängergerecht zu halten - bin neuling... danke

[Joghurt]

Hallo und Willkommen im Forum!

1. ist es ok, den server her und so upzudaten, oder gibt es da gewisse pakete o.ä., die ich nicht auf den neuesten stand bringen sollte (bekannte bugs, usw)?

Das "stable" in Debian heisst genau das, nämlich, dass sich nach Updates alles genauso verhält wie vorher, Updates spielen nur noch Bugfixes ein, die u.U. zurückportiert wurden, damit garantiert ist, dass sich nichts ändert (außer, dass die Sicherheitslücke nicht mehr da ist). Du kannst/solltest regelmäßige Sicherheitsupdates machen, ohne dass irgendwas hakt.
(Natürlich kann es sein, dass ein Update des Quake-Servers neue Bibliotheken verlangt, aber von Seiten der Debianupdates gibt es keine Probleme)

oder sollte ich mir einen eigenen user zulegen, mit dem ich das mache?

Eigener User ist besser.

3. falls ich bei 2. den normalen user anlege, sollte ich den dann jailen?

Jupp. Denn wenn es mal eine Sicherheitslücke geben sollte, kann derjenige, der sie ausnutzt, nur dass, was der Server kann, ist also auch im Jail (natürlich kann man das evtl. umgehen (Stichwort:Kernelbugs), aber es ist eine weitere Hürde)
Aus demselben Grund sollte ein Server niemals als root laufen.

und last but not least: wer kann mir genauere infos geben, wie ich den server am besten administrieren kann?

Meinst du den Gameserver oder den Computer? Als Remotetool für den Compi gibt es webmin

ps.: ich würde euch bitten, die antworten anfängergerecht zu halten - bin neuling... danke

Neulinge waren wir alle mal, ich empfehle die Lektüre des Anwenderhandbuchs, um sich in Linux einzuarbeiten.

http://www.debiananwenderhandbuch.de

[joshi]

Das "stable" in Debian heisst genau das, nämlich, dass sich nach Updates alles genauso verhält wie vorher, Updates spielen nur noch Bugfixes ein, die u.U. zurückportiert wurden, damit garantiert ist, dass sich nichts ändert (außer, dass die Sicherheitslücke nicht mehr da ist). Du kannst/solltest regelmäßige Sicherheitsupdates machen, ohne dass irgendwas hakt.

astrein genau das wollte ich hören

Jupp. Denn wenn es mal eine Sicherheitslücke geben sollte, kann derjenige, der sie ausnutzt, nur dass, was der Server kann, ist also auch im Jail...

wie mach ich das am besten? ich erstelle eine gruppe, erstelle einen user in der gruppe und dann steh ich schon wieder an. wo kann ich das jailen einstellen?

Meinst du den Gameserver oder den Computer? Als Remotetool für den Compi gibt es webmin

nun, für webmin müsste ich wieder nen webserver installieren, und das trau ich mir aus securitytechnischer hinsicht noch nicht zu. ausserdem will ich in meiner noch aus DOS-zeiten geliebten shell ordentlich fit sein, ich klicke eh schon genug rum den ganzen tag

http://www.debiananwenderhandbuch.de

danke! bin gestern eh schon über den link gestoplert, aber das war auf ~4.00, da wollt ich nur noch in die kiste *gg*

prinzipiell möchte ich gerne einen normalen user anlegen, der sich (und nur der) per ssh einloggen kann. der soll dann aber gar nix können ausser su. mal eine andere frage:
kann ich mich mit diesem dummyuser einloggen und den benutzer wechseln? also zu einem, der ganz normal befehle ausführen kann gemäß seinen rechten und q3 und ts starten kann?

hui, ich weiss, das sind einige fragen - und ich hoffe, dass ihr versteht, was ich meine *g*

vielen dank
joshi

[oli_f]

salü

Also wenn ich dich richtig verstehe, logst du dich jeweils als root per ssh ein. Das würde ich dir abraten!

Mit "adduser <name>" kannst du einen neuen Benutzer anlegen, mit dem logst du dich ein und kannst danach, nur wenn's unbedingt nötig ist, mit "su" zum root werden.

Benutzer wechseln geht einfach: "su <name des Benutzers>"

Ich würde mir einen Benutzer anlegen für den täglichen Gebrauch, einen unter dem der Quake Server läuft (und der sonst möglichst keine Rechte hat) und den root nur brauchen wenns nötig ist (configs ändern, daemons starten usw.)

Viel spass

PS: Wenn du nicht mehr als root einlogst würde ich es gerade verbieten: in /etc/ssh/sshd_config sollte eine Option "allow root login" oder ähnlich zu finden sein.

[Joghurt]

prinzipiell möchte ich gerne einen normalen user anlegen, der sich (und nur der) per ssh einloggen kann. der soll dann aber gar nix können ausser su. mal eine andere frage:
kann ich mich mit diesem dummyuser einloggen und den benutzer wechseln? also zu einem, der ganz normal befehle ausführen kann gemäß seinen rechten und q3 und ts starten kann?

Wenn der Benutzer nur die Möglichkeit hat, mit su zu wechseln, ist er ziemlich sinnlos. Wofür soll der Benutzer denn gut sein? Falls du Freunden einen Account geben möchtest, mit dem sie dann den Server starten können, lies dir mal Infos zu restricted shells / rbash durch.

Gerade als Anfänger würde ich dir raten, zu beschreiben, welches Problem du lösen wilst, und nicht danach fragst, wie du die Problemlösung, die du dir ausgedacht hast, realisieren kannst; meistens gehen die Sachen nämlich immer etwas anders/leichter als man denkt. Natürlich solltest du deine Idee auch mitposten.

[joshi]

Gerade als Anfänger würde ich dir raten, zu beschreiben, welches Problem du lösen wilst, und nicht danach fragst, wie du die Problemlösung, die du dir ausgedacht hast, realisieren kannst; meistens gehen die Sachen nämlich immer etwas anders/leichter als man denkt. Natürlich solltest du deine Idee auch mitposten.

*ggg* ok. mach ich...

ich will folgendes:
einen kleinen quake3server mit teamspeak, da einige leute probleme haben mit skype und onlinegames simultan. dann möchte ich, wenn ich mal noch ein bißchen bandbreite übrig habe, meinen streamingserver für mich und vlt. 1-3 leute laufen lassen.

ich möchte einen user anlegen (root login unterbunden), mit dem ich mich dann einloggen kann und mich dann aufstufe zum su. somit müsste ein etwaiger eindringling schon mal 2 user und passwörter knacken. falls es nun meinen torwächter-user irgendwie knackt, dann soll der eben gar nix dürfen (kein wget von irgendwelchen dateien, kein editor zum scripten, kein gcc zum kompilieren, um ihm komplett die hände zu binden, falls er wirklich zugang zum system hat. ich glaub, da bin ich vom denkansatz her net so schlecht, oder?

deshalb war meine frage auch, ob ich mit meinem dummyuser auch in einen anderen benutzer wechseln kann als nur su. in einen, der dann q3a, ts und icecast starten darf...

somit wäre eine weitere hürde für einen potentiellen angreifer geschaffen, da nur ich dieses szenario kenne...

desweiteren bin ich auf der suche nach einem kleinen und feinen q3admin tool - falls jemand sowas weiss, nur her damit

mfg
joshi

[padarasa]

ich möchte einen user anlegen (root login unterbunden), mit dem ich mich dann einloggen kann und mich dann aufstufe zum su. somit müsste ein etwaiger eindringling schon mal 2 user und passwörter knacken.

Oder mit einer Sicherheitslücke ins System eindringen und sich dann root-Rechte z.B. durch nen Kernel-Bug besorgen. Die Wahrscheinlichkeit ein Passwort zu knacken ist doch sehr gering. Außer du hast richtig schlechte Passwörter. Mit genug Stellen, Groß- und Kleinschreibung, Zahlen und Sonderzeichen ... sehe ich keine große Gefahr.

falls es nun meinen torwächter-user irgendwie knackt, dann soll der eben gar nix dürfen

gute Sache, wie willst du das realisieren?

(kein wget von irgendwelchen dateien, kein editor zum scripten, kein gcc zum kompilieren, um ihm komplett die hände zu binden, falls er wirklich zugang zum system hat. ich glaub, da bin ich vom denkansatz her net so schlecht, oder?

Sobald er "eigenen" Code ausführen kann (sprich mittels Lücke im System) wird das schwierig.

deshalb war meine frage auch, ob ich mit meinem dummyuser auch in einen anderen benutzer wechseln kann als nur su. in einen, der dann q3a, ts und icecast starten darf...

Solang dieser "dummyuser" das Passwort kennt, kann er jeden User annehmeh.

somit wäre eine weitere hürde für einen potentiellen angreifer geschaffen, da nur ich dieses szenario kenne...

Im Prinzip braucht man nur Zugang zum Server. Sobald man Benutzerrechte hat, kann man versuchen sich auch Root-Rechte zu erschleichen. In wie weit da der Dummyuser helfen soll, hab ich jetzt nicht kapiert.

Chroots sind prinzipiell auch eine gute Idee, aber wenn du wissen willst wie man da ausbrechen kann:
http://www.bpfh.net/simes/computing/chroot-break.html

Natürlich kann man sowas auch verhindern

[joshi]

Oder mit einer Sicherheitslücke ins System eindringen und sich dann root-Rechte z.B. durch nen Kernel-Bug besorgen. Die Wahrscheinlichkeit ein Passwort zu knacken ist doch sehr gering. Außer du hast richtig schlechte Passwörter. Mit genug Stellen, Groß- und Kleinschreibung, Zahlen und Sonderzeichen ... sehe ich keine große Gefahr.

meine pw´s sind idr min. 12 zeichen lang, mit sonderzeichen ($, *, alles was mir so in den sinn kommt). das mit dem kernelbug hat man ja eigentlich bei nem vserver nie in unter kontrolle, da man da den kernel nicht updaten kann.

falls es nun meinen torwächter-user irgendwie knackt, dann soll der eben gar nix dürfen

gute Sache, wie willst du das realisieren?

ich hab mal was gelesen, dass man einem user sein eigenes sbin oder bin verzeichniss angeben kann. wenn das leer ist, und er im homedir jailed ist, sollte es ihm doch nicht möglich sein, irgendwas auszuführen, oder? und wenn er dann noch (wenns geht) keine schreibrechte hat, kann er nicht mal eine datei erstellen, ein script per shell reinklopfen usw...

(kein wget von irgendwelchen dateien, kein editor zum scripten, kein gcc zum kompilieren, um ihm komplett die hände zu binden, falls er wirklich zugang zum system hat. ich glaub, da bin ich vom denkansatz her net so schlecht, oder?

Sobald er "eigenen" Code ausführen kann (sprich mittels Lücke im System) wird das schwierig.

wenn er (siehe oben) keinen einzigen befehl ausführen kann, denk ich mir, wird das schlecht gehen (gar nicht will ich nicht sagen, aber halt eher schlecht, oder?)

Solang dieser "dummyuser" das Passwort kennt, kann er jeden User annehmeh.

mit dem dummyuser logge ich mich ja ein, das einzige was der kann können sollte ist den user zu wechseln.

Im Prinzip braucht man nur Zugang zum Server. Sobald man Benutzerrechte hat, kann man versuchen sich auch Root-Rechte zu erschleichen. In wie weit da der Dummyuser helfen soll, hab ich jetzt nicht kapiert.

naja, ich hab nie behauptet, dass das geht - eingebildet hab ichs mir halt *gg*
und deshalb hier gepostet und wollte bestätigung oder ernüchternde aufklätung

Chroots sind prinzipiell auch eine gute Idee, aber wenn du wissen willst wie man da ausbrechen kann:
http://www.bpfh.net/simes/computing/chroot-break.html

Natürlich kann man sowas auch verhindern

und genau sowas will ich halt schritt für schritt machen - das system soweit sichern, wie es der vserver (bez. kernel - siehe oben) halt zulässt. um einem möglichen angreifer so wenig angriffsfläche wie nur irgend möglich zu geben...


in wieweit mein ansatz da in ordnung ist, wollte ich halt von euch wissen. dass diese lösung perfekt ist oder auch nur funktioniert, hab ich nie behauptet - gehofft halt

mfg
joshi