User Root aussperren

[BoSSSpy]

Hallo,

ich hab einen kleinen VPS Server gemietet und bemerke mit

Code: Alles auswählen

 netstat -tapenc

und

Code: Alles auswählen

lastb

man massiv versucht via ssh und root sich anzumelden.
Ich hab ein schön doofes Passwort genommen, jedoch würde ich gerne wie hier https://www.thomas-krenn.com/de/wiki/SS ... _verbieten beschrieben worden ist den root die Rechte wegnehmen. Ein neuer User welcher in der root & sudo Gruppe sind befindet, ist aber kein vollwertiger Root.
Hat da jemand eine Idee wie ich am besten vorgehen kann um "root" auszusperren?

Vielen Dank für die Tipp's

[heisenberg]

man massiv versucht via ssh und root sich anzumelden.

Willkommen im Internet!

----

a) Trage in /etc/ssh/sshd_config dies ein:

Code: Alles auswählen

PermitRootLogin without-password

... und sshd neu starten. Jetzt darf sich der Root nur noch per Public-Key anmelden.(Das solltest Du vorher eingerichtet und verifiziert haben)
Siehe: https://wiki.ubuntuusers.de/SSH#Authent ... ublic-Keys

b) Den SSH-Port von 22 auf etwas höheres einstellen. Also z. B. 41234 (kleiner als 65535!). Das ist zwar kein wirkliches Sicherheitsfeature, aber es reduziert die massenhaften SSH-Root-Login-Versuche erheblich.

c) fail2ban einrichten für SSH. Damit werden Brute-Force-Angriffe nach einer einstellbaren Anzahl fehlgeschlagener Versuche per iptables gesperrt.

Siehe: https://www.thomas-krenn.com/de/wiki/SS ... _absichern

[dufty2]

Jetzt darf sich der Root nur noch per Public-Key anmelden.

In IMHO sollte mensch sich überhaupt nicht als root einloggen dürfen.
Nur noch - per public-key - als "normalo"-user.
Und diesen normalo-user auch keine erweiterten Rechte geben, so wie es BoSSSpy vor hat.
Falls ja was gemacht werden muss, dann halt ein

Code: Alles auswählen

$ su -

Und das nur recht sparsam.

Am allerbesten, man loggt sich gar nicht mehr auf seinen Server ein

[DeletedUserReAsG]

IMHO sollte mensch sich überhaupt nicht als root einloggen dürfen.

Die allgemeine Meinung geht mittlerweile dorthin, dass es sicherer wäre, wenn root sich (nur) via Schlüssel anmelden kann, statt dass ein lokaler User mit einem Passwort zu root werden darf. Mir leuchtet der Gedankengang dahinter durchaus ein.

[dufty2]

IMHO sollte mensch sich überhaupt nicht als root einloggen dürfen.

Die allgemeine Meinung geht mittlerweile dorthin, dass es sicherer wäre, wenn root sich (nur) via Schlüssel anmelden kann, statt dass ein lokaler User mit einem Passwort zu root werden darf. Mir leuchtet der Gedankengang dahinter durchaus ein.

/bin/su gehört zum Paket "login" und das ist "essential", bekommt man also nicht so einfach weg.
Dem User root wird man eh' ein Passwort verpassen, da man sich per console anmelden möchte.
Somit bleibt nur noch, dass der public key unter /home/user/.ssh statt /root/.ssh liegt.
De-priviligierte User hat man eh, da man ja Apache/MySQL/whatever damit laufen lassen will.

Einen echten Vorteil sehe ich - derzeit - nur dann, wenn man sich nur noch per Smartcard - auch lokal - anmelden kann, denn dann kann man das Passwortzeugs einsparen.

[DeletedUserReAsG]

su wird zu anderen Zwecken gebraucht. Das PW von Root könnte man in dem Szenario entfernen und damit verhindern, dass su zu root funktioniert oder dass sich jemand lokal als root einloggen kann.
Ich sehe das Problem damit nicht. Insbesondere sehe ich heute nicht mehr, dass ein erlaubter Root-Login via Schlüssel oder Ähnlichem unsicherer sein sollte, als ein komplett Verbotener.

[uname]

den root die Rechte wegnehmen.

root darf im Prinzip immer alles. Du meinst eher, dass sich root per Passwort nicht anmelden darf. Das ist aber eine Funktion des SSH-Servers bzw. dessen Konfiguration.

Ein neuer User welcher in der root & sudo Gruppe sind befindet, ist aber kein vollwertiger Root.

Ein Benutzer ist nie root. Per "sudo" kann er root-Befehle absetzen, da der Befehl "sudo" per setuid-root die Ausführung von Befehlen als root erlaubt. Also so ähnlich wie "passwd", wo auch nicht der Benutzer berechtigt ist in /etc/shadow zu ändern, sondern der Anwender indirekt über den Befehl "passwd" sein Passwort ändert.
Mit "sudo -s" kannst du natürlich als normaler Benutzer auch eine root-Shell erhalten. Diese Untershell ist dann eine root-Shell und somit ist der Benutzer root. Eigentlich ist die Shell root und der Benutzer ist weiterhin nicht root. Und was man nun in der Untershell eingibt gibt man als root ein. Der vorherige Benutzer ist unwichtig.
Die Rechte bzw. Shell gab es aber per "sudo" per setuid-root aufgrund von /etc/sudoers und somit wahrscheinlich aufgrund der Gruppe sudo. Lese noch "man sudoers".
Ich hoffe ich habe alle Klarheiten beseitigt.

[Cae]

Dem User root wird man eh' ein Passwort verpassen, da man sich per console anmelden möchte.

