[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ weiter ]

Anleitung zum Absichern von Debian
Kapitel 11 - Frequently asked Questions (FAQ)


Dieses Kapitel führt Sie in ein paar der am häufigsten gestellten Fragen in der Security-Mailing-Liste ein. Sie sollten sie lesen, bevor Sie dort etwas posten, oder die Leute werden Ihnen lediglich "RTFM!" sagen.


11.1 Sicherheit im Debian Betriebssystem


11.1.1 Ist Debian sicherer als X?

Ein System ist so sicher, wie der Administrator fähig ist, es sicher zu machen. Debian versucht Services auf eine standardmässig sicher-Art zu installieren, und wird nicht versuchen so paranoid wie andere Betriebssysteme zu sein, die Services auf eine standardmässig abgeschaltet-Art installieren. In jedem Fall muss der System-Administrator die Sicherheit des System den lokalen Sicherheits-Regeln anpassen.


11.1.2 In bugtray gibt es viele Debian-Fehler. Heisst das, es ist sehr gefährdet?

Debian enthält wirklich viele Pakete und unterschiedliche Software, wahrscheinlich sogar mehr, als mit manch einem propietären Betriebssystem geliefert wird. Die heisst, dass es mehr potentielle Sicherheits-Angelegenheiten geben kann, als bei einem System mit weniger Software.

Wie auch immer: Es gibt viele Sicherheits-Gutachten in Zusammenhang mit Quell-Code Überprüfungen von grösseren Software-Komponenten, die Debian enthält. Wann immer eine solche Überprüfung eine grössere Lücke findet, wird er repariert und ein Sicherheitsgutachten wird al Listen wie bugtraq geschickt.

Fehler, die in der Debian Distribution vorhanden sind, betreffen normalerweise auch andere Lieferanten und andere Distributionen. Prüfen Sie einfach einfach den "Debian specific: yes/no" Eintrag am Anfang jedes Sicherheitsgutachten (DSA, Debian Security Advisory). Wenn dort "yes" steht, betrifft es nur Debian, wenn dort "no" steht, betrifft es wahrscheinlich auch andere Distributionen.

Debian enthält wirklich viele Pakete, und heutzutage gibt es viele Gruppen die nach Sicherheits-Problemen in Software suchen (warum auch immer).


11.1.3 Hat Debian irgendein Zertifikat für Sicherheit?

Kurze Antwort: Nein.

Lange Antwort: Zertifikate kosten Geld und niemand hat Resourcen dazu bestimmt, die Debian GNU/Linux Distributionen auf irgendeiner Stufe, beispielsweise der Common Criteria, zu zertifizieren. Wenn Sie daran interessiert sind, eine zertifizierte GNU/Linux Distribution zu haben, stellen Sie uns die Resourcen zur Verfügung, um dies Möglich zu machen.


11.1.4 Gibt es irgendein Absicherungsprogramm für Debian?

Ja. Bastille Linux, ursprünglich an anderen Linux Distributionen (RedHat und Mandrake) orientiert funktioniert es derzeit auch mit Debian. Es sind Massnahmen eingeleitet, um die entsprechenden Änderungen auch der ursprünglichen Version zugute kommen zu lassen. In jedem Fall heisst das Debian-Paket natürlich bastille.

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


11.1.5 Ich möchte eine XYZ-Service laufen lassen. Welchen sollte ich benutzen?

Einer der Vorteile von Debian, der die meisten neuen Administratoren verwirren könnte, ist, dass es eine grosse Zahl von Software, die den gleichen Service anbietet (DNS-Server, Mail-Server, FTP-Server, Web-Server...) enthält. Wenn Sie wissen wollen, welchen Server Sie installieren sollten, gibt es keine allgemeingültige Antwort. Es hängt wirklich von den benötigten Fähigkeiten und der benötigten Sicherheit (was eventuell ausbalanciert werden muss) ab.

Dinge, die Sie prüfen sollten:


11.1.6 Wie mach ich den Service XYZ unter Debian sicherer?

