Einführung

Diese Webseite gibt Einsteigern und erfahrenen Benutzern Hilfestellungen zum Thema Sicherheit. Bei FreeBSD wird Sicherheit groß geschrieben: Wir arbeiten ständig daran, das Betriebssystem so sicher wie möglich zu machen.

Im Folgenden finden Sie Informationen zu verschiedenen Sicherheitsaspekten, beispielsweise wie Sie ein System vor bestimmten Angriffen schützen und wenn Sie ansprechen können, wenn Sie einen sicherheitsrelevanten Fehler finden. Ein gesonderter Abschnitt für Entwickler erläutert Maßnahmen, die Sicherheistlücken in Programmen verhindern.

Inhalt

• Der FreeBSD Security-Officer
• Umgang mit Informationen
• FreeBSD Sicherheits-Hinweise
• Mailinglisten zum Thema Sicherheit
• Richtlinien zum sicheren Programmieren
• FreeBSD sichern
• Maßnahmen bei einem Sicherheitsvorfall

Der FreeBSD Security-Officer und das Security-Officer-Team

Um zügig sicherheitsrelevante Informationen mit anderen auszutauschen, besitzt das FreeBSD Project einen zentralen Ansprechpartner: Den FreeBSD Security-Officer.

Wenn Sie ein Sicherheitsproblem an das FreeBSD Project melden wollen, schreiben Sie eine E-Mail an den Security-Officer. Beschreiben Sie in der E-Mail die entdeckte Sicherheitslücke.

Damit Sicherheitsprobleme schnell bearbeitet werden, wird die E-Mail an das Security-Officer Alias an vier Personen ausgeliefert: den Security-Officer, den Deputy-Security-Officer und zwei Mitglieder des Core-Teams. Zurzeit werden E-Mails an <security-officer@FreeBSD.org> an die folgenden Personen geliefert:

Der Security-Officer wird vom FreeBSD-Security-Team <security-team@FreeBSD.org> unterstützt. Das Team besteht aus einer Gruppe von Committern, die vom Security-Officer ausgewählt werden.

Verschlüsseln Sie E-Mails mit dem PGP-Schlüssel des Security-Officers, wenn dies erforderlich ist.

Umgang mit Informationen

Generell veröffentlicht der Security-Officer nach einer angemessenen Zeit alle Informationen über ein Sicherheitsproblem. Die Zeitspanne erlaubt eine sichere Analyse und die Behebung des Sicherheitsproblems und dient auch zum Testen der Korrektur sowie der Koordination mit anderen Betroffenen.

Der Security-Officer wird einen oder mehrere der Administratoren des FreeBSD-Clusters über Sicherheitsprobleme informieren, die Ressourcen des FreeBSD Projects bedrohen.

Der Security-Officer kann weitere FreeBSD-Entwickler oder externe Entwickler hinzuziehen, wenn dies zur Beurteilung oder Lösung des Sicherheitsproblems notwendig ist. Ein diskretes Vorgehen verhindert die unnötige Verbreitung des Sicherheitsproblems. Alle hinzugezogenen Experten handeln entsprechend den Richtlinien des Security-Officers. In der Vergangenheit wurden Experten wegen ihrer immensen Erfahrungen mit komplexen Komponenten des Systems, wie dem FFS, dem VM-System und dem Netzwerkstack, hinzugezogen.

Wenn gerade ein Release erstellt wird, kann der FreeBSD Release-Engineer ebenfalls über das Sicherheitsproblem und dessen Ausmaße unterrichtet werden. Damit können fundierte Entscheidungen über den Ablauf der Release-Erstellung und die Auswirkungen der Sicherheitsprobleme auf das kommende Release getroffen werden. Auf Anfrage gibt der Security-Officer nur die Existenz des Sicherheitsproblems und dessen Schwere an den Release-Engineer weiter.

