Kapitel 12. Häufig gestellte Fragen / Frequently asked Questions (FAQ)

Der Unterschied zwischen den Linux-Distributionen ist nicht sehr groß mit Ausnahme der Basisinstallation und der Paketverwaltung. Die meisten Distributionen beinhalten zum Großteil die gleichen Anwendungen. Der Hauptunterschied besteht in den Versionen dieser Programme, die mit der stabilen Veröffentlichung der Distribution ausgeliefert werden. Zum Beispiel sind der Kernel, Bind, Apache, OpenSSH, Xorg, gcc, zlib, etc. in allen Linux-Distributionen vorhanden.

Ein Beispiel: Red Hat hatte Pech und wurde veröffentlicht, als foo 1.2.3 aktuell war. Später wurde darin eine Sicherheitslücke entdeckt. Dagegen hatte Debian das Glück, dass es mit foo 1.2.4 ausgeliefert wurde, in dem der Fehler schon behoben war. Das war der Fall beim großen Problem mit http://www.cert.org/advisories/CA-2000-17.html vor ein paar Jahren.

Es besteht eine weitgehende Zusammenarbeit zwischen den jeweiligen Sicherheitsteams der großen Linux-Distributionen. Bekannte Sicherheitsaktualisierungen werden selten (wenn nicht sogar nie) von den Anbietern der Distribution nicht eingespielt. Das Wissen um eine Sicherheitslücke wird niemals vor anderen Anbietern von Distributionen geheim gehalten, da die Ausbesserungen gewöhnlich vom Programmautor oder von http://www.cert.org koordiniert werden. Das hat zur Folge, dass notwendige Sicherheitsaktualisierungen üblicherweise zur selben Zeit veröffentlicht werden. Damit ist die relative Sicherheit der verschiedenen Distributionen ziemlich ähnlich.

Einer großen Vorteile von Debian in Hinblick auf die Sicherheit ist die Leichtigkeit von Systemaktualisierungen mit apt. Hier sind ein paar andere Aspekte über die Sicherheit in Debian, die Sie berücksichtigen sollten:

Die Debian-Distribution enthält eine große und wachsende Zahl von Softwarepaketen, wahrscheinlich sogar mehr als mit vielen proprietären Betriebssystemen geliefert wird. Je mehr Pakete installiert sind, desto größer ist die Möglichkeit von Sicherheitslücken in einem System.

Immer mehr Menschen untersuchen den Quellcode, um Fehler zu entdecken. Es gibt viele Anweisungen im Zusammenhang mit Audits des Quellcodes von großen Softwarekomponenten, die in Debian enthalten sind. Immer wenn ein solcher Audit Sicherheitslücken aufdeckt, werden sie ausgebessert und eine Ankündigung wird an Listen wie Bugtraq geschickt.

Fehler, die in der Debian-Distribution vorhanden sind, betreffen normalerweise auch andere Anbieter und Distributionen. Prüfen Sie einfach den »Debian specific: yes/no«-Abschnitt am Anfang jeder Ankündigung (DSA).

Die kurze Antwort: Nein.

Die lange Antwort: Zertifikate kosten Geld (besonders ein seriöses Sicherheitszertifikat). Niemand hat die Ressourcen aufgebracht, um Debian GNU/Linux beispielsweise mit irgendeinem Level des http://niap.nist.gov/cc-scheme/st/ zertifizieren zu lassen. Wenn Sie daran interessiert sind, eine GNU/Linux-Distribution mit Sicherheitszertifikaten zu haben, stellen Sie uns die Ressourcen zur Verfügung, um dies möglich zu machen.

Es gibt im Moment mindestens zwei Linux-Distributionen, die mit verschiedenen http://en.wikipedia.org/wiki/Evaluation_Assurance_Level-Levels zertifiziert sind. Beachten Sie, dass einige CC-Tests im http://ltp.sourceforge.net vorhanden sind, welche in Debian durch ltp angeboten wird.

Ja. http://bastille-linux.sourceforge.net, das sich ursprünglich an anderen Linux-Distributionen (Red Hat und Mandrake) orientierte, es funktioniert derzeit auch mit Debian. Es sind Maßnahmen eingeleitet, um Änderungen am Originalprogramm auch in das Debian-Paket bastille einfließen zu lassen.

Manche Leute glauben jedoch, dass ein Absicherungsprogramm nicht die Notwendigkeit einer guten Administration ersetzen kann.

