SELFHTML aktuell  Artikel  Serverkonfiguration  SELFHTML Server Konfiguration
	SELFHTML Server Konfiguration: Sicherheits-Konzept
	Copyright  Einleitung  Einbruchs-Stufen  Ziele  Useraccounts  Prozess-Bedingungen  Sonstige Einschränkungen  Was tun im Ernstfall?

Copyright

Das Sicherheits-Konzept hat Oliver Lehmann ausgearbeitet, an dieser Stelle vielen Dank an ihn.

Einleitung

Ein Sicherheitskonzept ist nach meiner Auffassung eine Definition von Bestimmungen, die jeder User, auch der root, einzuhalten haben. Mit Hilfe der aufgestellten Bestimmungen/Regeln möchte ich eine Umgebung schaffen, die den Server stärker, und vor allem bewußter, vor fremdem Zugriff schützt. Fremder Zugriff bedeutet:

• Zugriff von außen über eine Schnittstelle zur DMZ (DMZ = DeMilitarisierteZone, z. B. das Internet) auf den Rechner. Mittelbar über z.b. den Apache und Skripte, sowie unmittelbar über ein Shelllogin.
• Physikalischen Zugriff auf den Rechner. Diesen Gesichtspunkt möchte ich hier jetzt aber mal außer acht lassen.

Einbruchs-Stufen

Ich klassifiziere folgende Stufen des Einbruchs:

• Stufe 1: Jemand hat mittelbaren Zugriff auf den Server.
  Diese Art von Zugriff ist die "ungefährlichste". Damit meine ich nicht etwa, dass diese Art von Zugriff egal wäre. Jeder fremde Eingriff in das System ist tödlich für dessen Glaubwürdigkeit. Was ich damit sagen will, ist, dass der User aufgrund der beschränkten Rechte des Prozesses über den er Zugriff erlangt auch nur sehr beschränkte Rechte im System hat, und damit verhältnismäßig wenig Schaden anrichten kann. Im schlimmsten Fall kann Stufe 1 Stufe 2 gleichgesetzt werden. Nämlich dann, wenn der Angreifer befähigt ist, beliebigen Code auf dem Zielrechner, unserem Server, auszuführen.
• Stufe 2: Jemand erlangt unmittelbaren Zugriff auf den Server.
  Diese Stufe ist wesentlich tragischer für das System. Der User hat direkten Zugriff auf den Server und kann sich ungestört umschauen und Fehlerquellen gemäß seiner Rechte einbauen, auch solche, die evtl. von uns unentdeckt bleiben.
• Stufe 3: Jemand erlangt root Zugriff.
  Das ist wohl die schlimmste vorstellbare Situation. Quasi der "worst case". Diese Stufe kann ohne weiteres nur über Stufe 2 erreicht werden. Ohne weiteres nur, weil ich jetzt davon ausgehe, dass keine der eingesetzten Programme über Sicherheitslöcher, Exploits, etc. verfügt. Dass man davon nicht ausgehen kann, brauche ich glaube ich nicht extra zu erwähnen. Somit kann unter Umständen auch diese Stufe direkt erreicht werden.

Ziele

Unser Ziel muß es nun sein, das Erreichen der einzelnen Stufen soweit wie möglich zu erschweren. Dafür stehen unter UNIX verschiedene Optionen offen. Auf diese Optionen werde ich später noch genauer eingehen.

Wir sollten uns darüber im Klaren sein, dass ein Mehr an Sicherheit auch immer ein Mehr an Belastung für den User mit sich bringt. Diese Diskusion hier soll dazu dienen, den gewissen Mittelpunkt zwischen der Belastung für den User und der Sicherheit des Systems abzuwägen.

Früher sah es so aus, dass wir gar kein Sicherheitskonzept hatten und im Grunde jeder so arbeitet wie er es für sicher/richtig hält. Das man selber nicht immer das "große Ganze" im Auge behält, ist genauso selbstverständlich in meinen Augen wie der Fakt, dass wohl keiner vorsätzlich eine unsichere Stelle ins System einbaut. Wenn doch, dann sei dem jenigen hiermit gesagt, das unsere Rache unvorstellbar sein wird. Nein, mal Spaß beiseite: darüber sollten wir uns alle klar sein. Jeder macht Fehler, das ist normal. Es müssen aber weitestgehend Mechanismen geschaffen werden, die die Fehlern ausbügeln oder, besser noch, verhindern und auffangen.

