Skip to topic | Skip to bottom
Linux.AdministratorGeboter1.1 - 01 Nov 2007 - 05:29 - TWikiGuest? [Zum Ende]

Start of topic | Direkt zum Menü

Die 14 Gebote der Administration

Einige einfache Regeln, nach denen es sich leicht leben läßt. Aber Vorsicht: der Teufel steckt im Detail und oft weiss man auch nicht, dass man gerade ein Gebot verletzt, weil man sich mit einem benutzten Programm, Protokoll oder Konzept einfach nicht genug auskennt.

Oft genug gibt es auch Parallelen zur Nicht-Computer-Welt. Solche werden - wenn vorhanden und bekannt - aufgezeigt.

1. Du sollst nicht speichern oder übertragen Passwörter im Klartext.

Passwörter sind sehr sensible Daten. Sie sollten nirgends im Klartext gespeichert werden. Auch sollte man dringend vermeiden, Protokolle wie telnet zum remote-Login zu benutzen, da Passwörter dabei im Klartext übertragen werden.

Hinweise:

  • Einige Programme behaupten, Passwörter verschlüsselt abzuspeichern zu können (Stichwort Passwortsafe, ...). Skeptisch sollte man dann (jedoch nicht nur dann) sein, wenn sich ein Programm Passwörter merkt, man jedoch nach dem Programmstart niemals ein anderes Passwort eingeben muss, um diesen Passwortsafe aufzuschliessen.
  • Andere Programme (z.B. kwalletmanager oder Mozilla Firefox ) benutzen einen Passwort-Safe. Dabei werden die Passwörter in einer verschlüsselten Datei abgelegt. Das Passwort, um diese Datei zu verschlüsseln, muss man dann bei jedem Programmstart eingeben.
  • Ein Passwort, dass per Telefon mitgeteilt wird, wird im Klartext übertragen. Ein Benutzer, der sein Passwort vergessen hat, muss persönlich in der EDV erscheinen (es sei denn, er ist der Direktor - dann muss die EDV natürlich zum Benutzer kommen).
  • Ein Passwort, dass auf dem Post-It am Monitor steht, kann man sich sparen.
  • Ein unverschlüsselt abgelegter SSH-Schlüssel entspricht einem unverschlüsseltem Passwort. Das ist OK, wenn der Schlüssel auf einem Server liegt und das 8. Gebot befolgt wurde - unter ~ottonormaluser/.ssh hat ein nicht-gesicherter Private-Key jedoch nichts verloren.

2. Du sollst möglichst Passwörter gar nicht übertragen.

Authentifikation ist dann am besten, wenn kritische Informationen wie Passwörter oder Schlüssel niemals übertragen werden - unabhängig davon, ob verschlüsselt oder nicht.

Beispiel:

  • SSH ermöglicht Passwort-Authentifikation per PAM, wobei das Passwort im Klartext über einen verschlüsselten Kanal übertragen wird.
    • Probleme:
      • Wenn der verschlüsselte Kanal kompromitiert wird (z.B. weil der Benutzer am Client den Public-Key-Fingerprint des Servers mal wieder zu schnell wegge-"yes"-t hat und gerade eine MITM-Attacke im Gange ist), dann ist das Passwort in fremden Händen.
      • Wenn der Administrator des Servers, auf dem ich mich einlogge, ein böser Bub' ist, kann er mein Passwort mitloggen - schliesslich kommt es beim ihm im Klartext aus dem verschlüsselten Tunnel.
    • Lösung: SSH bietet die Möglichkeit, die Authentifikation per Public-Key-Verfahren durchzuführen, ohne dass der geheime Schlüssel jemals (ob verschlüsselt oder unverschlüsselt) über das Netzwerk übertragen wird.