Der Security-Officer arbeitet eng mit anderen Organisationen zusammen. Dazu zählen Dritthersteller, die Quellcode von FreeBSD benutzen (OpenBSD, NetBSD, Apple und andere Hersteller, die Software auf Basis von FreeBSD vertreiben, sowie die Linux-Vendor-Security Liste) und Organisationen, die Sicherheitsproblemen und Sicherheitsvorfällen nachgehen, beispielsweise das CERT. Oft haben Sicherheitsprobleme Auswirkungen, die über FreeBSD hinausgehen. Sie können auch (vielleicht weniger häufig) große Teile des Internets betreffen. Unter diesen Umständen wird der Security-Officer andere Organisationen über das Sicherheitsproblem informieren wollen. Wenn Sie das nicht wünschen, vermerken Sie das bitte explizit beim Einreichen eines Sicherheitsproblems.

Besondere Anforderungen an den Umgang mit den eingereichten Information müssen ausdrücklich angegeben werden.

Wenn die Veröffentlichung des Sicherheitsproblems mit dem Einsender und/oder anderen Lieferanten abgestimmt werden soll, so muss dies ausdrücklich beim Einreichen des Problems angegeben werden. Ist dies nicht vermerkt, legt der Security-Officer einen Zeitplan für die Veröffentlichung des Problems fest. Der Zeitplan berücksichtigt die möglichst schnelle Veröffentlichung und die zum Testen von Lösungen benötigte Zeit. Wenn das Problem schon in öffentlichen Foren (wie Bugtraq) diskutiert wird und ausgenutzt wird, kann der Security-Officer einen anderen als den vorgeschlagenen Zeitplan verwenden. Dies dient dem maximalen Schutz der Benutzergemeinde.

Einsender von Sicherheitsproblemen sollte bewusst sein, dass FreeBSD ein Open-Source-Projekt ist. Jede Änderung des FreeBSD-Quellbaums ist öffentlich und jedem zugänglich. Stellt der Einsender einen Zeitplan zur Verfügung, sollte der Plan die Zeitspanne zwischen der Aufnahme der Fehlerbehebung in den Quellbaum und der Veröffentlichung berücksichtigen. Die Zeitspanne ist nötig, da der Hinweis, die Fehlerbehebungen und die binären Patche mithilfe eines Versionierungs-Systems erstellt werden,

Eingesendete Sicherheitsprobleme können mit PGP geschützt werden. Auf Wunsch werden die Antworten ebenfalls mit PGP geschützt.

FreeBSD Sicherheits-Hinweise

Der FreeBSD-Security-Officer gibt Sicherheitshinweise für verschiedene FreeBSD-Entwicklungszweige heraus: Die -STABLE-Zweige und die Sicherheits-Zweige. Für den -CURRENT-Zweig werden keine Sicherheitshinweise herausgegeben.

• Normalerweise gibt es nur einen -STABLE-Zweig. Bei einem Übergang von einer Hauptversion zu einer neuen Hauptversion (wie von FreeBSD 4.X zu 5.X) gibt es allerdings zeitweise zwei -STABLE-Zweige. Die Tags der -STABLE-Zweige haben Namen wie RELENG_4. Die daraus gebauten FreeBSD-Versionen werden beispielsweise FreeBSD 4.6-STABLE genannt.

• Jedes FreeBSD-Release besitzt einen Sicherheits-Zweig. Die Tags der Sicherheits-Zweige haben Namen wie RELENG_4_6. Die daraus gebauten FreeBSD-Versionen tragen Namen wie FreeBSD 4.6-RELEASE-p7.

Jeder Zweig wird vom Security-Officer nur für eine begrenzte Zeit unterstützt, typischerweise für 12 Monate nach der Veröffentlichung. Wann die momentan unterstützten Releases auslaufen, ist in der Tabelle unten aufgeführt. Die Spalte Wartungsende gibt den frühest möglichen Zeitpunkt an, an dem ein Zweig ausläuft. Beachten sie, dass die Zeitpunkte nach hinten verschoben werden können, aber nur besondere Umstände dazu führen, dass ein Zweig vorher aus der Wartung genommen wird.

Ältere Releases werden nicht mehr gepflegt. Benutzer solcher Releases sollten dringend auf eine oben aufgeführte unterstützte Release aktualisieren.