User-Accounts

1. Passwörter
   
   • Minimale Länge 8 Buchstaben
   • Gross- und Kleinschreibung wechseln
   • Sichern des Passworts als MD5-String in einer Passwort-Datei (nicht World-Readable)
   • Ein Passwort nur für eine bestimmte Zeit zulassen.
     Damit ist gemeint, dass ein Passwort nach z.B. 30 Tagen gewechselt werden muß. Das halte ich für äußerst wichtig! Alleine schon aus dem Grund, dass man so diese "Ich habe ein Passwort für alles"-Schiene recht gut ausschalten kann.
   • Eine Woche vor Ablauf des Passworts wird der User täglich benachrichtigt
2. Logins
   • Nach 20 erfolglosen Logins wird ein User-Account deaktiviert.
     Das heißt nicht, dass er gelöscht wird, sondern nur, daß von diesem Useraccount aus kein Login mehr möglich ist.
   • Die Idle-Time wird auf 30 Minuten begrenzt. Ein User muß nicht stundenlang auf einer Shell rumhocken um nichts zu tun.
3. Prozess-Limits
   • CPU-Zeit-Limit eines Eserprozesses
     Damit soll verhindert werden, dass ein User die CPU des Rechners z.B. 24h lang mit 100% Last belegt. Jeder Prozess, der länger als 2 Stunden läuft, wird gekillt¹.
   • Speicherbeschränkung
     Wenn ein Userprozess 1Gb RAM verbraucht, läeft da was falsch... kein Prozess sollte mehr als 20% RAM verbrauchen¹.
   • Maximale Anzahl an Prozessen pro User¹ (z. B. 15)
     Dieser Wert sollte gesetzt werden, wenn auch recht hoch. Ich kann ein System auch mit einem Einzeiler in Perl "ausschalten", wenn ich eine Endlosschleife mache, die nichts anderes macht als sich selber zu forken, sprich lauter Kindprozesse erstellt. So werden so lange Prozesse generiert, bis das System abstürzt (also so mehrere (100)tausende konkurrierende Prozesse).

1) Die Punkte zu den Passwörtern und Logins sollen zum größten Teil einen Schutz gegen das Erreichen von Stufe 2 dienen. Der Punkt "Prozesslimits" dient zum Schutze des Servers durch fehlerhafte Scripte, aber auch wenn Stufe 2 berreits erreicht ist, da es dem Angreifer so erschwert wird, den Server so zu belasten, dass dieser ausfällt.

Prozess-Bedingungen

• Usergruppen
  Ein Dämon, der eine Verbindung zwischen DMZ und Server darstellt, sollte Grundsätzlich a) nicht als root laufen und b) kein anderer User darf in der Gruppe sein, in der dieser Dämon ist. Wieso nicht? Nun, wird Stufe 2 erreicht, hat dieser User u.U. Zugriff auf Prozesse des Dämons sowie auf Dateien und Verzeichnisse, wenn diese Group-writable/executable/readable sind. Ein Bsp.: Der Apache. Erreicht ein Angreifer über einen User Zugriff, der in der Gruppe ist in der sich der Apache befindet, dann hat er zu allen Verzeichnissen mindestens Lesezugriff. Zu bestimmten auch Schreibzugriff. Ich erwähne nur die Forumsdateien.
