Wie kann man einen wechsel zu root unmöglich machen?

[razorjack]

Ich will meinen Server gegen brute-force methoden absichern.

Ich stelle mir dabei vor, das der Angreifer in der Lage wäre, ein Skript unter einem normalen user auszuführen, welches durchs ständiges Ausprobieren anderer Zeichenkombinationen über das Befehl "su" zum Root Passwort gelangen kann.
Eine Privilegeinschränkung zur Ausführung des Befehls "su" wäre jedoch keine Lösung glaube ich, da jede andere Applikation die gleichen Kernelprozeduren zur Privilegsetzung aufrufen darf, wie "su" das tut.
Kann man stattdessen irgendwie den Kernel selbst dazu bringen, einer Anwendung überhaupt nicht zu gestatten, seine Privilegien zu ändern, wenn diese nicht unter root läuft?

 

[Guin]

Also wenn dein root Passwort lang genug ist (mehr als 8 Zeichen) und zudem aus Buchstaben, Ziffern und Sonderzeichen besteht, wird kaum jemand per Brute Force das Passwort herusfinden.

Kann man stattdessen irgendwie den Kernel selbst dazu bringen, einer Anwendung überhaupt nicht zu gestatten, seine Privilegien zu ändern, wenn diese nicht unter root läuft?

Mir persoenlich ist da nichts bekannt.

 

[Huschi]

Kann man stattdessen irgendwie den Kernel selbst dazu bringen, einer Anwendung überhaupt nicht zu gestatten, seine Privilegien zu ändern, wenn diese nicht unter root läuft?

Das ist bereits der Fall. Deshalb gibt es ja Programme wie su und sudo. Beide arbeiten übrigends gleich: Sie ändern nicht die aktuellen Privilegien, sondern öffnen eine neue Shell.
Willst Du nicht, daß man sie nutzt, dann deinstallier sie.

huschi.

 

[Peacemaker33]

Du kannst die Authentifizierung per PW vollständig abschalten und nur noch RSA-Schlüssel verwenden, dann ist eine Brute-Force-Attacke faktisch aussichtslos.

 

[Huschi]

und nur noch RSA-Schlüssel verwenden

Das gilt lediglich für ssh.
Razorjack redete eindeutig von einem lokalen Angriff.

huschi.

 

[Peacemaker33]

Naja, von "lokal" kann ich in seinem Beitrag aber nichts finden.
Aber vielleicht mag er ja selbst etwas dazu sagen...

 

[Huschi]

Wer lesen kann ist klar im Vorteil:

ein Skript unter einem normalen user auszuführen

Er läßt offen, wie der Angreifer das Skript einbringt. Aber er sagt eindeutig, daß der Angriff lokal läuft.

huschi.

 

[razorjack]

Danke für die Tips.
Ich glaube ich habs herausgefunden. Was da gemacht wird.

Es gibt zwei Prozeduren für Benutzerwechsel bei linux/unix, um eine Anwendung als anderen Benutzer anzumelden:

void setuid( int uid );
void setgid( int gid );

Diese sind aber nur Anwendungen vorbehalten, die unter Root laufen.
Zum Benutzerwechsel werden dagegen programme wie su,login o.ä. verwendet.

Alles was ich machen müsste, ist nur, alle root Programme zu finden wie /bin/login etc., die mit SET-UID-FLAG bzw. SET-GID-FLAG attributen versehen sind.
Ich muss diese dannach nur noch für Root zugänglich machen und alle SET-UID-FLAG und SET-GID-FLAG Dateiattribute löschen.

Man fragt sich dann nur, welche es sind und welche ich nicht ändern sollte.

Alles klar. Ich glaube dies wäre so in etwa ne lösung.

 

[Huschi]

alle root Programme zu finden wie /bin/login etc., die mit SET-UID-FLAG bzw. SET-GID-FLAG attributen versehen sind.

find / -type f \( -perm -04000 \) \-exec ls -l {} \;

Ich muss diese dannach nur noch für Root zugänglich machen und alle SET-UID-FLAG und SET-GID-FLAG Dateiattribute löschen.

Das ist das, was man unter System-Administratoren als 'paranoid' definiert.

Man fragt sich dann nur, welche es sind und welche ich nicht ändern sollte.

I.d.R. ist das System bereits entsprechend sicher ausgelegt.
Die 'Schwachstellen' für einen Bruteforce sind letztendlich su und sudo.
sudo kann man in /etc/sudoers einschränken oder gleich deinstallieren.
Und su könnte man z.B. umbenennen, bzw. nur einer bestimmten Benutzergruppen zuteilen.

huschi.

 

[razorjack]

Die Lösung "Paranoid" wäre für meinen Internet Host glaub ich am Idealsten. Ich lasse dort hauptsächlich nur div. Serverdienste am laufen.

Die Einschränkung oder Sperrung des su Befehls und sudo Befehls wäre eher für ne Workstation angebracht. Aber dies ist dennoch gut zu wissen, wenn man sie Blockieren könnte.

Was das SSH Bruteforcing angeht. Ich glaub da kann man auch nen RSA Key file benutzen.

Nun gut. Danke nochmals.