Einer der größten Stärken von Debian ist die große Vielfalt von Paketen, welche die gleichen Funktionen erfüllen (DNS-Server, Mail-Server, FTP-Server, Web-Server etc.). Das kann einen unerfahrenen Administrator verwirren, wenn er herausfinden will, welches Paket das richtige für ihn ist. Die beste Wahl hängt in der Balance zwischen Ihrem Bedürfnis nach Funktionalität und dem nach Sicherheit in der jeweiligen Situation ab. Im Folgenden einige Fragen, die Sie sich stellen sollten, wenn Sie zwischen ähnlichen Paketen entscheiden müssen:

Sie werden in diesem Dokument Informationen über das Absichern von einigen Diensten (FTP, Bind) unter Debian GNU/Linux finden. Für Dienste, die hier nicht abgedeckt werden, prüfen Sie die Programm-Dokumentation oder allgemeine Linux-Informationen. Die meisten Sicherheitshinweise für Unix-Systeme sind auch auf Debian anwendbar. So wird Dienst X unter Debian in den meisten Fällen wie in einer anderen Linux-Distribution (oder Un*x, was das betrifft) abgesichert.

Wenn Sie z.B. nicht wollen, dass Benutzer sich mit Ihrem POP3-Daemon verbinden und dadurch Informationen über Ihr System erlangen, sollten Sie das Banner, das der Dienst den Benutzern zeigt, entfernen (oder verändern). ^[82] Wie Sie das anstellen können, hängt von der Software ab, mit der Sie einen bestimmten Dienst betreiben. Für postfix stellen Sie beispielsweise das SMTP-Banner in /etc/postfix/main.cf ein:

  smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

Andere Software kann nicht so leicht verändert werden. ssh muss neu kompiliert werden, um die angezeigte Version zu ändern. Stellen Sie sicher, dass Sie nicht den ersten Teil des Banners (SSH-2.0) entfernen, da Clients ihn verwenden, um die von Ihrem Paket unterstützten Protokolle zu identifizieren.

Das Sicherheitsteam von Debian kann nicht alle Pakete aus Debian auf potenzielle Sicherheitslücken hin analysieren, da es einfach nicht genug Ressourcen gibt, um für das gesamte Projekt ein Quellcodeaudit durchzuführen. Allerdings profitiert Debian von den Quellcode-Prüfungen durch die Originalautoren.

Tatsächlich könnte ein Debian-Entwickler in einem Paket einen Trojaner verbreiten und es gibt keine Möglichkeit das nachzuprüfen. Sogar wenn es in einen Zweig von Debian eingeführt werden würde, wäre es unmöglich, alle möglichen Situationen abzudecken, in denen der Trojaner ausgeführt werden würde. Das ist der Grund, warum Debian eine »Keine Gewährleistung«-Klausel in seiner Lizenz hat.

Allerdings können Debian-Benutzer insofern Vertrauen fassen, als dass der stabile Quellcode eine breite Prüfung hinter sich hat. Die meisten Probleme würden dabei durch Benutzung entdeckt. Es ist nicht zu empfehlen, ungetestete Software auf kritischen Systemen zu installieren, wenn Sie nicht die notwendige Code-Prüfung vornehmen können. In jedem Fall gewährleistet der Aufnahmeprozess in die Distribution (mit digitalen Signaturen), dass im Falle von in die Distribution eingeschleusten Sicherheitsproblemen das Problem letztendlich zum Entwickler zurückgeführt werden kann. Das Debian-Projekt hat diese Angelegenheiten nie auf die leichte Schulter genommen.

Natürlich können Sie die Standardrecht von Debian auf Ihrem System abändern. Der aktuelle Richtlinie in Bezug auf Protokoll- und Konfigurationsdateien besagt, dass sie für alle lesbar sein sollen, es sei denn, sie enthalten sensible Informationen.

Seien Sie vorsichtig, wenn Sie Änderungen vornehmen:

FIXME: Check if this is written in the Policy. Some packages (i.e. ftp daemons) seem to enforce different permissions.

Tatsächlich kann die gleiche Frage auch für jeden anderen Benutzer gestellt werden. Da Debians Standardinstallation keine Dateien unter diesem Verzeichnis abgelegt, sind keine sensiblen Informationen vorhanden, die geschützt werden müssten. Wenn Sie denken, dass diese Rechte für Ihr System zu locker sind, können Sie sie auf 750 einschränken. Für Benutzer sollten Sie Abschnitt 4.11.19.1, „Begrenzung des Zugangs zu Informationen anderer Benutzer“ lesen.