• Fake-Root
  Man sollte darüber nachdenken, Prozesse, die eine Verbindung zur DMZ haben, in ein sogenanntes "Fake-Root" zu stecken. Das heißt kurz erklärt, dass der Prozess selber nicht mehr auf das wirkliche Dateisystem unterhalb seines Start-Verzeichnisses zugreifen kann, sondern fuer ihn ist "/" irgendwo im realen Filesystem. Damit kann sich der in Stufe 1 befindliche Hacker nich mehr oder zumindest nur äußerst schwer (irgendwie kann man alles umgehen) Zugriff auf Dateien verschaffen, die außerhalb des Fake-Roots liegen. Ein Beispiel: der Apache wird mit einem Fake-Root Programm gestartet (üblicherweise chroot), welches ihm vorgaukelt "/home/www" waere "/". Nun ist es dem Apachen nicht mehr möglich, Zugriff auf Dinge zu erlangen, die oberhalb von "/home/www" liegen. Somit kann z.B. auch nicht auf /etc/passwd mit den Useraccounts zugegriffen werden.

Sonstige Einschränkungen

• Wichtige Systemdateien
  ... sollten grundsätzlich "irgendwo" Im Filesystem, besser gar nicht auf dem Rechner selber, gesichert werden. Diese Sicherung soll dazu dienen, zu "checken" ob sich an den Dateien, wie z.b. der passwd, den Cronjobs, usw. etwas gändert hat. Die passwd wird z.b. bereits vom System solch einer Prüfung unterzogen. Diese ist aber ungenügend, weil sie in einem jedem versierten User bekantem Verzeichnis gesichert wird. Die Sicherung muss "versteckt" erfolgen. Es ist verständlich, dass auch ein ambitionierter Angreifer diese Backups finden und modifizieren kann. Dagen kann man sich z.b. durch Checksummenprüfung schützen. Ein wichtiger Punkt ist auch die Rechte-Verteilung. Wichtige Systemdateien sollten äußerst restriktive Zugriffsrechte haben. Was "wichtige systemdateien" sind, muß wie auch vieles andere erst noch konkretisiert werden.
• Checksummen
  Dateien unter /bin und /sbin sollten regelmäßig auf Authentität geprüft werden. Auch dies übernimmt das System bereits. Aber wie auch bei den oberen Punkten erfolgt der Checksummen-Vergleich auf dem Rechner selbst. Durch Verlagerung des Checksummen-Vergleiches auf ein externes System kann das ganze sehr sicher gemacht werden. Wechselt ein Angreifer eine Systemdatei, wie z.b. ls oder ps oder Sonstiges aus um Dinge vor dem Anwender zu verstecken, hat sich natürlich die Checksumme des Tools gäendert. Nun kann der Angreifer natürlich auch hingehen und das Programm austauschen, welches die Checksummen generiert.... es gibt immer einen Weg, aber deswegen müßen wir ja nicht gleich Tür und Tor aufmachen.
• Gelegendliche Diskchecks
  Einem Eindringling kann es möglich sein, Daten direkt auf das Dateisystem zu schreiben. Daten, die z.B. erst nach einem Reboot Wirkung zeigen und bis dahin gänzlich unentdeckt bleiben. Ein gelegentlich ausgeführtes fsck (File System Check) wirkt dem entgegen. Ist auf dem Dateisystem etwas nicht so, wie es sein sollte, wird, wenn möglich, der "Fehler" behoben.

Was tun im Ernstfall?

Was auch noch zu bedenken wäre, sind sogenannte "Szenarien" oder "Notfallplaene", also was getan wird, wenn ein Fremdzugriff registriert wurde. Es ist recht wichtig, dass dann nichts "unueberlegtes" getan wird, sondern vorher das Ganze bedacht wurde. Natürlich wird es immer Fälle geben, die man nicht vollständig bedacht hat, aber sich gar keine Gedanken über den "Was ist wenn"-Fall zu machen halte ich für viel schlimmer. Sinnvolle Maßnahmen wären z. B.

• Das löschen des User-Accounts, durch den der Angreifer Zugriff erlangte, bzw. das Abschalten/Updaten der Software.
• Das ändern der Passwörter der auf dem System befindlichen User
• Das Wiederherstellen der Orginal-Konfiguration
• Das Einleiten von rechtlichen Schritten gegen den Angreifer, soweit identifizierbar

Tja, wenn euch irgendwelche Schwachstellen oder ähnliches auffallen, gebt mir bitte bescheid!

 SELFHTML aktuell  Artikel  Serverkonfiguration  SELFHTML Server Konfiguration

© 2007  Impressum