Wie alle Entwicklungen werden Fehlerbehebungen zuerst in den FreeBSD-CURRENT-Zweig gebracht. Nach einigen Tagen und Abschluß der Tests wird die Fehlerbehebung auf die unterstützten -STABLE-Zweige angepasst und der Sicherheitshinweis wird veröffentlicht.

Ein paar Zahlen zu den im Jahr 2002 veröffentlichten Hinweisen:

• 44 Hinweise von unterschiedlicher Schwere betrafen das Basissystem.
• 12 Hinweise davon betrafen nur FreeBSD. Die restlichen 32 Hinweise betrafen auch mindestens ein anderes Betriebssystem. Dies wurde hauptsächlich durch gemeinsam benutzte Code-Teile verursacht.
• Es wurden 6 Mitteilungen herausgegeben, die auf 95 Probleme mit Software Dritter aus der Ports-Collection hinwiesen.

Die Hinweise werden an die folgenden FreeBSD-Mailinglisten versendet:

• FreeBSD-security-notifications@FreeBSD.org
• FreeBSD-security@FreeBSD.org
• FreeBSD-announce@FreeBSD.org

Die Hinweise werden immer mit dem PGP-Schlüssel des FreeBSD-Security-Officers signiert. Die Hinweise werden zusammen mit den Fehlerbehebungen in unserem FTP CERT-Repository abgelegt. Zurzeit sind folgende Hinweise verfügbar (die Liste kann ein paar Tage alt sein, die neusten Hinweise finden Sie auf unserem FTP-Server):

Mailinglisten zum Thema Sicherheit

Wenn Sie ein FreeBSD-System administrieren oder benutzen, sollten Sie eine oder mehrere der nachstehenden Listen abonnieren:

Richtlinien zum sicheren Programmieren

• Vertrauen Sie keinen Eingaben wie Kommandozeilenargumenten, Umgebungsvariablen, Konfigurationsdateien, eingehenden TCP/UDP/ICMP-Paketen, Namensauflösungen und Funktionsparametern. Wenn Sie die Länge der eingehenden Daten oder die eingehenden Daten selbst nicht kontrollieren können, sollten Sie vorsichtig beim Kopieren der Daten sein. Achten Sie insbesondere auf die folgenden Punkte:
  • Aufrufe von strcpy() und sprintf() mit Daten unbekannter Länge. Wenn die Länge bekannt ist, verwenden Sie strncpy() und snprintf() (oder sorgen Sie selbst dafür, dass Puffer nicht überschrieben werden, wenn die Länge unbekannt ist). Verwenden Sie nie gets() oder sprintf(), Punkt!
  • Wenn Sie Benutzereingaben auf unerwünschte Zeichen prüfen, suchen Sie nicht nach diesen unerwünschten Zeichen. Prüfen Sie stattdessen, dass die Eingabe nur aus erlaubten Zeichen besteht. Die allgemeine Regel lautet: Verbieten Sie alles, was nicht ausdrücklich erlaubt ist.
  • Lesen Sie die Hilfeseiten der Funktionen strncpy() und strncat(). Sie müssen verstanden haben, wie die Funktionen arbeiten. Mit strncpy() wird die abschließende \0 vielleicht nicht angehängt, mit strncat() schon.
  • Achten Sie auf den Missbrauch der Funktionen strvis() und getenv(). Bei strvis() ist oft der Ziel-String zu kurz. getenv() kann längere Zeichenfolgen zurückgeben als Sie erwarten. Beide Funktionen werden oft ausgenutzt um ein Programm anzugreifen. Meist wird dabei der Stack oder Variablen überschrieben oder Umgebungsvariablen enthalten unerwartete Werte. Wenn Ihr Programm Umgebungsvariablen benötigt, werden Sie paranoid, werden Sie richtig paranoid!
  • Jedes Mal, wenn Sie die Funktionen open() oder stat() benutzen, fragen Sie sich: "Was passiert, wenn die Funktionen auf einen symbolischen Link angewendet werden?"
  • Benutzen Sie mkstemp() anstelle von Funktionen wie mktemp() oder tempnam(). Achten Sie auf Race-Conditions insbesondere im Verzeichnis /tmp. Es gibt nur wenige atomare Operationen in Verzeichnissen:
    • Anlegen eines Verzeichnisses. Diese Operation gelingt oder schlägt fehl.
    • Öffnen einer Datei mit O_CREAT | O_EXCL.
  • Legen Sie temporäre Dateien immer mit mkstemp(), an, da mit dieser Funktion Race-Conditions und falsche Zugriffsrechte verhindert werden.
  • Wenn ein Angreifer Pakete auf ein beliebiges System umleiten kann, dann hat er die vollständige Kontrolle über Daten, die wir erhalten. Diesen Daten kann nicht vertraut werden.
  • Setzen Sie nie voraus, dass eine Konfigurationsdatei richtig formatiert ist oder mit dem passenden Werkzeug erstellt wurde. Verlassen Sie sich nicht darauf, dass Benutzereingaben, wie Terminalnamen oder Spracheinstellungen, frei von Zeichenfolgen wie '/' oder '../../../' sind, wenn diese Eingaben in Pfadnamen verwendet werden können. Mißtrauen Sie jeder Pfadangabe des Benutzers, wenn ein Programm unter root-Rechten (SUID) läuft.
  • Achten Sie auf Sicherheitslöcher, wenn Daten gespeichert werden. Um unberechtigte Zugriffe zu verhindern, werden temporäre Dateien mit den Zugriffsrechten 600 angelegt.
  • Beschränken Sie sich nicht auf die üblichen Verdächtigen, wenn Sie ein Programm mit erhöhten Rechten kontrollieren. Prüfen Sie Zeile für Zeile des Programms, da es neben strcpy() noch viele andere Ursachen für Pufferüberläufe gibt.
  • Die Aufgabe erhöhter Rechte alleine verhindert keinen Einbruch. Ein Angreifer kann Code auf dem Stack platzieren, der die Rechte wiedererlangt, bevor /bin/sh ausgeführt wird.
