Hardening Linux: Neugierige User einschränken

Achtung! Dieser Artikel ist älter als ein Jahr. Der Inhalt ist möglicherweise nicht mehr aktuell!

Normalerweise bin ich auf meinen eigenen Servern alleine. Wie man seine Linux Kiste nach außen hin schützen kann ist mir bewusst, jedoch habe ich mir noch nie Gedanken darüber gemacht wie man sich vor neugierigen Usern von innen schützen kann.

Seit kurzem habe ich einen Gast auf meinem Server, der sich um meine Insurgency Gameserver kümmern will. Dazu wurde Terminalzugriff (und auch eine Möglichkeit Dateien hoch und runterzuladen. Da der Terminalzugriff notwendig ist durch SFTP realisiert) benötigt.

Also kurzerhand den SSH Public Key angefordert und währenddessen Gedanken gemacht, wie man den Gast am herumschnüffeln hindert.

Im Grunde genommen wollte ich den Useraccount auf sein Homeverzeichnis beschränken. Man sollte nicht in das übergeordnete Verzeichnis wechseln können – sehr wohl aber in Unterverzeichnisse.

Alles was außerhalb dem Homeverzeichnis sollte unerreichbar sein. Hört sich leicht an, ist aber leider doch schwerer.

Der erste Versuch mit rbash

Sucht man nach dem Thema mit seiner Lieblingssuchmaschine wird man viele Einträge für die rbash finden. Das besondere an der „restricted bash“ oder kurz rbash:

Eigentlich eine tolle Lösung, jedoch nicht für meinen Fall anwendbar. Das „cd“-Kommando wird leider zu restriktiv geblockt sodass Unterverzeichnisse ebenfalls unerreichbar sind. Die Bash-Completition ist ebenfalls etwas verbugt.

Während ich den Artikel schrieb fiel mir kein praktischer und sinnvoller Anwendungsfall für die rbash ein.

Chroot

Ja das Thema mit chroot. Viele lieben es – viele hassen es. Ich selbst habe noch nicht wirklich viel mit chroot gemacht und keine Erfahrung damit. Kurzerhand habe ich entschieden das chroot viel zu kompliziert ist und ich eine andere Lösung finden muss.

Unix Rechte

Dann hab ich mir nochmal genau meine Anforderungen überlegt. Das der User über einen Kernelexploit root Rechte erlangt habe ich nicht bedacht. Es ging mir mehr darum, dass private Keys, E-Mails und Configfiles nicht  vom User insurgency angeschaut (und somit auch nicht kopiert) werden können.

Meine Änderungen

Am besten nimmt man dafür die r- und x-Rechte der others weg.

Beispiele am Homeverzeichnis des Users git:

Vorher:

drwxr-xr-x 20 git git 4096 Oct 28 12:33 git

Konkret heißt das: chmod 755.

User git darf lesen, schreiben und ausführen,

Gruppe git darf lesen und ausführen,

Others dürfen lesen und ausführen.

Um nun dem Benutzer insurgency sämtliche Möglichkeiten zu nehmen musste ich nur die others-Rechte kastrieren. Aktuell darf der User insurgency immer noch in das Verzeichnis wechseln. Für die Änderung:

# chmod 750 git

Danach sieht es so aus, wie es sein soll:

drwxr-x--- 20 git git 4096 Oct 28 12:33 git

Nach einem kleinen Test das erwartete Ergebnis: Der User darf nun nicht mehr in das Verzeichnis wechseln. Ein direkte Pfadangabe auf eine existierende Datei wird ebenfalls mit „Permission denied“ abgelehnt.

Angewendet habe ich das auf alle wichtigen Verzeichnissen.

Keine Dritten!

Bei mir gibt es keine Passwort Authentifizierung via ssh. Um zu verhindern, dass der User weiter Keys ohne meines Wissen einträgt habe ich den Eigentümer und Gruppe seiner _authorizedkeys Datei auf root geändert.

Vorher:

-rw-r--r-- 1 insurgency     insurgency     1580 Oct 30 14:43 authorized_keys

Nachher:

-rw-r--r-- 1 root     root     1580 Oct 30 14:43 authorized_keys

 

Stolpersteine

Über einen Solperstein bin ich gefallen. Postfix und Dovecot spielen zusammen – das wusste ich schon vorher. Nach den Änderungen an /etc/postfix und /etc/dovecot habe ich den Mailversand und -Empfang getestet. Dazu habe ich eine Mail an mich selbst geschickt – ohne Probleme!

Als ich dann den ganzen Nachmittag keine Mails bekommen habe bin ich stutzig geworden. In den Logs wurde eine „Permission denied“ Fehlermeldung festgehalten. Dovecot greift also beim Zustellen der Mails von externen Domains auf das Postfix Verzeichnis zu.

Gelöst habe ich das Problem, indem ich dem Postfix Ordner als Gruppe vmail gesetzt habe. Der User vmail ist der Benutzer unter dem Dovecot läuft.

Fazit

Wie schon oben gesagt: Angriffe von innen habe ich mir noch nie so richtig angesehen. Dabei ist mir klar geworden, dass es nicht mal einen abtrünnigen User geben muss. Exploits in Webanwendungen können ebenfalls durch solche Maßnahmen entschärft werden. In Zukunft werde ich mir auf jeden Fall mehr Gedanken über Verzeichnisrechte machen.


Du hast einen Kommentar, einen Wunsch oder eine Verbeserung? Schreib mir doch eine E-Mail! Die Infos dazu stehen hier.

🖇️ = Link zu anderer Webseite
🔐 = Webseite nutzt HTTPS (verschlüsselter Transportweg)
Zurück