This Debian security mailing list http://lists.debian.org/debian-devel/2000/11/msg00783.html has more on this issue.

Wenn Sie Nachrichten auf der Konsole empfangen, aber /etc/syslog.conf so eingerichtet haben, dass diese in Dateien oder auf ein spezielles TTY umgeleitet werden, sehen Sie dennoch Nachrichten auf der Konsole, die direkt an sie geschickt werden.

Der Standardloglevel der Konsole ist bei jeden Kernel 7, was bedeutet, dass alle Nachrichten mit einer niedrigeren Priorität auf der Konsole erscheinen werden. Für gewöhnlich haben Firewalls (die LOG-Regel) und einige andere Sicherheitswerkzeuge eine niedrigere Log-Priorität. Daher werden ihre Protokolle direkt an die Konsole geschickt.

Um die Nachrichten, die an die Konsole geschickt werden, zu verringern, können Sie dmesg (Option -n, vergleichen Sie dmseg(8)) verwenden, das den Ringspeicher des Kernel untersucht und steuert. Damit das nach dem nächsten Neustart geändert ist, ändern Sie in /etc/init.d/klogd von

  KLOGD=""

in Folgendes ändern:

  KLOGD="-c 4"

Verwenden Sie eine niedrigere Nummer für -c, wenn Sie immer noch unerwünschte Nachrichten sehen. Eine Beschreibung der verschiedenen Loglevels befindet sich in /usr/include/sys/syslog.h:

  #define LOG_EMERG       0       /* system is unusable */
  #define LOG_ALERT       1       /* action must be taken immediately */
  #define LOG_CRIT        2       /* critical conditions */
  #define LOG_ERR         3       /* error conditions */
  #define LOG_WARNING     4       /* warning conditions */
  #define LOG_NOTICE      5       /* normal but significant condition */
  #define LOG_INFO        6       /* informational */
  #define LOG_DEBUG       7       /* debug-level messages */

Das Standardverhalten von Debian ist, dass jeder Benutzer seine eigene, persönliche Gruppe hat. Das traditionelle UN*X-Modell weist alle Benutzer der Gruppe users zu. Zusätzliche Gruppe werden erstellt, um den Zugang zu gemeinsam genutzten Dateien, die mit verschiedenen Projektverzeichnissen verbunden sind, einzuschränken. Die Dateiverwaltung wurde schwierig, wenn ein einzelner Benutzer an verschiedenen Projekten arbeitete, da, wenn jemand eine Datei erstellte, diese mit der primären Gruppe des Erstellers (z.B. »users«) verbunden war.

Das Modell von Debian löst dieses Problem, indem es jedem Benutzer seine eigene Gruppe zuweist. So wird mit einer korrekten Umask (0002) und mit dem SETGID-Bit für ein Projektverzeichnis den Dateien, die in diesem Verzeichnis erstellt werden, automatisch die richtige Gruppe zugewiesen. Das erleichtert die Arbeit von Menschen, die an verschiedenen Projekten arbeiten, da sie nicht die Gruppe oder Umasks ändern müssen, wenn sie mit gemeinsam genutzten Dateien arbeiten.

Sie können allerdings dieses Verhalten verändern, indem Sie /etc/adduser.conf modifizieren. Ändern Sie die Variable USERGROUPS auf »no« ab. Dadurch wird keine neue Gruppe erstellt, wenn ein neuer Benutzer angelegt wird. Sie sollten auch USERS_GID die GID der Gruppe zuweisen, der alle Benutzer angehören.

Wenn Sie zum Beispiel einen POP-Dienst anbieten wollen, müssen Sie nicht für jeden zugreifenden Benutzer ein Konto anlegen. Am besten setzen Sie hierzu eine Authentifizierung, die auf Verzeichnisses basiert, durch einen externen Dienst (wie Radius, LDAP oder eine SQL-Datenbank) ein. Installieren Sie einfach die gewünschte PAM-Bibliothek (libpam-radius-auth, libpam-ldap, libpam-pgsql oder libpam-mysql), lesen Sie die Dokumentation (Einsteiger sehen bitte unter Abschnitt 4.11.1, „Benutzerauthentifizierung: PAM“ nach) und konfigurieren Sie den PAM-nutzenden Dienst, so dass er Ihren Backend benutzt. Bearbeiten Sie dazu die dem Dienst entsprechenden Dateien unter /etc/pam.d/ und ändern die folgenden Zeile von:

  auth   required    pam_unix_auth.so shadow nullok use_first_pass