Hinweis:

  • Kerberos basiert auf zeitlich begrenzten Tickets. Das Passwort wird niemals über das Netzwerk übertragen. Kerberos muss aufgrund seiner Struktur jedoch teilweise gegen das erste Gebot verstossen, da es auf symmetrischer Verschlüsselung basiert. (Mit "teilweise" ist dabei gemeint, dass zwar der alles entscheidende Schlüssel, mit dem man sich als der entsprechende User ausgeben kann, auf dem Server liegt, dieser Schlüssel jedoch keine Rückschlüsse auf das Passwort zuläßt.)

3. Du sollst Passwörter nur selten eingeben.

Single-Sign-On ist nicht nur eine Frage der Bequemlichkeit. Wenn man Passwörter weniger häufig eingeben muss, ist es auch unwahrscheinlicher, dass jemand sieht, wie das eingetippte Passwort lautet.

Besonders sicher ist es, wenn die Authentifikation mit Hardware-Unterstützung geschieht - z.B. per Smartcard oder eToken. Dann muss man sich nur ein kurzes Passwort merken, dass ohne die Spezialhardware nutzlos ist und man profitiert trotzdem von der Sicherheit eines sehr langen "Passwortes" (dem Schlüssel auf der Smartcard/dem eToken).

4. Du sollst keine Mauern bauen, die Du selbst nur schwer überwinden kannst.

Wenn ein System abgesichert werden soll, sollte die Art der Absicherung leicht überschaubar sein. Es ist z.B. Unsinn, mehrere Passwörter eingeben zu müssen - dann kann man auch ein langes Passwort benutzen.

Beispiele:

  • Wenn die Authentifikation besonders sicher sein soll, gibt der Administrator einfach eine Mindeststärke für das Passwort vor (z.B. per cracklib) oder über eine simple Minimallänge.
  • Wenn Automatismen im Rahmen einer Sitzung benutzt werden, die authentifiziert auf Fremdrechner zugreifen (Bsp: ksysguard -Applet unter KDE), dann kann man natürlich mehrmals Passwörter eingeben, um sich per ssh auf die Rechner zu begeben. Besser ist es jedoch, den ssh-agent zu benutzen, wobei nur einmal ein Passwort für den privaten Schlüssel nötig ist.
  • 5 Schlösser an der Wohnungstür nützen nicht mehr als eines - die Tür läßt sich genauso leicht eintreten. Jedoch sind die 5 Schlösser für den Besitzer ein nerviges Hinderniss auf dem täglichen Weg zur Arbeit.

5. Du sollst Benutzern nicht vertrauen.

Benutzer sind keine Administratoren - sie machen Fehler. Man sollte das immer einplanen, indem man dafür sorgt, dass die Fehler das System/Netzwerk maximal zum Stillstand bringen können, jedoch nie Manipulationen durchführen können. Das gilt auch für den Direktor. Dieses Gebot ist leicht verbunden mit dem 12.

Beispiel:

  • Benutzer sollten nur das machen können (wie be able to ), was sie machen dürfen. Ein Verzeichnis, in das kein Benutzer hineindarf sollte deshalb mit den Modebits 0700 versehen werden und nicht mit einem README-File, in dem steht Bitte nicht betreten .
  • Benutzer sollten - wenn es nötig ist - durchaus als root auf ihrer Workstation arbeiten dürfen - jedoch niemals auf einem Server. Das schliesst z.B. auch ein, dass ein normaler Benutzer niemals in einer userlist eines AFS-Servers stehen darf.

6. Du sollst nicht geheimhalten, was öffentlich ist.

Man sollte Daten, die nicht sicherheitsrelevant sind, nicht verschlüsseln. Das kostet nur unnötig Rechenzeit, erhöht die Sicherheit nicht, erzeugt jedoch u.U. trügerische Sicherheit. Auch sind verschlüsselte Übertragungen schwerer zu debuggen

Beispiel:

  • LDAP muss sicher nicht verschlüsselt arbeiten.

7. Du sollst sichern den Host und nicht nur das Netz.

