Sicherheit bei Remote-Administration

[daemotron]

Moin moin,

ich bin gerade dabei, mir ein Tool zu schnitzen, mit dem ich mehrere Server und Jails bequem vom heimischen Rechner aus konfigurieren und verwalten kann [1]. Der Zugang zum entfernten System soll dabei über SSH erfolgen; allerdings stellt sich hier jetzt die Frage nach der Sicherheit eines solchen Zugangs.

Bisher gibt es auf meinen Servern einen "normalen" User, und nur dieser darf sich per SSH einloggen. root-Rechte erwirbt dieser normalerweise, indem er su nutzt. Aus praktischen Erwägungen heraus lässt sich diese Vorgehensweise nicht nachbilden, was auch mit dem Aufbau des SSH-Protokolls zusammenhängt: Jeder Befehl wird in einem neuen Channel abgefeuert; der Kontext bleibt also nur erhalten, wenn gleich der erste Befehl selbst einen Kontext herstellt, in dem dann alles weitere geschieht (z. B. eine Shell, was sich dann von außen nur schwer bis gar nicht skripten lässt).

Ich sehe daher drei theoretisch mögliche Vorgehensweisen:

1. Anders als bisher darf root sich doch direkt per SSH einloggen, natürlich beschränkt auf Public Key Authentication
2. Es darf sich weiterhin nur ein normaler User einloggen; dieser darf aber sudo ohne Passworteingabe nutzen
3. Es darf sich weiterhin nur ein normaler User einloggen; dieser spawnt als erstes eine Shell, in deren Kontext dann alles weitere abläuft.

Meine Pro's und Con's:
Pro a: Einfach umzusetzen, PubKey sehr schwer zu knacken
Contra a: root ist ein bekannter Account => minimaler Vorteil bei einem Brute Force Angriff

Pro b: Immer noch relativ einfach umzusetzen, PubKey sehr schwer zu knacken, kein bekanntes User-Handle
Contra b: sudo ohne Passwort-Schutz => wer in den Account reinkommt, ist faktisch root

Pro c: PubKey sehr schwer zu knacken, kein bekanntes User-Handle, selbst bei erfolgreichem Einbruch noch keine root-Rechte
Contra c: Sehr komplex (und damit fehleranfällig) in der Umsetzung, root-Passwort muss irgendwie lokal gespeichert werden

Momentan tendiere ich zu Variante a., da ich den tatsächlichen Sicherheitsgewinn der Varianten b. und c. als sehr gering einschätze - wie seht Ihr das? Habe ich ggf. etwas übersehen?



[1] https://github.com/daemotron/controlbeast

[ddm3ve]

Ich würde für Dein Vorhaben SVN oder Github nehmen und ein Puppet laufen lassen.

Puppet zieht sich die Daten aus dem Repository und Du commitest Deine Änderungen. Puppetrun zieht sich dann alle 5-10 Minuten, so wie Du es willst, die Änderungen vom puppet master. der wieder erhält sein update eben aus dem Repository.

[daemotron]

Puppet war im Prinzip Vater des Gedankens, bietet aber nicht ganz, was ich suche. Puppet setzt AFAIK eine serverseitige Komponente voraus, auf die ich gerne verzichten möchte, da ich ein push-getriebenes Deployment vorziehe. Da passt Ansible vom Ansatz her besser, ist aber eher dazu geeignet, die Konfiguration von Diensten auf dem laufenden System zu steuern, als das System selbst (Versions-Audits etc.).

[Joe User]

Ich würde bei allen drei Varianten dem jeweiligen User auf jeden Fall schonmal alle nicht benötigten SSH-Features bereits beim erstellen des mindestens 4096 bit langen RSA-Key entziehen:

Code: Select all

ssh-keygen -t rsa -b 4096 -O clear -O permit-pty

Die Manpage zu ssh-keygen ist da relativ interessant, fiel mir auch erst vor drei Wochen ins Auge :-/

Ansonsten wäre meine Präferenz a vor b und c würde wegen der früher oder später zwangsläufig auftretenden Probleme raus.
b bietet gegenüber a aber keinen echten Vorteil mehr, zumindest wenn man sich den FD-Thread OpenSSH User Enumeration Time-Based Attack durchliest und besser umsetzt.