Aber ich werde so ein Passwort komplex genug machen, dass ich es mir nicht auswendig merken kann (sondern es auf einen Zettel schreiben und im Bedarfsfalle aus dem Tresor holen). Und auch sonst ist ein zusaetzliches Passwort nur super nervig, weil sowas wie

Code: Alles auswählen

$ ssh root@host tail /var/log/auth.log

einfach nicht mehr geht, und die Alternative

Code: Alles auswählen

$ ssh user@host su -lc 'tail /var/log/auth.log' root
Password: ********************************

wird man nicht freiwillig eintippen wollen. Das macht nur den Workflow kaputt.

Die Verwendung von public keys und PermitRootLogin without-password ist imho sehr empfehlenswert und ausreichend. Die Fehl-Logins kann man ausserdem prima per fail2ban weiterverarbeiten (SSH auf Port 22 ist eine hervorragende Datenquelle).

Btw., man kann einem Benutzer sehr wohl die UID oder Gruppe 0 verpassen, auch wenn er nicht root heisst. Kein Problem, er hat dann exakt dieselben weitreichenden Rechte, heisst aber anders. Bringt in den meisten Faellen keinen Gewinn. Ein anwendbares Szenario waere beispielsweise eine vertrauensvoll geteilte Maschine mit mehreren "root"-Logins, welche dann pro "root"-Login je ein unterschiedliches $HOME und damit eine individuell anpassbare Umgebung fuer jeden Benutzer haette.

Gruss Cae

[heisenberg]

Extrem lange Passwörter wird man nicht freiwillig eintippen wollen. Das macht nur den Workflow kaputt.

Full Ack. Allerdings ist ein komplexes Passwort mit 30 Zeichen aufwärts ein guter Fallback, falls man mal an einem System sitzt, dass den eigenen Key nicht eingetragen hat. Wenn man dann aus seinem Passwortsafe das Passwort per CopyPaste übernehmen kann ist das schon gut. Da muss man schon sehr wichtig sein, dass jemand einen hohen Aufwand treibt und da, nach dem er es geschafft hat, sich die Shadow anzueignen auch noch ein paar 1000 Brute-Force Nodes auf das knacken des Passwortes mietet. Auch ohne fail2ban abgesichertem SSH hat ein Angreifer da keine Chance.

Wohlgemerkt bei neueren Systemen. Bei irgendwelchen Alt-Systemen war die Passwortlänge ja auf 8 Zeichen beschränkt.

Nochwas zum Thema Zeit und Brute Force:

http://www.1pw.de/brute-force.html

Selbst wenn man als Sicherheitspuffer eine Vertausendfachung der Rechnerleistung in Betracht zieht - wohlgemerkt für Standardserver mit normalem Sicherheitsbedarf - dann ist man auch mit guten Passwörtern sicher.

[dufty2]

Und auch sonst ist ein zusaetzliches Passwort nur super nervig, weil sowas wie

Code: Alles auswählen

$ ssh root@host tail /var/log/auth.log

einfach nicht mehr geht, und die Alternative

Code: Alles auswählen

$ ssh user@host su -lc 'tail /var/log/auth.log' root
Password: ********************************

wird man nicht freiwillig eintippen wollen. Das macht nur den Workflow kaputt.

Stimmt, der Workflow ist kaputt, aber in einem ganz anderen Sinne:
Wer sich einloggt, um zu sehen, wer sich eingeloggt hat, macht was falsch, genauer:
Die Automatisierung/Monitoring-Maschinerie wurde noch nicht weit genug vorangetrieben.
Ein-/Auslogvorgänge kann man z. B. per SNMP-traps recht flott zentralisieren, dazu bedarf es kein manuelles Einloggen mehr.

Merke mir 2 Dinge: Den PIN meiner Smartcard und das Passwort zum Passwortsafe, dann ist es egal,
ob die PW der einzelne Maschinen (jedes hat sein eigenes!) 20 oder 30 oder 50 Zeichen lang ist.
Mit Tastaturkürzeln geht das superflott, der Rest - wie gesagt - wird automatisiert.

Selbst mit vorgehaltener Pistole auf mich gerichtet könnt' ich Dir - nur als Beispiel - nicht sagen, wie mein Passwort für dieses Forum aussieht. Ich habe es nie gesehen ...

[DeletedUserReAsG]

Die Automatisierung/Monitoring-Maschinerie wurde noch nicht weit genug vorangetrieben.
Ein-/Auslogvorgänge kann man z. B. per SNMP-traps recht flott zentralisieren, dazu bedarf es kein manuelles Einloggen mehr.

Merke mir 2 Dinge: Den PIN meiner Smartcard und das Passwort zum Passwortsafe […]

Dir ist bewusst, dass es hier um einen popeligen vServer geht?

[dufty2]

Heya,

Meister Poettering hat "machinectrl shell" eingeführt. Das war mir anfangs der Unterschied (zu "su -") nicht so klar.
Aber die Erklärung von
http://www.phoronix.com/forums/forum/ph ... post820598
ist hilfreich. Danach macht es - vermutlich - bei ssh Sinn, "direkt" als root sich einzuloggen als durch "su -" restriktiert zu sein.
Mensch lernt nie aus

[heisenberg]

Mal so als Vergleich aus dem RL:

Anzahl der Root-Login-Versuche auf einen SSH-Dienst mit Port 22 und aktiviertem Passwort-Login pro Tag:

20000

Anzahl der Root-Login-Versuche auf einen SSH-Dienst mit Port !22 und aktiviertem Passwort-Login pro Tag:

0