Archiv verlassen und diese Seite im Standarddesign anzeigen : su vs. sudo, was ist sicherer?
CheGuevara
03.09.06, 09:31
Hallo Leute
Ich habe ein Grundsätzliches Problem mit der Sicherheit.
Ich habe einen Server mit verschiedenen Diensten aufgestellt. Dieser liegt hinter einem Router im LAN.
Um die Konfiguration des Servers auch von ausserhalb zu bewerkstelligen, habe ich eine Dyndns eingerichtet und den Port 22 geforwardet (auf den Server natürlich) Diese Konstelation funktioniert bestens.
Da ich von natur aus ein sehr paranoider Mensch bin, will ich dieses System so sicher wie nur möglich machen. Jetzt bin ich zur "su" oder "sudo" Frage gekommen. Alle behaupten, dass "sudo" die sichere Variante währe.
Jedoch habe ich diesbezüglich ein Verständniss Problem. Root ist auf dem Server per SSH standardmässig gesperrt. Ich muss mich als user einloggen und dann root befehle ausführen.
Bei su muss ein potenzieller Einbrecher zuerst das PW des Users herausfinden und dann noch das PW von ROOT.
Bei sudo muss er nur das PW vom User knacken und er könnte alles mit Rootrechten ausführen.
Ich habe Sudo deaktiviert. Was haltet ihr davon?
Gruss
CheGuevara
Mit sudo hast du da was falsch verstanden. Du kannst in der /etc/sudoers festlegen, welcher Nutzer/welche Gruppe welchen Befehl mit Root-Rechten ausführen darf. Wenn also jemand das Passwort des Nutzers herausfindet kann er keineswegs damit alles als Root ausführen, wenn du sudo vernünftig konfiguriert hast.
Ich würde trotzdem sudo deaktivieren wenn du es nicht benötigst.
-hanky-
CheGuevara
03.09.06, 10:41
Verstehe. Aber warum sollte ich einem normalen User mehr Rechte zugestehen als anderen?
Ich habe einen Root und dieser soll das System verwalten. Alle anderen sollten "nur" arbeiten und dazu genügt ein normaler Account, oder irre ich?
Nichts für ungut und besten dank für deinen rat!
Gruss
CheGuevara
Verstehe. Aber warum sollte ich einem normalen User mehr Rechte zugestehen als anderen?
Ich habe einen Root und dieser soll das System verwalten. Alle anderen sollten "nur" arbeiten und dazu genügt ein normaler Account, oder irre ich?
Nichts für ungut und besten dank für deinen rat!
Gruss
CheGuevara
Hi,
um ein Beispiel zu nennen, in dem sudo für mich mehr als nützlich ist:
[...]
%users ALL= NOPASSWD: /usr/sbin/cryptsetup luksOpen *
%users ALL= NOPASSWD: /usr/sbin/cryptsetup luksClose *
[...]
Damit kann ich meine verschlüsselte Partition als normaler Nutzer mounten und muss nicht immer zuvor per 'su' zu Root wechseln.
Das ist aber mehr Faulheit als Notwendigkeit, ich könnte das Ganze auch per "su" lösen, wäre halt nur mehr Aufwand.
Wenn deine Nutzer nur ganz normal auf dem System arbeiten können sollen, wie du schreibst, ist sudo nicht notwendig und ich würde es deinstallieren/deaktivieren.
-hanky-
Wenn also jemand das Passwort des Nutzers herausfindet kann er keineswegs damit alles als Root ausführen, wenn du sudo vernünftig konfiguriert hast.
Wenn schon das Passwort eines Users bekannt wird, ist es auch nur noch nötig, sich als dieser einzuloggen. Ich kann mir nicht vorstellen, dass sudo da noch helfen kann.
Hi!
Bei sudo muss er nur das PW vom User knacken und er könnte alles mit Rootrechten ausführen.
Das hängt von deiner Konfiguration ab. Du kannst auch die Option targetpw setzen, sodass man nach dem root-Kennwort statt des User-Kennworts gefragt wird.
Das hätte z.B. einen Vorteil in Shell-Scripts, da sudo z.B. mehrere Versuche für das Kennwort zulässt, während bei einer fehlerhaften Eingabe des Kennwortes via su das komplette Script abbricht.
Außerdem kannst du bei sudo eine Zeitspanne konfigurieren, in der du das Kennwort nicht erneut eingeben musst. So bräuchtest du gar kein su, sondern könntest alles mit sudo machen und nach spätestens (standardmäßig) 5 Minuten ohne root-Aktivität ist der root-Zugang wieder dicht. Du kannst die "root-Freigabe" aber auch manuell zurücksetzen.
Wenn du per su eine root-Shell öffnest, musst du selbst daran denken, diese wieder zu schließen, was man z.B. übersehen könnte, wenn man mit screen arbeitet. In solchen Fällen würde nämlich auch die Kenntnis des User-Kennworts reichen, um root-Rechte zu erhalten, indem er die jeweilige screen-Sitzung in den Vordergrund holt.
Gruß
fuffy
Ich fand zum Thema su vs. sudo diesen Link sehr interessant: http://wiki.ubuntuusers.de/sudo?highlight=%28sudo%29
Allerdings ist der wohl mehr auf den Desktop-User ausgelegt. Nach dem Lesen des Links würd ich auf Servern doch eher zur klassischen su - Variante raten.
MfG ako
stefan-tiger
03.09.06, 20:18
Noch was zu deiner Sicherheit: warum legst du den SSH nicht auf einen anderen Port?
CheGuevara
03.09.06, 20:25
Noch was zu deiner Sicherheit: warum legst du den SSH nicht auf einen anderen Port?
Warum sollte ich dies tun? Bei einem Portscann währe dies eh ersichtlich.
Rain_maker
04.09.06, 00:57
Da ich von natur aus ein sehr paranoider Mensch bin, ..
Warum sollte ich dies tun? Bei einem Portscann währe dies eh ersichtlich.
WTF? :confused:
Bei einem Portscan, WÄRE das nicht sofort ersichtlich, sondern es würde zunächst NUR ein offener Port angezeigt.
Da aber 22 für ssh reserviert ist (sog. "privileged" Port), ist aus einem offenen Port 22 deutlich mehr ersichtlich als aus irgendeinem offenen Port > 1024.
Mal davon abgesehen, daß die wenigsten "Bösen Buben" wahrscheinlich alle 65535 Ports scannen, die "Standardports" (wie eben unter anderem Port 22) aber sehr wohl durchforsten.
http://de.wikipedia.org/wiki/Port_(Protokoll)
Greetz,
RM
hm, also meine Tools hier sagen mir sofort, dass dass, was da auf Port 4711 lauscht ein ssh-Dämon ist - aber vermutlich liegt es daran, dass ich die oberc0073n Haxx0r-Options benutze, die nirgendwo doumentiert sind...
hm, also meine Tools hier sagen mir sofort, dass dass, was da auf Port 4711 lauscht ein ssh-Dämon ist - aber vermutlich liegt es daran, dass ich die oberc0073n Haxx0r-Options benutze, die nirgendwo doumentiert sind...
Cool, haste mal nen Download-Link????????????ßßßß
:ugly:
Naja, ein Portwechsel sorgt wenigstens dafür dass die Logfiles nicht mehr mit den automatisierten Loginversuchen zugemüllt werden.
Sinnvoller in punkto Sicherheit ist da eher Port-Knocking, z.B. als Kurzbeschreibung unter [1] nachzulesen.
-hanky-
[1] http://de.gentoo-wiki.com/Port_Knocking
Hallo,
Auch Portknocking will gut konfiguriert sein.
Auf welchem Port der SSHD lauft ist doch egal, solange man nur mit PublicKeyAuthentication arbeitet.
Und die kann man ja auch noch beliebig zurecht frickeln. Stichwort Wrapper. Stichwort Forced-Commands.
Als Loesung von untrusted domains (Inet cafes) hat sich bei mir etabliert erstmal ssh auf einen User
ohne besondere Rechte zu machen. Dann ggf. sudo verwenden. Um Keyloggern vorzubeugen sollten
dann Skripte angestossen werden.
Zur sicheren sudoers Konfiguration siehe
man sudoers
Die Timestamps verursachen allerdings ordentlich RSI :)
greetz lh
PS, Es muss auch nicht jeder User gleich su ausfuehren duerfen...
hm, also meine Tools hier sagen mir sofort, dass dass, was da auf Port 4711 lauscht ein ssh-Dämon ist
Mein SSHd läuft ebenfalls auf einem Port >1024 und nmap zeigt mir nur einen offenen Port an.
Welchen Scanner nutzt du?
... Gegenfrage: welche Opionen benutzt Du?
nmap -sS (jaja nicht notwenig aber gewohnheit) -p mein_ssh_port IP
service: unknown
... dann mach mal noch ein -sV dazu :-)
Ok, die Option kannte ich nicht ^^
dann bitte nicht weiterveraten - wie gesagt, sind gaaaaanz geheime souperl33tc007e Haxxor-Options... :-), ey ~# man, ey...
CheGuevara
04.09.06, 19:02
WTF? :confused:
WÄRE
Wenn es dich glücklicher macht ......
Monk lässt grüssen!!! Huch.... muss da jetzt ein sz her?
Zurück zum Topic. Port 22 muss sein, da >1024 vom Proxy geblockt wird.
Gruss
Che
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.