Sie werden in diesem Dokument Informationen über das Absichern von einigen Servicen (FTP, Bind) unter Debian GNU/Linux finden. Für Services die hier nicht abgedeckt werden, prüfen Sie die Programm Dokumentation, oder allgemeine Linux Informationen. Die meisten Sicherheits-Hinweise für Unix-Systeme sind auch auf Debian anwendbar. So ist das Absichern von Service X unter Debian meistens wie das absichern des Service unter einer anderen Linux-Distribution (oder Unix, was das betrifft).


11.1.7 Sind alle Debian Pakete sicher?

Das Sicherheits-Team von Debian kann nicht alle Pakete aus Debian auf potentielle Sicherheits-Lücken hin analysieren, da es einfach nicht genug Resourcen gibt, um allen Quellcode zu prüfen. Dennoch profitiert Debian von den Quellcode-Prüfungen durch den ursprünglichen Entwickler oder durch ander Projekte, wie das Linux Kernel Security Audit Project oder das Linux Security-Audit Project.

Tatsächlich könnte ein Debian Developer in einem Paket einen Trojaner verbreiten, und es gibt keine Möglichkeit das nachzuprüfen. Sogar wenn sie in Debian eingeführt würden, wäre es unmöglich alle möglichen Situationen, in der der Trojaner ausgeführt werden würde, abzudecken.

Dies fällt unter die no guarantees Lizens-Klausel. In jedem Fall können Debian User insofern Vertrauen fassen, dass der stabile Quellcode eine breite Prüfung hinter sich hat und die meisten Probleme durch Benutzung endeckt worden wären. Es ist in jedem Fall nicht empfohlen ungetestete Software auf einem wertvollen System zu installeren (wenn Sie nicht die notwendige Code-Prüfung vornehmen können). Und in jedem Fall kann, wenn es zu in die Distribution eingeführten Sicherheits-Problemen käme, könnte der Prozess zu ihrer Aufnahme (der digitale Unterschriften benutzt) sicherstelen, dass das Problem letzendlich zu dem Developer zurückgeführt werden kann. Und das Debian Project hat diese Angelegenheiten nie auf die leichte Schulter genommen.


11.1.8 Betriebssystem User und Gruppen


11.1.8.1 Sind alle System User notwendig?

Ja und nein. Debian kommt mit einigen für bestimmte Services vordefinierten Usern (ids < 99, beschrieben in der Debian Policy). So wird das installieren eines neuen Service einfach (das sie dann bereits als ein passender User laufen). Wenn Sie nicht vorhaben neue Services zu installieren, können Sie die User, denen keine Dateien gehören und die keine Services auf Ihrem System laufen lassen, entfernen.

Sie können leicht User finden, denen keine Dateien gehören, indem Sie das folgenen Kommando ausführen (stellen Sie sicher, dass Sie es als root ausführen, da ein gemeiner User nicht genug Zugriffsrechte haben könnte, um ein paar sensitive Verezichnisse zu durchsuchen):

     cut -f 1 -d : /etc/passwd |
     while read i; do find / -user "$i" | grep -q . && echo "$i"; done

Diese User kommen aus dem Paket base-passwd. Sie finden Informationen über die Behandlung dieser User unter Debian in der Dokumentation des Pakets.

Hier folgt nun eine Liste der standard User (mit ihren entsprechenden Gruppen):

Andere Gruppe, die keinen assozierten User haben:


11.1.8.2 Was ist der Unterschied zwischen der adm und der staff Gruppe?

'adm' sind Administratoren und ist meistens nützlich, um ihne zu erlauben, Log-Dateien zu lesen, ohne su benutzen zu müssen. 'staff' ist mehr bei den Helpdesk/junior Sysadmins Leuten nützlich, und gibt ihnen die Möglichkeit, Dinge in /usr/local zu erledigen und Verzeichnisse in /home anzulegen.


11.1.9 Fragen über Services und offene Ports


11.1.9.1 Warum werden Services während der Installation aktiviert?

