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.
Ein System ist so sicher, wie der Administrator fähig ist, es sicher zu machen. Debian versucht, Dienste auf eine standardmäßig sichere Art zu installieren, und wird nicht versuchen, so paranoid wie andere Betriebssysteme zu sein, die Dienste standardmäßig abgeschaltet-Art installieren. In jedem Fall muss der System-Administrator die Sicherheit des System den lokalen Sicherheits-Regeln anpassen.
Debian enthält wirklich viele Pakete und unterschiedliche Software, wahrscheinlich sogar mehr, als mit manch einem proprietären Betriebssystem geliefert wird. Die heißt, 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ößeren Software-Komponenten, die Debian enthält. Wann immer eine solche Überprüfung eine größere Lücke findet, wird er repariert und ein Sicherheits-Gutachten wird an 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 Sicherheits-Gutachten (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).
Kurze Antwort: Nein.
Lange Antwort: Zertifikate kosten Geld und niemand hat Ressourcen 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 Ressourcen zur Verfügung, um dies Möglich zu machen.
Ja. Bastille Linux
,
ursprünglich an anderen Linux Distributionen (RedHat und Mandrake) orientiert,
funktioniert derzeit auch mit Debian. Es sind Maßnahmen 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 Absicherungs-Programm nicht die Notwendigkeit einer guten Administration eliminiert.
Einer der Vorteile von Debian, der die meisten neuen Administratoren verwirren könnte, ist, dass es eine große Zahl von Software, die den gleichen Dienst anbietet (DNS-Server, Mail-Server, FTP-Server, Web-Server...) enthält. Wenn Sie wissen wollen, welchen Server Sie installieren sollten, gibt es keine allgemein gü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:
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 Sicherheits-Hinweise für Unix-Systeme sind auch auf Debian anwendbar. So ist das Absichern vom Dienst X unter Debian meistens wie das absichern dieses Dienstes unter einer anderen Linux-Distribution (oder Unix, was das betrifft).
Das Sicherheits-Team von Debian kann nicht alle Pakete aus Debian auf
potentielle Sicherheits-Lücken hin analysieren, da es einfach nicht genug
Ressourcen gibt, um allen Quellcode zu prüfen. Dennoch profitiert Debian von
den Quellcode-Prüfungen durch den ursprünglichen Entwickler oder durch andere
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 diese 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 Lizenz-Klausel. Allerdings können Debian-Benutzer insofern Vertrauen fassen, dass der stabile Quellcode eine breite Prüfung hinter sich hat. Die meisten Probleme würden dabei durch Benutzung entdeckt. Keinesfalls ist es zu empfehlen, ungetestete Software auf wichtigen 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 Sicherheits-Problemen das Problem letztendlich zum Entwickler zurückgeführt werden kann. Das Debian Project hat diese Angelegenheiten nie auf die leichte Schulter genommen.
Ja und nein. Debian kommt mit einigen für bestimmte Dienste vordefinierten
Usern (ids < 99, beschrieben in der Debian Policy
). So
ist das Installation eines neuen Dienstes einfach (da dieser dann bereits als
ein passender User läuft). Wenn Sie nicht vorhaben, neue Dienste zu
installieren, können Sie die User, denen keine Dateien gehören und die keine
Dienste auf Ihrem System laufen lassen, entfernen.
User, denen keine Dateien gehören, finden Sie mit dem folgenden Kommando (stellen Sie sicher, dass Sie es als root ausführen, da ein normaler User nicht genug Zugriffsrechte hat, um einige sensible Verzeichnisse 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):
/var/spool/cups
der Gruppe sys.
/bin/sync
. Wenn das Passwort
auf etwas leicht zu ratendes gesetzt wurde (zum Beispiel ""), kann so
jeder das System von der Konsole aus synchronisieren lassen, auch wenn er
keinen Account auf dem System hat.
/var/cache/man
schreiben kann.
/var/mail
gehören der Gruppe mail, wie in
der Policy erklärt wird. Der User und die Gruppe werden zu verschiedenen
anderen Zwecken benutzt und für verschiedene MTAs.
/var/lib/postgresql
gehören diesem User, um anständige
Sicherheit zu gewährleisten.
Andere Gruppe, die keinen assoziierten User haben:
/var/log
lesen und die xconsole benutzen.
/var/log
war früher einmal /usr/adm
(und später
/var/adm
), daher der Name dieser Gruppe.
ppp
, dip
,
wvdial
usw. zu benutzen. Die User dieser Gruppe können das Modem
nicht konfigurieren, Sie können lediglich Programme aufrufen, die Sie benutzen.
/usr/share/doc/sudo/OPTIONS
.
/usr/src
. Sie kann benutzt werden, um einem bestimmten User die
Möglichkeit zu bieten, Quell-Code des Systems zu verwalten.
/etc/shadow
ist von dieser Gruppe lesbar. Einige
Programme, die auf diese Datei zugreifen müssen, sind sgid shadow.
/var/run/utmp
und ähnlichen Dateien
schreiben. Programme, die darin schreiben können müssen, sind sgid utmp.
/usr/local
, /home
), ohne dass Sie Root-Privilegien
bräuchten. Vergleichen Sie mit "adm", die sich mehr auf
beobachten/absichern bezieht.
'adm' sind Administratoren und ist meistens nützlich, um ihnen zu erlauben,
Log-Dateien zu lesen, ohne su
benutzen zu müssen. 'staff' ist
mehr bei den Helpdesk/junior Sysadmin Leuten nützlich, und gibt ihnen die
Möglichkeit, Dinge in /usr/local
zu erledigen und Verzeichnisse in
/home
anzulegen.
Das ist der Annäherung an das Problem, auf der einen Seite sicherheitsbewusst und auf der anderen Seite benutzerfreundlich zu sein. Anders als OpenBSD, das alle Dienste abschaltet, bis sie vom Administrator aktiviert werden, aktiviert Debian GNU/Linux alle installierten Dienste, bis sie abgeschaltet werden (siehe dazu Daemons abschalten, Abschnitt 3.6.1). Immerhin haben Sie den Dienst 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.
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 entweder abschalten (siehe Daemons abschalten, Abschnitt 3.6.1) oder
das Paket entfernen, indem Sie das Paket equivs
benutzen.
Port 111 ist sunrpcs Portmapper und wird standardmäßig 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-Diensten, Abschnitt 5.14 erklärt.
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 schließt dies mail, FTP und IRC Server ein, jedoch kann es auch dazu benutzt werden, um den User Ihrer Systeme zurück zu verfolgen, der einen Angriff gestartet hat.
Es gab ausführliche Diskussionen hierüber (siehe in den Mailing
List Archiven
. Grundsätzlich gilt: 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
).
Natürlich können Sie. Die Ports, die Sie offen lassen, hängen von Ihrem Regelwerk bezüglich öffentlich zugänglichen Diensten ab. Prüfen Sie, ob inetd (siehe Abschalten von inetd-Diensten, Abschnitt 3.6.2) oder ein anderes installiertes Paket sie öffnet und leiten Sie passende Maßnahmen ein (Konfigurieren von inetd, Entfernen des Pakets, Vermeiden dass der Dienst beim Booten gestartet wird...)
/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 verhindert üblicherweise nicht, dass ein Dienst 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 Dienst
abzuschalten, siehe Daemons abschalten,
Abschnitt 3.6.1.
Die nötigen Schritte, um wieder Zugriff erhalten, hängen davon ab, ob Sie die vorgeschlagene Prozedur zum Absichern von Lilo und 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, öffnen Sie das PC-Gehäuse, und entfernen die BIOS-Batterie.
Wenn Sie nun von CD-ROM oder Diskette booten können:
ae
, Debian 3.0
kommt mit nano-tiny
, der vi
etwas ähnelt) die Datei
/etc/shadow
und ändern Sie die Zeile:
root:asdfjl290341274075:XXXX:X:XXXX:X::: (X=irgendeine Ziffer)
in:
root::XXXX:X:XXXX:X:::
Dies entfernt das Root-Passwort. Sie können das System starten und sich am 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.
Falls Sie derartige Maßnahmen getroffen haben, müssen Sie im Single-User-Modus
starten. Wenn Sie LILO eingeschränkt haben, müssen LILO erneut ausführen,
nachdem Sie das Root-Passwort zurückgesetzt haben. Das ist trickreich, da Ihre
/etc/lilo.conf
nicht gefunden wird, und Ihr /-Dateisystem eine
RAM-Disk und keine echte Festplatte ist.
Sobald LILO nicht mehr eingeschränkt ist:
mount -o remount,rw /
passwd
(da Sie der Superuser
sind, werden Sie nicht nach Ihrem alten Passwort gefragt).
Wenn Sie zum Beispiel einen POP-Dienst anbieten wollen, müssen Sie nicht für
jeden zugreifenden User einen Account anlegen. Am besten setzen Sie hierzu
eine Verzeichnis-basierte Authentifizierung durch einen externen Dienst (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 Dienst, so dass er Ihr
Backend benutzt. Bearbeiten Sie dazu die dem Dienst entsprechende Datei 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 folgendermaßen:
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 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 letzten (bool'schen) Werte dazu benutzen, den Zugriff auf die verschiedenen Dienste entweder zu erlauben oder zu verbieten, indem Sie einfach die folgenden Zeilen in die Dateien einfügen:
/etc/pam.d/imap
:where=imap=1.
/etc/pam.d/qpopper
:where=pop=1.
/etc/nss-mysql*.conf
:users.where_clause = user.sys =
1;.
/etc/proftpd.conf
:SQLWhereClause "ftp=1".
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 Nach einer Kompromittierung, Kapitel 9). Beachten Sie auch, dass Angriffsspuren in den Logs mitunter bedeuten, dass sie hierfür bereits angreifbar sind (ein entschlossener Angreifer könnte übrigens auch andere Angriffe, als die von Ihnen beobachteten durchgeführt haben).
Wenn Ihr System keine hohe Last (und kaum laufende Dienste) 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 ist keine Kompromittierung, obwohl User, die von einer Debian-Release
wechseln, es vielleicht merkwürdig finden. Tatsächlich ist es 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äß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 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 einen Cron-Job 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
Lesen Sie dieses Dokument und leiten Sie passenden, hier dargestellten Maßnahmen ein. Wenn Sie Hilfe benötigen, wenden Sie sich an die Debian-Security-Mailingliste (debian-security@lists.debian.org) um Rat, wie Sie Ihr System wiederherstellen/patchen.
Durch Durchgehen der Logs (wenn Sie nicht geändert wurden), Benutzung eines
Intrusion-Detection-Systems (siehe Aufsetzen einer Eindringlings-Erkennung,
Abschnitt 8.1), traceroute
, whois
und ähnliche
Tools (einschließlich forensischer Analyse) können einen Angriff zu seinem
Ursprung zurückverfolgen. Wie Sie auf diese Informationen reagieren hängt
ausschließlich von Ihren Sicherheits-Regeln ab, und was Sie als
Angriff betrachten. Ist ein einfacher Scan ein Angriff? Ist die Prüfung auf
eine Verwundbarkeit ein Angriff?
Nehmen Sie sich einen Augenblick Zeit, um zu schauen, ob die
Angriffs-Mö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 Maßnahmen 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 detaillierten Beschreibung des Angriffs-Punktes (Code, der dies bestätigt, ist auch okay) an security@debian.org. Dort erreichen Sie das Sicherheits-Team.
Statt auf neue Releases zu aktualisieren, nehmen wir Sicherheits-Korrekturen an der Version vor, die in der stabilen Version enthalten ist. 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 als Resultat einer Sicherheits-Korrektur nicht unerwartet ändern oder kaputt gehen. Ob Sie eine sichere Version eines Paketes benutzen, prüfen Sie, 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.
Fügen Sie Ihrer Konfigurationsdatei DenyFilter \*.*/ hinzu. Mehr
Informationen entnehmen Sie http://www.proftpd.org/critbugs.html
.
Das Debian-Sicherheitsteam (siehe unten) informiert in diesen Gutachten über
die Verfügbarkeit und Bezugsquellen von Security-Fixes für das
Debian-Betriebssystem. Digital unterschriebene DSAs werden an eine öffentliche
Mailing-Liste gesendet und auf der Debian-Website veröffentlicht (sowohl auf
der Hauptseite als auch unter Sicherheits-Informationen
).
DSAs enthalten Informationen über beeinträchtigte Pakete, den entdeckten Fehler und wie man aktualisierte Pakete bekommt (und Ihre md5-Summen).
Dies ist wahrscheinlich ein Problem an Ihrem Ende. Der der debian-security-announce-Liste vorgeschaltete Filter lässt nur Nachrichten durch, die eine korrekte Signatur von einem Mitglied des Sicherheitsteams enthalten.
Wahrscheinlich verändert irgendeine Mail-Software an Ihrem Ende die E-Mail ein wenig und ruiniert damit die Unterschrift. Stellen Sie sicher, dass Ihre Software keine MIME-Kodierung oder -Dekodierung oder Tabulator/Leerzeichen-Konvertierung durchführt.
Bekannte Schuldige sind fetchmail (mit eingeschalteter mimedecode-Option) und formail (lediglich von procmail 3.14)
Sobald dem Sicherheitsteam ein Vorfall gemeldet wird, 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 des Problems 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, das dann auf allen stabilen Architekturen kompiliert und anschließend hoch geladen wird. Nachdem all dies getan ist, wird ein Debian-Sicherheitsgutachten (DSA) an die öffentliche Mailing-Liste geschickt.
Wie eine Analyse der Zeitspanne, in der das Debian-Sicherheitsteam nach Bekanntwerden einer Angriffsmöglichkeit ein Gutachten veröffentlicht und reparierte Pakete produziert, zeigt, dauert es nicht besonders lange, Angriffmöglichkeiten in Debian/stable zu reparieren.
Nach einem Report in
der debian-security Mail-Liste
vom Jahr 2001 benötigte das
Debian-Sicherheitsteam durchschnittlich 35 Tage, um eine sicherheitsrelevante
Angriffmöglichkeit zu reparieren. Über 50% der Angriffs-Punkte wurden jedoch
innerhalb eines Zeitrahmens von 10 Tagen beseitigt, und über 15% von ihnen noch
am gleichen Tag repariert.
Oft vergessen Leute, die diese Frage stellen, dass:
Die kurze Antwort ist: Gar nicht. Testing und unstable unterliegen stetigen Veränderungen, und das Sicherheits-Team hat nicht die benötigten Ressourcen, um diese richtig zu betreuen. Wenn Sie einen sicheren (und stabilen) Server haben möchten, sollten Sie bei stable bleiben.
Tatsächlich wird unstable normalerweise relativ schnell repariert, da Sicherheits-Updates für die aktuelle Version vom Programmautor schnell verfügbar sind (während auml;ltere Versionen wie die in stable normalerweise zurück portiert werden müssen).
Der Zweck von security.debian.org ist es, Sicherheits-Updates möglichst schnell und einfach zur Verfügung zu stellen. Mirrors machen dies unnötig komplizierten und erzeugen nur Frustration, wenn sie nicht aktuell gehalten werden.
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.
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 E-Mail auch mit dem Debian Security Contact Key (Key-Id 363CCD95) verschlüsselt werden.
Wenn Sie eine Nachricht an security@debian.org schicken, wird diese an die Developer Mailingliste geschickte (debian-private), die alle Debian Entwickler abonniert haben. Nachrichten an diese Liste werden vertraulich behandelt (d.h. nicht auf einer öffentlichen Web-Seite archiviert). debian-security@lists.debian.org ist eine öffentliche Mail-Liste, offen für jeden, der Sie abonnieren möchte, und es gibt ein auf den Web-Seiten ein durchsuchbares Archiv.
WNPP
bug
ein, und fragen nach Software, die Sie für nützlich halten, die
aber noch nicht zur Verfügung steht.
Linux
Kernel Security Audit Project
oder das Linux Security Audit Project
erhöhen
auch die Sicherheit von Debian GNU/Linux, da Beiträge dort letzten Endes auch
hier helfen.
Prüfen Sie bitte in jedem Fall nach, bevor Sie etwas an security@debian.org melden. Wenn Sie Patches beifügen, beschleunigt das den Prozess natürlich. Leiten Sie nicht einfach Mails von Bugtraq weiter, da diese bereits empfangen werden. Es ist aber eine gute Idee, zusätzliche Informationen zu schicken.
Das Debian-Sicherheitsteam besteht derzeit aus fünf Mitgliedern und zwei Sekretären. Das Sicherheitsteam lädt selbst Personen zum Beitritt ein.
Nein, weder prüft das Sicherheitsteam jedes neue Paket noch gibt es einen automatischen (lintian) Test, um neue Pakete mit bösartigem Inhalt 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. Keine Software wird eingeführt, die nicht zuerst von einem autorisierten Entwickler signiert wurde. Sie sind selbst dafür verantwortlich, die Software, die Sie einsetzen, zu analysieren und auf Sicherheit zu achten.
Leider nein. Das Debian-Sicherheitsteam kann leider nicht sowohl die stabile Release (inoffiziell also auch unstable) als auch ältere Releases unterstützen. Für einen begrenzten Zeitraum (normalerweise mehrere Monate) nach der Veröffentlichung einer neuen Debian Distribution können Sie jedoch Sicherheits-Updates erwarten.
Anleitung zum Absichern von Debian
Version: 2.5 (beta), Fri, 03 Dec 2004 23:31:52 +0000jfs@debian.org