Firewalls sind eine tolle Sache - vor allem um sich gegen automatische Angriffe aus dem Internet zu sichern. Allerdings halten sich ihre positiven Effekte in Grenzen, wenn der Angreifer ein Benutzer des geschützten Netzwerks ist. Die Firewall ist nur eine Verteidigungslinie, die öfter unwirksam ist, als man vermutet. Deshalb sollte man die Rechner selbst absichern.

Hinweise:

  • Unsicher Netzwerkdateisysteme wie NFS arbeiten mit clientbasierter Authentifikation und sind für größere Netzwerke ungeeignet da unsicher. Besser sind Filesysteme wie AFS oder SMB, bei denen serverbasierte Authentifikation eingesetzt wird und nicht die nächstbeste Knoppix bereits zum Sicherheitsrisiko wird.
  • Ein von einem Benutzer (oder von einem als Handwerker getarnten Angreifer) ans Netz angeschlossener WLAN-Router umgeht den Schutz einer Firewall vollkommen und ist schwer zu bemerken.
  • Ein geknacktes Notebook eines Benutzers ist so gut wie ein WLAN-Router.

8. Du sollst abschliessen den Serverraum.

Bis auf wenige Ausnahmen gilt folgende Regel: Der Angreifer, der am Server steht, hat gewonnen.

Wer physischen Zugriff auf einen Rechner hat, ist noch mehr als root - er ist allmächtig .

Hinweise:

  • In gewissen Grenzen kann man diese Regel entschärfen - z.B. durch verschlüsselnde Filesysteme auf Fileservern, bei denen der Schlüssel nur im Speicher gehalten wird. Allerdings hilft das auch nicht weiter, wenn die Daten zu wertvoll sind - dann lohnt es sich u.U. z.B. ein Gerät zu bauen, dass den Arbeitspeicher eines Rechners im laufenden Betrieb dumpen kann (Siehe auch Du sollst kennen den Feind ).
  • Entlohne die Putzfrau bis zur Unbestechlichkeit - ihr Generalschlüssel könnte sonst der Konkurrenz in die Hände fallen.

9. Du sollst kennen den Feind.

Ein System muss man nicht gegen die ganze Welt absichern, sondern nur gegen Angreifer, die mit einer gewissen Wahrscheinlichkeit zu erwarten sind.

Beispiele:

  • Homecomputer sind ein beliebtes Ziel für Personen, die Botnetze aufbauen wollen. Die Angriffe sind automatisiert - wenn man immer fleissig Updates installiert, unnötige Dienste abschaltet und keine Broken-by-Design -Betriebssysteme einsetzt, ist das Risiko gering, dass man das Opfer eines solchen Angriffs wird. Der Anreiz, ein Botnetz aufzubauen, ist zwar finanziell, jedoch gibt es im Internet einfach zu viele ungesicherte Rechner, als dass es sich für den Bösen Bub' lohnen würde, sich an einem einzelnen Rechner die Zähne auszubeissen.
  • Server eines Biotec-Unternehmens sind u.U. ein sehr lohnenswertes Ziel. Wenn die Konkurrenz das noch nicht patentierte Allheilmittel gegen Krebs auf einem Fileserver findet, ist der Schaden schnell im Bereich des BSP einer Industrienation. Entsprechend hoch ist die Motivation, einen solchen Server zu knacken und €10Mio für Dienste von hochbegabten Hackern sind dann für die Konkurrenz nur noch Peanuts.
    Solche Server sollten am besten gar keinen Internet-Zugang haben und es sollte einer einzelnen Person unmöglich sein, die Sicherheit zu gefährden (Stichwort: Single Point of Failure ) - schliesslich könnte man die Frau des Administrators entführen.
  • Kim Jong's Computer ist vermutlich für keine Firma von finanziellem Interesse, jedoch könnte sich u.U. politische Begehrlichkeiten ergeben. Verschlüsselte Daten/Übertragungen lassen sich - etwas Kleingeld vorrausgesetzt (1) - fast immer (2) knacken. In einem solchem Fall muss man über den Tellerrand gucken und mit oft hohem finanziellem Aufwand zusätzlich zur kryptografischen Absicherung starke physische Sicherheitsmassnahmen einplanen.