[ddm3ve]

Puppet war im Prinzip Vater des Gedankens, bietet aber nicht ganz, was ich suche. Puppet setzt AFAIK eine serverseitige Komponente voraus, auf die ich gerne verzichten möchte, da ich ein push-getriebenes Deployment vorziehe. Da passt Ansible vom Ansatz her besser, ist aber eher dazu geeignet, die Konfiguration von Diensten auf dem laufenden System zu steuern, als das System selbst (Versions-Audits etc.).

Dann würde ich es so lösen wie wir bis vor der Umstellung von puppet. Setzt jedoch root rechte vorraus.

Im Grunde ganz einfach. Alle Konfigurationen werden seitens SVN abgelegt und verwaltet. Dabei gibt es folgende Hirachie und setzt eine einheitliche Namensgebung der Server vorraus.

/SRV/CONFIG/MYDBMS/etc/hosts
/SRV/CONFIG/MYDBMS001A/etc/ha.cnf
/SRV/CONFIG/MYDBMS001AA/etc/networks/if.cfg/...
/SRV/CONFIG/MYDBMS001AB/etc/networks/if.cfg/...
/SRV/CONFIG/MYDBMS001B/etc/ha.cnf
/SRV/CONFIG/MYDBMS001BA/etc/networks/if.cfg/...
/SRV/CONFIG/MYDBMS001BB

die Konfiguration/Aufteilung hierbei war sehr simpel.
MYDBMS z.B. spezifiziert global für eine Datenbanksytem notwendige Features. Im Übrigens auch fertige Installationsscripte um z.B. Storage an zu passen, binaries zu installieren usw.

MYDBMS001A umfasst den 1. CLuster (Fortlaufende Alphanumerische Nummerierung je Kundensystem / Projekt.
Hier finden sich alle für den cluster relevanten Konfigurationen. Also die Gemeinsame Menge aller Konfigurationen für diesen Cluster.

MYDBMSAA ... -> Erste aktive Node des A Clusterverbundes. Hier finde sich nur noch die für den individuellen Host relevanten Konfigurationen.


Das Script dahinter machte bei uns im wesentlichen nur folgendes.
Alles vor der 1. Zahl in der Bezeichnung sind Klassen spezifische Definitionen. In diesem Fall mysql Datenbanken.
Für eine Erstinstallation wird genau dieses heran gezogen und mit wenigen Parameter auf die Zielsystem ausgerollt.
I.d.R. werden hierzu auch Templates verarbeitet und z.B.für die einzelnen Nodes oder Cluster vorbereitet.
Im Anschluss werden alle generierten Dateien auf das Zielsystem gesynct.
Die Reihenfolge lautet dabei:

Klasse, Projekt, Gruppe, Single Node.
Ich hoffe Du kannst der kurzen Ausführung folgen.
Wir hatten es damals einfach selbst gescriptet, weil es zu damaliger Zeit keine "Alternative" gab.
Beim Rollout z.B. werden auch Scripte und Libs unter /opt/ gesynct und im anschluss eine setup.sh ausgeführt was wiederum Templates anhand echter lokaler Daten verarbeitet. So z.B. per DHCP gezogene IP Adressen, Interface Bezeichnungen, Mac Adressen.
Diese Daten wiederum werden in einer Art CMDB inventarisiert und dienen zukünftig als Basis für die Verarbeitung der Templates.

BTW: SSh Zugriff für den Key und root wurde auf einen oder wenige Quellhosts reduziert.
z.B. from="127.0.0.1,127.0.0.2" ssh-rsa AAAA........

Zusätzlich liese sich ein root zugriff verhindern wenn Du einen alternativen Benutzer mit UId GID 0 erzeugst und diesen nutzt.
Damit sollte zumindest eine Brutforce Attacke auf Benutzer root ins leere laufen.
Allerdings finde ich eine normale absicherung per SSH Key und eine entsprechende Verschlüsselung für absolut ausreichend so dass man auf diesen Workaround verzichten kann.




Das entspricht ja Deiner Variante A. Wenn jetzt auch etwas ausführlicher erklärt wie wir das damals organisiert haben.