Das ist der Annäherung an das Problem auf der einen Seite Sicherheits-Bewusst und auf der anderen Seite benutzerfreundlich zu sein. Anders als OpenBSD, dass alle Services abschaltet, bis sie vom administrator aktiviert werden, aktiviert Debian GNU/Linux alle installierten Services, bis sie abgeschaltet werden (siehe dazu Daemon-Services abschalten, Abschnitt 3.6.1). Immerhin haben Sie den Service installiert, oder?

Es gab einige Diskussionen auf Debian Mailing-Listen (sowohl auf debian-devel als auch auf debian-security), darüber was das standard Setup sein sollte. Jedoch gab es bisher (10. März 2002) keinen Konsens, wie dies behandelt werden sollte.


11.1.9.2 Kann ich inetd entfernen?

Inetd ist nich leicht zu entfernen, da netbase von dem Paket abhängt, das Inetd enthält (netkit-inetd). Wenn Sie es entfernen wollen, können Sie es entwerder abschalten (siehe Daemon-Services abschalten, Abschnitt 3.6.1) oder das Paket entfernen, indem Sie das Paket equivs benutzen.


11.1.9.3 Warum muss ich Port 111 offen haben?

Port 111 ist sunrpcs Portmapper und wird standardmässig bei allen Basis-Installationen eines Debian Systems, da es keine Möglichkeit gibt, herauszubekommen, wann das Programm eines Users RPC gebrauchen könnte, um korrekt zu arbeiten. In jedem Fall wird es meistens von NFS benutzt. Wenn Sie kein NFS benutzen, entfernen Sie es, wie in Abschalten von RPC-Servicen, Abschnitt 5.14 erklärt.


11.1.9.4 Wozu ist der identd (Port 113) da?

Identd wird von Administratoren benutzt, um anderen Systemen, die wissen wollen, wer für eine bestimmte Verbindung verantwortlich ist, zusätzliche Informationen zu einer Userid zur Verfügung zu stellen. Beachtenswert schliesst dies mail, FTP und IRC Server ein, jedoch kann es auch dazu benutzt werden, um den User ihrer Systeme zurückzuverfolgen, der einen Angriff gestartet hat.

