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 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.
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).
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.
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.
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:
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).
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.
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):
/var/spool/cups
der Gruppe sys.
/bin/sync
. Wenn das Passwort
auf etwas leicht zu ratendes gesetzt wurde (sum Beispiel ""), kann so
jeder das System von der Konsole aus syncen, 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 verschiedenen MTAs.
/var/lib/postgresql
gehören diesem User, um
anständige Sicherheit zu gewährleisten.
Andere Gruppe, die keinen assozierten 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
Madem 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 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.
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.
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.
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.
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
).
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...)
/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.
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:
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=irgendeien Ziffer)
nach:
root::XXXX:X:XXXX:X:::
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:
mount -o remount,rw /
passwd
(da Sie der
Superuser sind, werden Sie nicht nach Ihrem alten Passwort gefragt werden).
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:
/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 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).
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.
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
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.
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?
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.
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.
Fügen Sie DenyFilter \*.*/ Ihrer Konfigurations Datei hinzu.
Mehr Informationen entnehmen Sie http://www.proftpd.org/critbugs.html
.
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).
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)
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.
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:
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).
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.
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 Email 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 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.
WNPP bug
ein, und fragen
Sie nach Software, von der Sie glauben, dass Sie nützlich wäre, die
aber noch nicht zur Verfügung steht.
Linux
Kernel Security Audit Project
oder das Linux Security-Audit Project
erhöhen auch die Sicherheits von Debian GNU/Linux, da Beitraä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 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.
Debians Sicherheit Team besteht derzeit aus fünf Mitgliedern und zwei Sekretären. Das Sicherheits Team lädt Personen selbst ein, beizutreten.
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.
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.
Anleitung zum Absichern von Debian
2.5 (beta) 20 septiembre 2003Sat, 17 Aug 2002 12:23:36 +0200jfs@computer.org