Skip to content

Privilege Escalation für Konfigurationsmanagement, Teil II

So, nachdem ich die letzte Woche mit "Voraussetzungen aufbauen" verbracht habe, und wegen Zeitmangel am Wochenende sogar einen vorbereiteten Füller-Artikel posten musste, kommen wir heute (endlich) zu dem, was ich eigentlich mit Euch diskutieren wollte. Zu diesem Artikel sind mir Eure Kommentare besonders wichtig; ich weiß aber, dass es nach dem Absenden eines Kommentars im Browser einen Timeout hagelt. Das ändert aber nichts dran, dass der Kommentar ordentlich gepostet wurde.

Heute soll es nun endlich darum gehen, wie man Konfigurationsarbeiten ermöglicht und unterstützt, bei denen sich derjenige, der die Arbeiten ausführt, aktiv auf den zu bearbeitenden Systemen einlogged. Dabei schließe ich ausdrücklich das manuelle Arbeiten mit ssh oder mehrfach-ssh wie mssh und cssh ein, meine aber auch semiautomatisierte Arbeiten wie xargs --max-procs oder parallel(1) bis hin zum vollautomatischen Prozess, z.B. mit Ansible.

Continue reading "Privilege Escalation für Konfigurationsmanagement, Teil II"

Meine Best Practice für Shell-Accounts und ihre Absicherung (mit ssh)

Auf meinen Systemen bin ich im wesentlichen der einzige Shell-Benutzer. Die hier vorgeschlagenen Methoden können natürlich auch auf eine größere Menge von Accounts angewendet werden, wobei ab einer gewissen Grenze manche Verfahren nicht mehr skalieren.

lokaler Login

Lokaler Login auf der Konsole ist bei meiner Arbeitsweise die Ausnahme. Das passiert im Wesentlichen nur bei Störungen, wenn Netz und/oder ssh nicht mehr funktionieren. Die bei weitem häufigste Methode des Zugriffs auf die Shell erfolgt via ssh über das Netz. Da ich auf meinen Systemen natürlich sudo-berechtigt bin, benötige ich das zum Account gehörende Passwort (außer zum Konsolen-Login im Störungsfall) nur, um mich bei sudo zu authentifizieren um root werden zu können.

Continue reading "Meine Best Practice für Shell-Accounts und ihre Absicherung (mit ssh)"

Privilege Escalation für Konfigurationsmanagement, Teil I

Wenn man sich die Konfiguration seiner Systeme (managed systems) von einem Automaten (Konfigurationsmanagement-System, KMS) abnehmen lassen möchte, muss man ihm dazu die notwendigen Rechte geben. Da beißt die Maus keinen Faden ab.

Aber was sind die notwendigen Rechte, wie gibt man sie dem Automaten, und welche Implikationen für die Systemsicherheit (im Sinne von security) haben sie?

In diesem Artikel und seinen weiteren Teilen stelle ich ein paar Methoden vor, versuche ihre Vor- und Nachteile herauszuarbeiten und bitte euch um Kommentare und eure Meinung dazu. Dieser Teil 1 beschäftigt sich mit dem, dem ich eigentlich nur einen Absatz widmen wollte, und aus dem dann ein eigener Artikel geworden ist: Dem Pull-Prinzip mit einem Agenten.

Continue reading "Privilege Escalation für Konfigurationsmanagement, Teil I"

Daten mit Privilege Escalation abholen über eine named pipe

Aufgabe: Transportiere Daten von einem Host auf den anderen über eine ssh-Verbindung. Dafür kann man scp oder sftp verwenden, wenn der eigene Account auf der anderen Seite die Daten lesen darf:

myuser@$TRGHOST$ scp $SRCHOST:$PATH/file .
Interessanter wird das dann, wenn die Daten auf der anderen Seite vom eigenen Account nicht gelesen werden können, man also erst einmal sudo bemühen muss, um die Daten lesen zu können. An dieser Stelle versagt scp bereits - es sei denn, man kann sich auf der anderen Seite als anderer User einloggen:
myuser@$TRGHOST$ scp $ANDERER_USER@$SRCHOST:$PATH/file .
Nur, das scheitert oft daran, dass man das Passwort von $ANDERER_USER nicht kennt, nicht neu setzen kann und/oder seinen ssh-Key nicht in $ANDERER_USER/.ssh/authorized_keys fallen lassen kann oder darf.

Continue reading "Daten mit Privilege Escalation abholen über eine named pipe"

fail2ban fuer ssh fuer Arme

Wer einen Server in einschlägig bekannten Netzwerksegmenten (sprich: Bei den großen Housing-Anbietern) betreibt und wenigstens von Zeit zu Zeit mal in dessen Logs guckt kennt es: Irgendwelche Rechner aus Fernost oder anderswo werfen dem ssh-Daemon wild zusammengewürfelte Kombinationen aus Username und Passwort zu und tun dies mit einer bemerkenswerten Persistenz. Und wenn man auf dem System "fremde" User hat, lebt man als Admin stets mit der Angst, dass einer der Versuche der Angreifer irgendwann mal Erfolg hat.

Gegen diesen Typ der Brute-Force-Angriffe sind einige Wässerchen gewachsen, und ich möchte eine kleine Auswahl davon in diesem Artikel vorstellen.

Continue reading "fail2ban fuer ssh fuer Arme"