Es gab ausführliche Diskussionen hierrüber (siehe in den Mailing List Archiven. Grundsätzlich gillt: Wenn Sie nicht wissen, was und wozu es ist, aktivieren Sie es nicht. Aber wenn Sie es firewallen, bitte: Nehmen Sie eine reject-Regel und keine deny-Regel, oder Kommunikation könnte bis zu einer Zeitüberschreitung hängen (siehe reject or deny issues).


11.1.9.5 Ich habe festgestellt, dass ich den folgenden Port (XYZ) offen habe. Kann ich ihn schliessen?

Natürlich können Sie. Die Ports die Sie offen lassen hängen von Ihrem Regelwerk bezüglich öffentlich zugänglichen Services ab. Prüfen Sie, ob Sie durch inetd (siehe Abschalten von inetd-Servicen, Abschnitt 3.6.2) geöffnet sind, oder durch ein anderes installiertes Paket und leiten Sie passende Massnahmen ein (konfigurieren von inetd, entfernen des Pakets, vermeiden dass der Service beim booten gestartet wird...)


11.1.9.6 Ich habe einen Service von /etc/services entfernt, funktioniert das?

Nein, /etc/services zieht einfach nur eine Verbindung zwischen einem virtuellen Namen und einer Port Nummer. Das Entfernen eines Namens wird (meistens) nicht verhindern, dass ein Service gestartet wird. Manche Daemonen starten vielleicht nicht, wenn Sie /etc/services ändern, aber das ist nicht die Norm, und es ist nicht der empfohlene Weg einen Service abzuschalten, siehe Daemon-Services abschalten, Abschnitt 3.6.1.


11.1.10 Allgemeine Sicherheits Fragen


11.1.10.1 Ich habe meine Passwort vergessen und kann auf das System nicht mehr zugreifen!!

Die Schritte, die nötig sind, damit Sie wider Zugriff erhalten, hängen davon ab, ob Sie die vorgeschlagene Prozedur zum Absichern von Lilo und dem Bios durchgeführt haben oder nicht.

Wenn Sie beides eingeschränkt haben, müssen Sie im BIOS erlauben, von anderen Medien als der Festplatte zu booten, bevor Sie weitermachen können. Wenn Sie auch Ihr BIOS-Passwort vergessen haben, müssen Sie Ihr Gehäuse öfnen, und die Batterie des Bios entfernen.

Wenn Sie von CD-ROM oder Diskette booten können, können Sie:

Dies entfernt das Root-Passwort. Sie können das System starten und sich beim login: Prompt als Root mit einem leeren Passwort einloggen. Dies funktioniert, es sei denn, Sie haben Ihr System etwas sicherer eingestellt, d.h. User mit leeren Passwort dürfen sich nicht einloggen und Root kann sich nicht auf einer Konsole einloggen.

Wenn Sie diese Massnahmen getroffen haben, müssen Sie im singe-Modus starten. Wenn Sie LILO eingeschränkt haben, müssen LILO erneut ausfrühren, nachdem Sie das Root-Passwort zurückgesetzt haben. Das ist trickreich, da Ihre /etc/lilo.conf nicht gefunden iwrd, und Ihr /-Dateisystem eine ramdisk und keine echte Festplatte ist.

Sobald LILO nicht mehr eingeschränkt ist, können Sie:


11.1.11 Ich möchte meinen Usern einen Service anbieten, Ihnen aber keinen Shell-Account geben.

Wenn Sie einen zum Beispiel einen POP-Service anbieten wollen, müssen Sie nicht für jeden zugreifenden User einen Account anlegen. Am besten setzen Sie hierzu eine Verezichnis-basierte Authentifizierung durch einen externen Service (wie Radius, LDAP oder eine SQL-Datenbank) auf. 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 User Authentifizierung: PAM, Abschnitt 4.9.1 nach), und konfigurieren Sie den PAM-nutzenden Service, so dass er Ihr Backend benutzt. Dies tun Sie, indem Sie die dem Service entsprechedne Datei unter /etc/pam.d/ editieren, und die folgendende Zeile von

     auth    required        pam_unix_auth.so shadow nullok use_first_pass

beispielsweise nach ldap ändern:

     auth    required        pam_ldap.so

Im Fall von LDAP-Verzeichnissen, liefern manche Services LDAP-Schemata mit, die Sie ihrem Verzeichnis hinzufügen können, um LDAP-Authentifizierung mit Ihnen zu benutzen. Wenn Sie relationale Datenbanken benutzen, gibt es einen nützlichen Trick: Benutzen Sie die where Klausel, 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)

