Hack #19 - Hinter Ex-Benutzern aufräumen

Aufmacher News

O'Reilly-Verlag
25.09.2003

Der O'Reilly-Verlag bringt Anfang Oktober das Buch Linux Server Hacks auf den Markt. Hier auf Linux-Community.de lesen Sie exklusiv 20 ausgewählte Tipps vorab in der deutschen Übersetzung.

Es passiert. Pläne werden geändert, der Fokus einer Firma verändert sich, und die Leute suchen sich einen anderen Job. Irgendwann musste jeder Admin schon einmal den Zugriff per Shell aufräumen, nachdem jemand die Firma verlassen hat, gerne oder nicht.
Ich selbst vertrete die Meinung, dass man den eigenen Benutzern, wenn man ihnen nicht von Anfang an traut, eines Tages wirklich nicht mehr trauen kann. (Zugegeben, ich musste noch nie einen offenen Shell-Server eines ISP verwalten.) Auf jeden Fall ist es sehr ratsam, zu Ihren Benutzern von Anfang an ein Vertrauensverhältnis aufzubauen, wenn Sie später nachts ruhig schlafen können wollen.
Wenn Sie jedoch wirklich alte Accounts sperren müssen, gehen Sie am besten strategisch dabei vor. Verlassen Sie sich nicht darauf, dass der entsprechende Benutzer, nur weil Sie ein passwd -l verwendet haben, keinen Zugriff mehr auf Ihren Rechner hat. Angenommen, wir sperren einen Account namens luser. Hier stehen einige offensichtliche (und einige weniger offensichtliche) Dinge auf der Check-Liste, wenn es ums Saubermachen geht:

passwd -l luser

Selbstverständlich ist es ein guter erster Schritt, das Passwort des Benutzers zu sperren.

chsh -s /bin/true luser

Das ist ein weiterer beliebter Schritt: seine Login-Shell auf etwas zu setzen, das sofort terminiert. Im Allgemeinen verhindert man dadurch, dass ein Benutzer Shell-Zugriff auf den Server erlangt. Aber seien Sie gewarnt: Wenn auf diesem Rechner sshd läuft und Sie eine entfernte Authentifizierung per RSA- oder DSA-Schlüssel erlauben, kann luser weiterhin Ports an jeden Rechner weiterleiten, der von Ihrem Server erreichbar ist! Mit folgender Kommandozeile

luser@evil:~$ <b>ssh -f -N -L8000:private.intranet.server.com:80 old.server.com</b>

hat luser gerade seinen lokalen Port 8000 auf den HTTP-Port Ihres internen Intranet-Servers umgeleitet. Das ist erlaubt, da luser kein Passwort verwendet, sondern einen RSA-Schlüssel und nicht versucht, ein Programm auf old.server.com auszuführen (da er den Schalter -N angegeben hat).
Offensichtlich sollten Sie ~luser/.ssh/authorized_keys* entfernen und verhindern, dass luser seinen ssh-Schlüssel überhaupt benutzen kann. Suchen Sie außerdem nach einer dieser Dateien:

~luser/.shosts
~luser/.rhosts

Normalerweise ist das kein Problem, außer Sie verwenden rsh oder haben diese Funktionalität in ssh eingeschaltet. Aber Sie können nicht wissen, ob sich ein anderer Admin später entscheiden wird, die .shosts- oder .rhosts-Funktionalität bereitzustellen. Das heißt: Sie entfernen sie besser jetzt, sofern sie vorhanden ist.
Hatte luser irgendwelche sudo-Rechte? Prüfen Sie es mit visudo, um sicherzugehen.
Und wie sieht es mit cron- oder at-Jobs aus?

crontab -u luser -l 
atq

Und überhaupt: Führt luser jetzt gerade Jobs aus?

ps awux |grep -i ^luser