(1) Das Budget der Amerikanischen Geheimdienste belief sich 1998 auf $ 26.7 Mrd. und ist nach 911 sicher nicht niedriger geworden.

(2) Es existiert nur ein - allerdings üblicherweise unpraktikables - Verfahren, um Daten unknackbar zu sichern: One Time Pad

10. Sichere Kommunikation ist ein Sandwich und keine dicke Scheibe Wurst.

Jegliche verschlüsselte Übertragung kann nur eines leisten - nämlich Daten zwischen zwei gesicherten Kommunikationspartnern (z.B. ein Client und ein Server) über eine ungesicherte Verbindung (z.B. Internet) übertragen.

Beispiele:

  • Oft denken vor allem einfache Benutzer, dass Verschlüsselung ein Allheilmittel gegen Abhören ist und vergessen, dass das Trojanische Pferd auf dem eigenen Rechner ja einfach nur Tastaturanschläge protokollieren muss.
  • Wer aus allen Wolken fällt, wenn seine verschlüsselt zum Online-Händler übertragene Kreditkartennummer missbraucht wird, der sollte sich ins Gedächtnis rufen, dass ein ungesicherter Server ebenfalls die verschlüsselte Übertragung ad. absurdum führen kann (siehe z.B. hier, hier und hier).
  • Was für den geknackten Server gilt, kann man auch auf den Client übertragen. Wenn ich Online-Banking mache und meine TAN verschlüsselt über's Internet schicke, nützt mir die Verschlüsselung gar nichts, wenn auf meinem Rechner ein per Sicherheitslücke eingeschleustes Programm lauert, meine TAN abgreift und zusammen mit Kontonummer und PIN benutzt, um mein hart erspartes Geld nach Rumänien zu überweisen.

Sollte einer (oder beide) der Rechner unsicher sein - z.B. weil ein Angreifer root -Rechte auf einer Workstation erlangt hat - ist die sichere Kommunikation trotz Verschlüsselung hinfällig.

11. Du sollst nicht signieren Dein eigenes Zertifikat.

Ein HTTPS-Server, der sich mit einem selbstsignierten Zertifikat ausweist, verschwendet Rechenzeit. Die Verschlüsselung zwischen einem solchen Server und dem Client schützt nur gegen Lauscher, nicht jedoch gegen Men-in-the-Middle-Angriffe . Solche Angriffe sind heute extrem leicht durchzuführen, wie man anhand zahlreicher Phishing-Attacken in den Medien sieht. Auch gibt es jede Menge Typen solcher Angriffe ( Pharming, DNS-Spoofing, ARP-Poisoning, ...).

Lösung: Besser ist es, eine (meist kostenpflichtige) offizielle Zertifikatskette zu beantragen, womit man dann nur noch den öffentlichen Schlüsseln vertrauen muss, die der Browserhersteller mitliefert.

Beispiele:

  • Wenn ein Herr Meyer sich fantasievoll einen Führerschein druckt, auf dem steht Ausgestellt von Herrn Mayer wird er in der Verkehrskontrolle belächelt - und landet vor dem Richter, wenn er nicht schnell noch einen von der allgemein akzeptierten Instanz Bundesrepublik Deutschland auzsgestellten Führerschein vorweisen kann.
  • Allgemein: Was jemand über sich selbst sagt, hat keinerlei Aussagekraft, wenn ich dieser Person nicht vertraue.

12. Du sollst verifizieren allen Input.

Jedes privilegiert laufende Programm, das gerade von einem nicht privilegierten Prozess mit Daten versorgt wird, muss diese Daten misstrauen bis eine vertrauenswürdige Instanz ihr OK gegeben hat. Das gilt ganz besonders für Programme, die Benutzer authentifizieren/autorisieren sollen.