Können Sie die letzen (bool'schen) Werte dazu benutzen, denn Zugriff auf die verschiedenen Services entweder zu erlauben oder zu verbieten, indem Sie einfach die folgenden Zeilen in die Dateien hinzufügen:


11.2 Mein System ist angreifbar (sicher?)


11.2.1 Ich habe in meinen Logs einen Angriff gesen: Bin ich kompromitiert?

Ein Hinweis auf einen Angriff heistt nicht notwendigerweise, dass Sie gehackt worden sind. Sie sollten die üblichen Schritte einleiten, um festzustellen, ob das System kompromitiert wurde (siehe Nach einer Komprimitierung, Kapitel 10). Beachten Sie auch, dass manchmal die Tatsache, dass Sie einen Angriff in den Logs sehen, heissen kann, dass sie hierfür angreifbar sind (ein bestimmter Angreifer könnte übrigens auch andere Angriffe, als die, die Sie gesehen haben, durchgeführt haben).


11.2.2 Ich habe in meinen Logs merkwürdige "MARK"-Einträge gefunden, bin ich kompromitiert?

Wenn Ihr System keine hohe Last (und Services) hat, finden Sie vielleicht die folgenden Zeilen in Ihren System-Logs:

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

Dies zeigt keine Art der Komprimitierung, und User, die von einer Debian release wechseln, werden es merkwürdig finden. Es ist in der Tat ein ein Indiz dafür, dass syslogd vernünftig läuft. Aus syslogd(8):

            -m interval
                   The syslogd logs a mark timestamp  regularly.   The
                   default interval between two -- MARK -- lines is 20
                   minutes.  This can be  changed  with  this  option.
                   Setting the interval to zero turns it off entirely.
            -m interval
     	      Der Syslogd protokolliert regelmässig 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.

11.2.3 Ich habe User gefunden, die laut meinen Logs su benutzen: Bin ich kompromitiert?

Sie könnten in Ihren Logs 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 besorgt, und prüfen Sie, ob dies durch eine Job durch Cron entsteht (normalerweise /etc/cron.daily/find oder logrotate):

     $ grep 25 /etc/crontab
     25 6    * * *   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

11.2.4 Ich bin Opfer eines Einbruchs - was soll ich jetzt tun?

Lesen Sie dieses Dokument und leiten Sie passenden, hier dargestellten massnahmen ein. Wenn Sie Hilfe benötigen, können Sie auf der debian-security@lists.debian.org Liste Rat suche, wie Sie Ihr System wiederherstellen/patchen.


11.2.5 Wie kann ich Angriffe aufsprüren?

Durch durchgehen der Logs (wenn Sie nicht geändert wurden), benutzen eines Eindringling-Erkennungs-Systems (siehe Aufsetzen einer Eindringlingserkennung, Abschnitt 9.1), traceroute, whois und ähnliche Tools (einschliesslich forensiche Analyse) können einen Angriff zu seiner Ursprung zurückverfolgen. Wie Sie auf diese Informationen reagieren hängt ausschliesslich von Ihren Sicherheits-Regeln ab, und was Sie als Angriff betrachten. Ist ein einfacher Scan ein Angriff? Ist das Prüfen auf eine Verwundbarkeit ein Angriff?


11.2.6 Das Programm X ist in Debian angreifbar - was soll ich machen?

Nehmen Sie sich einen Augenblick Zeit, um zu schauen, ob die Angriffsmöglichkeit in öffentlichen Sicherheits-Mailinglisten (wie Bugtraq) oder anderen Foren bekannt gemacht wurde. Das Debian-Sicherheits-Team hält sich bei diesen Listen auf dem laufenden, also könnten ihnen dieses Problem bereits bekannt sein. Leiten Sie keine weiteren Massnahmen ein, wenn Sie schon ein Sicherheits-Gutachten auf http://security.debian.org sehen.

Wenn Sie nichts finden, senden Sie bitte eine Mail mit einer möglichst detailierten Beschreibung des Angriffspunktes (Code, der dies bestätigt ist auch okay) adn security@debian.org. Dadurch erreichen Sie das Sicherheits-Team.


11.2.7 Laut der Versions-Nummer eines Paketes, läuft bei mir immernoch eine angreifbare Version!

Anstatt auf neue Releases zu aktualisieren, führen wir Sicherheits-Korrekturen auf die Version zurück, die in der stabilen Version enthalten war. Der Grund dafür ist, dass wir sicher gehen wollen, dass eine stabile Release so wenig wie möglich verändert wird. So werden sich Dinge nicht unerwartet ändern oder kaputt gehen, als Resultat einer Sicherheits-Korrektur. Sie können prüfen, ob Sie eine sichere Version eines Paketes benutzen, indem Sie das Changelog des Paketes durchsehen, oder indem Sie die exakte Versions Nummer (Ursprüngliche Version -slash- Debian Release) mit der Nummer aus dem Debian Sicherheits-Gutachten vergleichen.


11.2.8 spezielle Software


11.2.8.1 Proftpd ist für einen "Denial of Service"-Angriff anfällig.

Fügen Sie DenyFilter \*.*/ Ihrer Konfigurations Datei hinzu. Mehr Informationen entnehmen Sie http://www.proftpd.org/critbugs.html.


11.3 Fragen über Debians Sicherheitsteam


11.3.1 Was ist ein Debian Sicherheitsgutachten (Debian Security Advisory, DSA)

Dies sind von Debians Sicherheits Team (siehe Unten) gesendete Informationen über die Verfügbarkeit der Korrektur einer sicherheitsrelevanten Verwundbarkeit für das Debian Betriebs System. Digital unterschriebene DSAs werden auf eine öffentliche Mailing-Liste gesendet und auf Debians Web-Seite veröffentlicht (sowohl auf der Hauptseite als auch unter Sicherheitsinformationen).

DSAs enthalten Informationen über beeinträchtigte Pakete, den entdeckten Fehler und wie man aktualisierte Pakete bekommt (und ihre md5-Summen).


11.3.2 Die digitale Signatur eines Debian Gutachtens kann nicht korrekt verifiziert werden!

Dies ist wahrscheinlich ein Problem an Ihrem Ende. Die debian-security-announce Liste hat einen Filter vorgeschaltet, der nur Nachrichten durchlässt, die eine korrekte Signatur von einem Mitglied des Sicherheits Teams enthält.

Wahrscheinlich verändert irgendeine Mail-Software an Ihrem Ende ein wenig und ruiniert damit die Unterschrift. Stellen Sie sicher, dass Ihre Software keine MIME-Codierung oder -Decodierung, oder Tabulatur/Leerzeichen konvertierung durchführt.

Bekannte Schuldige sind fetchmal (mit eingeschalteter mimedecode Option) und formail (lediglich von procmail 3.14)


11.3.3 Wie werden Sicherheits-Ereignisse in Debian behandelt?

Sobald das Sicherheits-Team eine Notiz über einen Vorfall erhält, prüfen ihn ein oder mehrere Mitglieder nach, und erwägen, ob Debian/stable angreifbar ist, oder nicht. Wenn unser System angreifbar ist, wird an einer Korrektur für das Problem gearbeitet. Der Paket-Verwalter wird ebenfalls kontaktiert, wenn er nicht bereits selbst das Sicherheits-Team kontaktiert hat. Schliesslich wird die Korrektur getestet und ein neues Paket vorbereitet, die dann auf allen stabilen Architekturen compiliert wird, die dann anschliessend hoch geladen werden. Nachdem all dies getan ist, wird ein Debian Sicherheits Gutachten (DSA) an die öffentliche Mailing Liste geschickt.


11.3.4 Wieviel Zeit wird Debian brauchen, um die Angriffsmöglichkeit XXXX zu reparieren?

Eine Analyse der Zeiten, die Debians Sicherheits-Team benötigt, um ein Gutachten zu veröffentlichen und reparierte Pakete zu produzieren nachdem eine Angriffsmöglichkeit bekannt wird, zeigt, dass es nicht so lange dauert, die Angriffmöglichkeiten in der stabilen Distribution zu reparieren.

Ein Report in der debian-security Mail-Liste zeigt, dass im Jahr 2001 Debians Sicherheitsteam durchschnittlich 35 Tage benötigte, um eine sicherheitsrelevante Angriffmöglichkeit zu reparieren. Über 50% der Angriffspunkte wurden jedoch innerhalb eines Zeitrahmens von 10 Tagen beseitigt, und über 15% von ihnen wirden noch am gleichen Tag repariert.

Dennoch tendieren Leute, die diese Frage stellen, zu vergessen, dass:


11.3.5 Wie wird Sicherheit für testing und unstable gehandhabt?

Die kurze Antwort ist: Gar nicht. Testing und unstable unterliegem einem rapoden Fluss, und das Sicherheits-Team hat nicht die benötigten Resourcen, die notwendig wären, um diese richtig zu betreuen. Wenn Sie einen sicheren (und stabilen) Server haben möchten, sind Sie stark dazu ermutigt, bei stable zu bleiben.

Aber tatsächlich wird unstable normalerweise relativ schnell repariert, da Sicherheitsupdates für die aktuelle Version durch den ursprünglichen Autor schnell verfügbar sind (während andere Versionen, wie die in stable, normalerweise einen zurück portiert werden müssen).


11.3.6 Warum gibt es keine offiziellen Spiegel für security.debian.org?

Der Zweck von security.debian.org ist es, Sicherheits-Updates möglichst schnell und einfach zur Verfügung zu stellen. Spiegel würden zusätzliche Komplexität einführen, die nicht benötigt ist, und nur Frustration erzeugt, wenn Sie nicht aktuell gehalten werden.


11.3.7 Ich habe DSA 100 und DSA 102 gesehen, wo ist aber DSA 101?

Verschiedene Distributoren (zumeist von GNU/Linux, aber auch von BSD-Derivaten) koordinieren Sicherheits-Gutachten für verschiedene Vorfälle und haben vereinbart, einen bestimmten Zeitplan einzuhalten, so dass alle Distributoren in der Lage sind, richtig zu prüfen, ob Sie betroffen sind (oder nicht) und entsprechende Updates erstellen können.

Das Sicherheits-Team von Debian behält in solchen Fällen die Nummer, bevor das Gutachten freigegeben wird, und so kann es zeitweise passieren, dass die ein andere Nummer fehlt.


11.3.8 Wie kann ich das Sicherheits-Team erreichen?

Sicherheits Informationen können an security@debian.org geschickt werden, damit es von allen Debian Entwicklern gelesen wird. Wenn Sie sensitive Informationen haben, benutzen sie bitte team@security.debian.org, damit es nur vom Security-Team gelesen wird. Wenn Sie es wünschen, kann die Email auch mit dem Debian Security Contact Key (Key-Id 363CCD95) verschlüsselt werden.


11.3.9 Was ist der Unterschied zwischen security@debian.org und debian-security@lists.debian.org?

Wenn Sie eine Nachricht an security@debian.org schicken, wird diese an die Developer Mailingliste geschickte (debian-private), die alle Debian Entwickler aboniert haben. Nachrichten an diese Liste werden vertraulich behandelt (d.h. nicht auf einer öffentlichen Webseite archiviert). debian-security@lists.debian.org ist eine öffentliche Mail-Liste, offen für jeden, der sie abonieren möchte, und es gibt ein auf den Web-Seiten ein durchsuchbares Archiv.


11.3.10 Wie kann ich Debians Sicherheit-Team unterstützen?

Prüfen Sie bitte in jedem Fall nach, bevor Sie etwas an security@debian.org melden. Wenn Sie Patches beifügen können, würde das den Prozess natürlich beschleunigen. Leiten Sie nicht einfach bugtraq Mails weiter, da Sie bereits empfangen werden. Es ist aber eine gute Idee, zusätzliche Informationen zu schicken.


11.3.11 Aus wem setzt sich das Sicherheits-Team zusammen?

Debians Sicherheit Team besteht derzeit aus fünf Mitgliedern und zwei Sekretären. Das Sicherheits Team lädt Personen selbst ein, beizutreten.


11.3.12 Prüft Debians Sicherheit Team jedes Paket in Debian?

Nein, weder prüft Debians Sicherheit Team jedes neue Paket noch gibt es einen automatischen (lintian) Test, um böshafte neue Pakete zu entdecken, da solche Dinge praktisch unmöglich automatisch zu erkennen sind. Paket-Verwalter sind jedoch voll und ganz verantwortlich für die Software, die in Debian eingeführt wird, und keine Software wird eingeführt, die nicht zuerst von einem autorisierten Entwickler signiert worden sind. Sie sind dafür verantwortlich die Software, die sie verwalten, zu analysieren und auf Sicherheit zu achten.


11.3.13 Ich habe eine ältere Version von Debian. Wird sie in Bezug auf Sicherheit noch unterstützt?

Leider nein. Debians Sicherheit-Team kann nicht leider nicht sowohl die stabile Release (inoffiziell also auch unstable) als auch ältere Releases unterstützen. Sie können jedoch Sicherheits-Updates für einen begrenzten Zeitraum (normalerweise mehrere Monate), nachdem eine neue Debian Distribution veröffentlicht wurde, erwarten.


[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ weiter ]

Anleitung zum Absichern von Debian

2.5 (beta) 14 febrero 2004Sat, 17 Aug 2002 12:23:36 +0200

Javier Fernández-Sanguino Peña jfs@computer.org