beispielsweise für ldap zu:

  auth   required    pam_ldap.so

Im Fall von LDAP-Verzeichnissen liefern manche Dienste LDAP-Schemata mit, die Sie Ihrem Verzeichnis hinzufügen können, um eine LDAP-Authentifizierung zu benutzen. Wenn Sie relationale Datenbanken benutzen, gibt es einen nützlichen Trick: Benutzen Sie die Klausel where, wenn Sie die PAM-Module konfigurieren. Wenn Sie beispielsweise eine Datenbank mit der folgenden Tabelle haben:

  (user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)

Wenn Sie die Attribute der Dienste zu Boolean-Feldern machen, können Sie sie verwenden, um den Zugang zu den verschiedenen Diensten zu erlauben oder zu verbieten. Sie müssen dazu nur die geeigneten Zeilen in folgende Dateien einfügen:

Viele Scanner zur Einschätzung der Verwundbarkeit liefern falsche Positivmeldungen, wenn sie auf Debian-Systemen eingesetzt werden. Das liegt daran, dass sie nur die Version eines Softwarepakets überprüfen, um herauszufinden, ob es verwundbar ist. Sie prüfen nicht, ob tatsächlich eine Sicherheitslücke vorhanden ist. Da Debian nicht die Version einer Software ändert, wenn ein Paket repariert wird (häufig werden Ausbesserungen an neueren Veröffentlichungen zurückportiert), neigen einige Werkzeuge dazu zu denken, dass ein aktualisiertes Debian-System verwundbar ist, auch wenn das nicht der Fall ist.

Wenn Sie denken, dass Ihr System auf dem aktuellen Stand der Sicherheitsaktualisierungen ist, sollten Sie die Querverweise zu den Datenbanken mit Sicherheitslücken, in denen die DSAs veröffentlicht sind (vergleichen Sie dazu Abschnitt 7.2, „Debian-Sicherheits-Ankündigungen“), verwenden, um falsche Positive auszusondern, wenn das Programm, das Sie verwenden, CVE-Referenzen enthält.

Ein Hinweis auf einen Angriff heißt nicht notwendigerweise, dass Ihr System gehackt wurde. Leiten Sie die üblichen Schritte ein, um festzustellen, ob das System kompromittiert wurde (siehe Kapitel 11, Nach einer Kompromittierung (Reaktion auf einem Vorfall)). Selbst wenn Ihr System hinsichtlich des protokollierten Angriffs nicht verwundbar ist, könnte ein entschlossener Angreifer neben der von Ihnen entdeckten Sicherheitslücke auch eine andere ausgenutzt haben.

Sie können die folgenden Zeilen in Ihren Systemprotokollen finden:

  Dec 30 07:33:36 debian -- MARK --
  Dec 30 07:53:36 debian -- MARK --
  Dec 30 08:13:36 debian -- MARK --

Dies stellt keinen Hinweis auf eine Kompromittierung dar, obwohl Benutzer, die von einer Debian-Release wechseln, es vielleicht merkwürdig finden. Wenn Ihr System keine große Last (oder nicht viele aktive Dienste) hat, können diese Zeilen in alle Protokollen auftauchen. Dies ist ein Hinweis, dass Ihr syslogd-Daemon richtig läuft. Aus syslogd(8):

    -m interval
              Der Syslogd protokolliert regelmäßig einen
              Zeitstempel. Der voreingestellte Abstand zwischen zwei
              – MARK – Zeilen ist 20 Minuten. Er kann mit dieser Option
              geändert werden. Setzen Sie den Abstand auf Null, um
              die Zeitstempel komplett abzuschalten.

Sie könnten in Ihren Protokolldateien Zeilen wie die folgenden finden:

  Apr  1 09:25:01 server su[30315]: + ??? root-nobody
  Apr  1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody by (UID=0)