Das gilt z.B. in folgenden Fällen:

  • Das su -Kommando fragt bei Benutzung das root-Passwort ab, das dann gegen die vertrauenswürdige Passwortdatenbank gecheckt wird. Es wäre albern, ein su -Kommando zu schreiben, dass den Benutzer selbst fragt:
    Sind sie sicher, dass sie root werden dürfen [Y/N]?
  • Ein Benutzer kommt zum Administrator und meint Ich bin Herr XYZ und hab' mein Passwort vergessen. . Das kann ja passieren, aber dass er Herr XYZ ist, kann jeder behaupten.
    Ein von der vertrauenswürdigen Instanz Bundesrepublik Deutschland ausgestellter Personalausweis mit Passbild kann zur Authentifikation herrangezogen werden.
  • Wenn ich im Auto sitze und Links abbiegen will und mein Beifahrer meint gelangweilt Rechts frei , kann ich dem vertrauen. Wenn mir kurz darauf jemand rechts in die Seite kracht, bin ich aber schuld (und der Beifahrer leicht deformiert). Ich sollte den Input Rechts frei deshalb verifizieren und selbst nachgucken.

13. Personals Firewalls schützen nur nach aussen.

Wenn der Feind im inneren ist, muss man die Schutzmassnahmen selbst gegen den Feind - also nach innen - absichern. Personal Firewalls werden häufig nicht nur dazu benutzt, eingehende Verbindungen zu filtern, sondern auch, um ausgehende Verbindungen nur bestimmten Programmen zu erlauben.

Wenn aber nun ein Angreifer bereits auf dem System ist (im Falle von Windows* gibt es eine gute Chance, dass er dann auch Superuser ist), dann braucht er die "Firewall" einfach nur abzuschalten.

Ist die Firewall aber ein Computer im Netzwerk sieht das schon anders aus. Im Idealfall arbeitet die Firewall wie ein Repeater, besitzt keine MAC-Adresse und hat damit keinen Angriffspunkt.

Beispiele:

  • Diverse Würmer schalten bereits bekannte Personal Firewalls ab.
  • Hätten die Trojaner (=Bewohner von Troja, nicht die Griechen) gewusst, wer im Ross steckt, hätten sie die Stadttore innen besser bewacht.
  • Eine per TAN gesicherte Einstellmöglichkeit für das Überweisungslimit beim Onlinebanking ist vollkommen nutzlos , da dem Angreifer ja TANs zur Verfügung stehen.

14. Keep it simple, Stupid!

Das einfach geht, sollte man nicht kompliziert machen. Dieses Gebot sollt eman aber nicht ins extreme strapazieren - besser ist, wenn Komplexität schichtweise daherkommt - z.B. durch eine modular erweiterbaren Protokoll wie XHTML 1.1 .

Hinweise:

  • Komplexität ist das größte Sicherheitsproblem überhaupt. Ein System, das man nicht versteht, kann man nicht wirklich absichern.
  • Wenn schon komplex, dann wenigstens sauber und dokumentiert.
  • Modularität bedeutet Verwaltungsaufwand und damit selbst schon wieder eine gewisse Komplexität.

Beispiele:

  • Im kleinen Netzwerk der eigenen 4 Wände braucht man kein LDAP (auch Du nicht, Torsten ).
  • Wer sich für sendmail entscheidet, wenn es postfix auch tut, dem ist nicht zu helfen. Die Konfiguration ist um ein vielfaches komplexer (manche vergleichen sendmail -Konfigurationsfiles mit uuencode -Output) und damit fehleranfälliger.
  • Wer zope anstelle von apache benutzt, um statische Webseiten auszuliefern, dem ist auch nicht zu helfen.

[Zurück zum Start]

Aktuelle Wiki-Seite: Linux > AdministratorGebote

[Zurück zum Start]