• Verwalten Sie UIDs, geben Sie erhöhte Rechte so schnell wie möglich auf und geben Sie die Rechte wirklich auf. Es ist unzureichend, zwischen der EUID und der UID zu wechseln. Benutzen Sie die Funktion setuid() wo Sie können.
• Verzichten Sie im Fehlerfall auf die Ausgabe von Konfigurationsdateien. Eine Zeilennummer und vielleicht die Spaltennummer der Zeile reichen völlig aus. Dies gilt für alle Bibliotheken und Programme, die SUID oder SGID laufen.
• Wenn Sie Quelltext auf Sicherheitsprobleme untersuchen, beachten Sie bitte die nachstehenden Hinweise:
  • Arbeiten Sie mit einem zweiten Prüfer zusammen. Wenn Sie sich bei einer Problembehebung nicht ganz sicher sind, lassen Sie die Behebung durch den zweiten Prüfer begutachten. Falls Sie sich unsicher sind, ändern Sie nichts. Es ist peinlich, wenn durch die Behebung eines Sicherheitsproblems neue Probleme entstehen.
  • Zu den letzten, die eine Problembehebung prüfen, sollte jemand mit commit-Rechten gehören. Diese Person wird die Problembehebung nochmals begutachten und in den CVS-Baum einbringen.
  • Schicken Sie Änderungen zur Begutachtung immer im context- oder unified-Ausgabeformat von diff ein; die Änderungen können so leicht mit patch(1) weiterverarbeitet werden. Reichen Sie nicht die vollständigen Dateien ein. Die Differenzen sind leichter zu lesen und lassen sich leichter auf einen lokalen Quellbaum anwenden, besonders wenn sie mehrere Änderungen enthalten. Erzeugen Sie die Differenzen bitte aus dem -CURRENT-Entwicklungszweig.
  • Testen Sie immer die Änderungen (übersetzen Sie die betroffenen Quellen und lassen Sie das neue Programm laufen), bevor Sie Änderungen einschicken. Niemand will kaputte Fehlerbehebungen prüfen und das Vertrauen in den Ersteller der Behebung sinkt, weil er sich offensichtlich nicht die Mühe gemacht hat, die Änderung zu prüfen. Wenn Sie Zugang zu Maschinen brauchen, auf denen eine bestimmte Software-Version installiert ist, fragen Sie einfach. Genau für solche Fälle besitzt das Projekt die entsprechenden Mittel.
  • Anmerkung für Committer: Stellen Sie Problembehebungen aus -CURRENT auch in -STABLE ein, wenn es nötig ist.
  • Passen Sie den Quelltext nicht grundlos an Ihren Stil oder ihre Vorlieben an – das erschwert die Begutachtung der Änderung nur unnötig. Führen Sie nur dann Stiländerungen durch, wenn es dafür berechtigte Gründe gibt.