Seien Sie nicht zu besorgt. Prüfen Sie, ob dies durch einen Cron-Job hervorgerufen wird (normalerweise /etc/cron.daily/find oder logrotate):

  $ grep 25 /etc/crontab
  25 9    * * *   root    test -e /usr/sbin/anacron || run-parts --report
  /etc/cron.daily
  $ grep nobody /etc/cron.daily/*
  find:cd / && updatedb --localuser=nobody 2>/dev/null

Sie sehen Einträge wie diese in Ihren Protokollen:

  May 1 12:35:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 12:36:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 12:37:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 13:43:11 linux kernel: possible SYN flooding on port X. Sending cookies.

Überprüfen Sie mit netstat, ob es eine große Anzahl von Verbindungen zum Server gibt. Zum Beispiel:

  linux:~# netstat -ant | grep SYN_RECV | wc -l
     9000

Dies ist ein Anzeichen, dass ein Denial-of-Service-Angriff (DoS) auf den Port X Ihres Systems (am wahrscheinlichsten gegen einen öffentlichen Dienst wie Ihren Web- oder Mailserver). Sie sollten TCP-Syncookies in Ihrem Kernel einschalten, siehe Abschnitt 4.18.2, „Konfiguration von Syncookies“. Beachten Sie, dass ein DoS-Angriff Ihr Netzwerk überfluten kann, auch wenn Sie verhindern können, dass er Ihr System zum Absturz bringt. ^[84] Der einzige effektive Weg, diesen Angriff abzuwehren, ist, mit Ihrem Netzprovider in Verbindung zu treten.

Sie sehen folgende Art von Einträgen in der Datei /var/log/auth.log:

  May 2 11:55:02 linux PAM_unix[1477]: (cron) session closed for user root
  May 2 11:55:02 linux PAM_unix[1476]: (cron) session closed for user root
  May 2 12:00:01 linux PAM_unix[1536]: (cron) session opened for user root by
  (UID=0)
  May 2 12:00:02 linux PAM_unix[1536]: (cron) session closed for user root

Sie kommen von einem ausgeführten Cron-Job (in unserem Beispiel alle fünf Minuten). Um herauszufinden, welches Programm für diese Jobs verantwortlich ist, überprüfen Sie die Einträge in /etc/crontab, /etc/cron.d, /etc/crond.daily und Roots crontab in /var/spool/cron/crontabs.

Es gibt mehrere Schritte, die Sie bei einem Einbruch durchführen sollten:

Sie können einen Angriff zu seinem Ursprung zurückverfolgen, indem Sie die Protokolle (wenn sie nicht geändert wurden) mit Hilfe eines Systems zur Eindringlingserkennung (siehe Abschnitt 10.3, „Aufsetzen einer Eindringlingserkennung“), traceroute, whois oder ähnlicher Werkzeuge (einschließlich forensischer Analyse) durchsehen. Wie Sie auf diese Informationen reagieren und was Sie als Angriff betrachten, hängt ausschließlich von Ihren Sicherheitsrichtlinien ab. Ist ein einfacher Scan ein Angriff? Ist die Prüfung auf eine Verwundbarkeit ein Angriff?

Nehmen Sie sich zuerst einen Augenblick Zeit, um zu schauen, ob die Sicherheitslücke in öffentlichen Sicherheitsmailinglisten (wie Bugtraq) oder anderen Foren bekannt gemacht wurde. Das Sicherheitsteam von Debian ist hinsichtlich dieser Listen auf dem Laufenden, daher sollte ihm dieses Problem bereits bekannt sein. Leiten Sie keine weiteren Maßnahmen ein, wenn Sie schon eine Bekanntmachung auf http://security.debian.org sehen.

Wenn anscheinend keine Informationen veröffentlicht wurden, schicken Sie bitte eine E-Mail zu den betroffenen Paketen mit einer detaillierten Beschreibung der Verwundbarkeit (Code, der dies bestätigt, ist auch in Ordnung) an mailto:[email protected]. Dort erreichen Sie das Sicherheitsteam von Debian.

Statt auf eine neue Veröffentlichung zu aktualisieren, portiert Debian sicherheitsrelevante Korrekturen zu der Version zurück, die in der Stable-Veröffentlichung enthalten ist. Der Grund dafür ist, dass sicher gegangen werden soll, dass die Stable-Veröffentlichung so wenig wie möglich verändert wird. Damit wird verhindert, dass sich Dinge als Folge einer Sicherheitskorrektur unerwartet ändern oder kaputt gehen. Ob Sie eine sichere Version eines Paketes benutzen, stellen Sie fest, indem Sie das Changelog des Paketes durchsehen oder indem Sie die exakte Versionsnummer (ursprüngliche Version -slash- Debian-Release) mit der Nummer aus der Debian-Sicherheits-Ankündigung (DSA) vergleichen.