Oder Sie können, wie in "Symbolische Manipulation von Prozessen mit procps" [Hack #17] angegeben, dies benutzen:

 skill -KILL luser 

Konnte luser CGI-Programme aus seinem Home-Verzeichnis (oder sonstwoher ausführen)?

find ~luser/public_html/ -perm +111

Was ist mit PHP oder anderen eingebetteten Skriptsprachen?

find ~luser ~public_html/ -name &#39;*.php*&#39;

Hat luser irgendeine E-Mail-Weiterleitung eingestellt? Solche Weiterleitungsprogramme können oft manipuliert werden, um beliebige Programme auszuführen:

less ~luser/.forward
grep -C luser /etc/mail/aliases

Und schließlich: Besitzt luser irgendwelche Dateien an seltsamen Orten?

find / -user luser &gt; ~root/luser-files.report

Ein sicheres (und schnelles) Verfahren, um zu garantieren, dass alle persönlichen Konfigurationsdateien von luser außer Kraft gesetzt werden, besteht darin, sie mit mv /home/luser /home/luser.removed umzubenennen. Das rührt den Inhalt des Home-Verzeichnisses von luser nicht an, und man muss sich keine Sorgen machen, etwas übersehen zu haben. Beachten Sie aber, dass dadurch eine legitime .forward-Datei nicht mehr funktioniert (sowie ~luser/public_html und alle anderen öffentlich zugänglichen Daten, die luser eventuell in seinem Home-Verzeichnis hatte). Seien Sie sich also darüber im Klaren, wenn Sie diese Lösung wählen, etwa indem Sie einen passenden Eintrag in die aliases-Systemdatei aufnehmen und eine gesäuberte Version von public_html/ nach /home/luser/public_html/ zurückkopieren.
Suchen Sie nach Konfigurationsdateien zu Systemsoftware, auf die luser Zugriff hatte, besonders von Diensten, die als privilegierte Benutzer laufen. Selbst etwas so Harmloses wie eine vom Benutzer angelegte Apache-Konfigurationsdatei könnte später dazu verwendet werden, Shell-Zugriff zu erlangen.
Diese Liste ist alles andere als vollständig und soll nur demonstrieren, dass es eine Menge mehr zu tun gibt, um den Zugriff eines Benutzers rückgängig zu machen, als nur sein Passwort zu sperren. Falls der Benutzer jemals root-Zugang hatte, ist alles möglich. Der Zugriff könnte später durch alles Mögliche erlaubt werden, von einem trojanischen System-Binary, einem unsichtbaren Kernel-Modul bis zum einfach geänderten root-Passwort.
Sie sollten Ihre Shell-Benutzer kennen lernen, lange bevor Sie ihnen "Auf Wiedersehen" sagen müssen. Dieser Job ist so schon schwierig genug, auch ohne sich Gedanken darüber zu machen, wem Sie vertrauen können.

Ähnliche Artikel

  • fli4l
    Mit wenigen Teilen aus der PC-Bastelkiste lässt sich ein ISDN- oder DSL-Internet-Einwählrouter aufbauen, der auf einer einzigen Diskette läuft. fli4l heißt die Wunderwaffe.

Kommentare
Re: Hack #19 - Hinter Ex-Benutzern aufräumen
Andreas Pfaffeneder, Donnerstag, 25. September 2003 18:35:09
Ein/Ausklappen

Zugangsberechtigungen über PAM abwickeln, User aus einer Gruppe für die Remote-Zugang per ssh/telnet/pop/ftp/... eingerichtet wurde herausnehmen oder user in Gruppe stecken die explizit nichts darf.

z.B: /etc/badluser mit den entsprechenden Accounts füttern und die PAM-konfiguration der einzelnen Dienste:


account required /lib/security/pam_listfile.so item=user sense=deny file=/etc/badluser

einfügen.

Das erspart die Spielerei und die konfiguration der einzelnen Dienste.


Bewertung: 275 Punkte bei 51 Stimmen.
Den Beitrag bewerten: Gut / Schlecht
Re: Hack #19 - Hinter Ex-Benutzern aufräumen
René Podlogar, Donnerstag, 25. September 2003 13:08:36
Ein/Ausklappen

hmmmm... das erscheint mir alles ein wenig aufwendig.

Ich gehe das bisher immer so an, daß ich den Benutzeraccount (auch in zB. htaccess, mysql) komplett lösche und das homelaufwerk auf CDROM migirere. Das homelaufwerk wird gelöscht. Alle verbiebenen dateien mit der betreffenden userid werden noch auf "sinvoll" überprüft und die Eigentümerschaft entsprechend geändert (zB. Arbeitsgruppendateien).

Habe ich bei diesem Vorgehen irgendetwas Grobes übersehen?


Bewertung: 268 Punkte bei 51 Stimmen.
Den Beitrag bewerten: Gut / Schlecht
-
Re: Hack #19 - Hinter Ex-Benutzern aufräumen
xxx yyy, Donnerstag, 25. September 2003 13:54:01
Ein/Ausklappen

> hmmmm... das erscheint mir alles ein wenig aufwendig.
Natürlich kann man das user-Verzeichnis auch auf CD brennen, falls der Platz ausreicht.
Man darf es nur nicht wegwerfen. Denn es könnten noch wichtige Dinge darin enthalten sein.



Bewertung: 254 Punkte bei 53 Stimmen.
Den Beitrag bewerten: Gut / Schlecht
Re: Hack #19 - Hinter Ex-Benutzern aufräumen
xxx yyy, Donnerstag, 25. September 2003 12:24:27
Ein/Ausklappen

Ich bin Entwickler und kein Admin.
In meiner Naivität würde ich das Problem folgendermassen angehen:

- Die Arbeitsgruppe bekommt ein eigenes LAN und wird über einen Router an das Backbone
angebunden.
- evtl. steht ein CVS Server ausserhalb des LAN
- Von Aussen hat niemand Zugriff auf das LAN
- Der Benutzer wird auf der/den Maschine(n) eingerichtet, auf denen er arbeiten soll
- Der Benutzer bekommt evtl. root Zugriff auf seiner Workstation (falls notwendig mehr)
- Wenn der Benutzer die Arbeitsgruppe für immer verlässt:
mv /home/user /home/user.removed
und Account löschen
CVS Account löschen

Übersehe ich dabei wichtige Dinge ?


Bewertung: 242 Punkte bei 54 Stimmen.
Den Beitrag bewerten: Gut / Schlecht
-
Re: Hack #19 - Hinter Ex-Benutzern aufräumen
René Podlogar, Donnerstag, 25. September 2003 13:12:06
Ein/Ausklappen

>>>- Der Benutzer bekommt evtl. root Zugriff auf seiner Workstation (falls notwendig mehr)


Bewertung: 281 Punkte bei 57 Stimmen.
Den Beitrag bewerten: Gut / Schlecht
-
Re: Hack #19 - Hinter Ex-Benutzern aufräumen
xxx yyy, Donnerstag, 25. September 2003 13:34:03
Ein/Ausklappen

> Was ist denn MEHR als root-Zugriff?
root Zugriff auf weiteren Maschinen
Nicht nur der eigenen Workstation



Bewertung: 241 Punkte bei 54 Stimmen.
Den Beitrag bewerten: Gut / Schlecht

Aktuelle Fragen

MS LifeCam HD-5000 an Debian
Kay Michael, 13.04.2016 22:55, 0 Antworten
Hallo, ich versuche die oben erwähnte Cam an einem Thin Client mit Debian zu betreiben. Linux...
Import von Evolution nach KMail erzeugt nur leere Ordner
Klaus-Christian Falkner, 06.04.2016 12:57, 2 Antworten
Hallo, da ich vor einiger Zeit von Ubuntu auf Kubuntu umgestiegen bin, würde ich gerne meine E...
Sophos lässt sich nicht unter Lubuntu installieren
Chrstina Turm, 30.03.2016 20:56, 3 Antworten
Hi Leute, habe mir vor paar Tagen auf ein Notebook, das ohne Linux ausgedient hätte, Linux dr...
Novell Client auf Raspbian
Chris Baum, 16.03.2016 15:13, 3 Antworten
Hallo Community, ich hätte eine Frage, und zwar geht es um folgendes: Ich möchte eine Datei...
Pantheon konfigurieren (eOS)
John Smith, 16.03.2016 13:50, 0 Antworten
Hallo ins Forum, ich bin neu in der Linuxwelt und fühle mich bereits sehr wohl. Mein neues Sys...