• Achten Sie auf Programme, die komplizierte Funktionen zur Signalbehandlung besitzen. Viele Funktionen verschiedener Bibliotheken sind nicht reentrant
• Schauen sie sich den Gebrauch der Funktion realloc() genau an – die Funktion wird oft falsch verwendet.
• Wenn Sie feste Puffergrößen verwenden, benutzen Sie die Funktion sizeof(). Sie verhindert Fehler, wenn die Puffergröße verändert aber der restliche Quelltext nicht angepasst wird. Ein Beispiel:

          char buf[1024];
          struct foo { ... };
          ...
  SCHLECHT:
          xxx(buf, 1024)
          xxx(yyy, sizeof(struct foo))
  GUT:
          xxx(buf, sizeof(buf))
          xxx(yyy, sizeof(yyy))
      

  Verwechseln sie nicht die Größe eines Zeigers mit der Größe der Daten, auf die der Zeiger zeigt!
• Wenn Sie char foo[###] sehen, prüfen Sie jeden Gebrauch der Variablen foo und stellen Sie sicher, dass kein Pufferüberlauf möglich ist. Wenn Sie einen Pufferüberlauf nicht verhindern können (das gibt es wirklich), fordern Sie den Speicher für den Puffer wenigstens mit malloc() an. Dies verhindert mögliche Zugriffe auf den Stack.
• Schließen Sie Dateideskriptoren so schnell wie möglich – die stdio-Puffer werden so wahrscheinlich schneller entleert. In Bibliotheksfunktionen müssen Dateideskriptoren immer close-on-exec (sie werden nach fork()/exec() automatisch geschlossen) angelegt werden.

Der Port its4 ist ein brauchbares Audit-Werkzeug. Sie finden den Port unter /usr/ports/security/its4/. Der Port prüft automatisch C-Quelltexte und zeigt Problemstellen auf. Das Werkzeug ist für eine erste Prüfung gut geeignet, allerdings sollten Sie sich nicht nur auf den Port its4 verlassen. Ein vollständiger Audit sollte von einem Menschen durchgeführt werden, der den ganzen Quelltext untersucht.

Zusätzliche Ressourcen und mehr über sicheres Programmieren finden Sie auf der Webseite How to Write Secure Code.

FreeBSD sichern

FreeBSD, oder jedes andere &unix; System, können Sie mit den nachstehenden Schritten sichern:

• Deaktivieren Sie potentiell gefährliche Programme:
  Viele Programme laufen unter besonders berechtigten Benutzern (SUID), um auf bestimmte Ressourcen zuzugreifen. UUCP oder PPP zum Beispiel benötigen einen speziellen Netzwerk-Port, sendmail benötigt Zugriff auf das Spool-Verzeichnis und einen speziellen Netzwerk-Port. Wenn Sie UUCP nicht verwenden, können Sie es auch deaktivieren. Natürlich müssen Sie Ihr System gut kennen, um entscheiden zu können, welche Programme Sie nicht benötigen und welche Programme Sie vielleicht später einmal benötigen werden.
  Einige Werkzeuge, wie swapinfo, die Sie vielleicht nicht besonders nützlich finden, stellen ebenfalls ein Sicherheitsrisiko dar. Wenn Sie mit chmod ug-s filename das SUID-Bit des Programms entfernen, können Sie swapinfo immer noch als root ausführen. Es ist allerdings keine gute Idee so viele SUID-Bits zu entfernen, dass Sie nur noch als root arbeiten können.
  Neben Programmen sollten Sie auch Dienste deaktivieren, die Sie nicht benötigen. In den Dateien /etc/inetd.conf und /etc/rc.conf sollten Sie alle Dienste deaktivieren, die Sie nicht benutzen.
• Schließen Sie Sicherheitslöcher (oder wie Sie den Crackern einen Schritt voraus sind):
  Abonnieren Sie die FreeBSD Sicherheits-Mailinglisten. So erhalten Sie Informationen über Sicherheitslöcher und deren Behebung. Sobald eine Lösung für ein Sicherheitsproblem existiert, wenden Sie die Lösung an.
• Datensicherungen – Reparieren Sie Ihr System nach einem Sicherheitsvorfall:
  Halten Sie aktuelle Datensicherungen und eine saubere Kopie des Betriebssystems (zum Beispiel auf CD-ROM) vor. Stellen Sie sicher, dass die Datensicherungen keine von Angreifern beschädigte oder veränderte Daten enthalten.
• Installieren Sie Software, die den Status des Systems überwacht:
  Programme wie die TCP-Wrapper oder Tripwire (beide sind als Paket oder aus den Ports installierbar) helfen, die Vorgänge auf einem System zu überwachen. Mit diesen Werkzeugen werden Sie Einbrüche leichter erkennen. Lesen Sie auch die täglichen Ausgaben der /etc/security-Skripten, die root zugeschickt werden.
• Schulen Sie die Benutzer des Systems:
  Benutzer sollten wissen, was sie tun. Niemand sollte einem Anderen sein Passwort geben. Die Benutzer sollen keine leicht zu erratenden Passwörter verwenden. Klären Sie die Benutzer darüber auf, dass sie für die System- und Netzwerksicherheit mitverantwortlich sind.

Das FreeBSD Security How-To enthält weiterführende Tipps, mit denen Sie die Sicherheit Ihres Systems verbessern können. Das How-To finden Sie unter der URL http://www.FreeBSD.org/~jkb/howto.html.

Sicherheit ist ein kontinuierlicher Prozess. Verfolgen Sie die Entwicklungen im Sicherheits-Umfeld.

Maßnahmen bei einem Sicherheitsvorfall

• Bestimmen Sie das Ausmaß des Vorfalls
  Welche Rechte hat der Angreifer erlangt? Hat der Angreifer root-Zugriff bekommen? Oder hat der Angreifer lediglich normale Benutzerrechte erhalten?
• Bestimmen Sie, ob sich etwas am Systemzustand (Kernel oder Userland) verändert hat
  Welche Software wurde verändert? Wurde ein neuer Kernel installiert? Wurden Systemprogramme (wie telnetd oder login) verändert? Wenn ein Angreifer das Betriebssystem verändert hat, sollten Sie das System von einem sicheren Medium neu installieren.
• Finden Sie heraus wie der Einbruch verübt wurde
  Nutzte der Einbrecher ein bekanntes Sicherheitsloch aus? In diesem Fall installieren Sie die richtigen Fehlerbehebungen. Wurde der Einbruch durch eine Fehlkonfiguration möglich? War der Einbruch durch ein bisher unbekanntes Sicherheitsloch möglich? Wenn Sie glauben, ein neues Sicherheitsloch entdeckt zu haben, benachrichtigen Sie bitte den FreeBSD Security-Officer.
• Schließen Sie das Sicherheitsloch
  Installieren Sie neue Software oder wenden Sie Fehlerbehebungen auf alte Software an. Sperren Sie missbrauchte Benutzerkonten.
• Weitere Ressourcen
  Das CERT bietet genaue Anleitungen zum Umgang mit Sicherheitsvorfällen.

Weitere Informationsquellen

• The COAST archive enthält eine große Sammlung von sicherheitsrelevantem Material.
• The Center for Education and Research in Information Assurance and Security (CERIAS) enthält alles was Sie über Sicherheit erfahren wollen.
• Die Seiten verschiedener CERTs wie http://www.cert.org und http://www.auscert.org.au.
• Mailinglisten wie Bugtraq und Firewall Wizards.