Index: head/de_DE.ISO8859-1/htdocs/security/Makefile =================================================================== --- head/de_DE.ISO8859-1/htdocs/security/Makefile (revision 52924) +++ head/de_DE.ISO8859-1/htdocs/security/Makefile (revision 52925) @@ -1,19 +1,19 @@ # $FreeBSD$ # $FreeBSDde$ -# basiert auf: r50897 +# basiert auf: r52778 .if exists(../Makefile.conf) .include "../Makefile.conf" .endif .if exists(../Makefile.inc) .include "../Makefile.inc" .endif DOCS= charter.xml DOCS+= reporting.xml DOCS+= security.xml DOCS+= unsupported.xml INDEXLINK= security.html .include "${DOC_PREFIX}/share/mk/web.site.mk" Index: head/de_DE.ISO8859-1/htdocs/security/reporting.xml =================================================================== --- head/de_DE.ISO8859-1/htdocs/security/reporting.xml (revision 52924) +++ head/de_DE.ISO8859-1/htdocs/security/reporting.xml (revision 52925) @@ -1,177 +1,190 @@ - + ]> &title; $FreeBSD$

Inhalt

Sicherheitsprobleme melden

Melden Sie Sicherheitsprobleme in FreeBSD direkt an das Security-Team oder, falls eine höhere Vertraulichkeit erforderlich ist, PGP-verschlüsselt an das Security-Officer-Team (verwenden Sie dazu den öffentlichen PGP-Schlüssel des Security Officers).

Sicherheitsprobleme, die die Ports-Sammlung betreffen, sollten hingegen an das FreeBSD Ports Security Team gemeldet werden.

Wenn Sie ein Problem melden, geben Sie bitte mindestens folgende Informationen an:

+

Versuchen Sie dabei soweit als möglich die entsprechenden + Vorlagen für Sicherheitshinweise + und Problemhinweise + zu verwenden, um Ihre Umgebung, die Beschreibung des Problems, + dessen Auswirkungen sowie (falls vorhanden) einen Workaround zu + dokumentieren.

+

Der Security-Officer oder ein Mitglied des Security-Officer-Teams wird Sie ansprechen, nachdem Sie ein Problem gemeldet haben.

Spam-Filter

Aufgrund des hohen Spam-Aufkommen durchlaufen alle an die Hauptadresse des Security-Teams gerichteten E-Mails einen Spam-Filter. Können Sie den FreeBSD Security Officer oder das FreeBSD Security Team nicht erreichen, weil Ihre E-Mail vom Spam-Filter verworfen wird (oder falls Sie vermuten, dass dies der Fall ist), so senden Sie Ihre E-Mail bitte an die Adresse security-officer-XXXX@FreeBSD.org, wobei Sie XXXX durch 3432 ersetzen. Beachten Sie, dass diese Adresse regelmäßig geändert wird. Alle E-Mails, die Sie an diese Adresse senden, werden an das FreeBSD Security Officer Team weitergeleitet.

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

Damit Sicherheitsprobleme schnell bearbeitet werden, werden E-Mails an den Security-Officer Alias <security-officer@FreeBSD.org> an folgende Personen weitergeleitet:

+ + + +
&a.gordon.email; Security Officer
&a.emaste.email;Deputy Security Officer
&a.remko.email; Deputy Security Officer
&a.delphij.email; Security Officer Emeritus
&a.des.email; Security Officer Emeritus

Der Security-Officer wird vom FreeBSD Security Team (<secteam@FreeBSD.org>), einer von ihm ausgewählten Gruppe von Committern, unterstützt.

Umgang mit Informationen

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

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

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

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

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

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

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

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

Index: head/de_DE.ISO8859-1/htdocs/security/security.xml =================================================================== --- head/de_DE.ISO8859-1/htdocs/security/security.xml (revision 52924) +++ head/de_DE.ISO8859-1/htdocs/security/security.xml (revision 52925) @@ -1,220 +1,212 @@ - + ]> &title; $FreeBSD$

Einführung

Bei FreeBSD wird Sicherheit groß geschrieben: Wir arbeiten ständig daran, das Betriebssystem so sicher wie möglich zu machen. Diese Seite erklärt, was Sie tun müssen, wenn Ihr System von einer Sicherheitslücke betroffen ist.

Inhaltsverzeichnis

FreeBSD Sicherheitsprobleme melden

Melden Sie Sicherheitsprobleme im Basissystem direkt an das FreeBSD Security Team oder, falls eine höhere Vertraulichkeit erforderlich ist, PGP-verschlüsselt an das Security-Officer-Team (verwenden Sie dazu den öffentlichen PGP-Schlüssel des Security Officers). Weitere Informationen finden Sie auf der Seite FreeBSD Sicherheitsprobleme melden.

Aktuelle FreeBSD Sicherheitslücken

Eine vollständige Liste aller bekannten Sicherheitslücken des Basissystems finden Sie hier.

FreeBSD Sicherheitshinweise verstehen

Sicherheitshinweise werden an die folgenden FreeBSD-Mailinglisten versendet:

Eine Liste aller bisher veröffentlichten Sicherheitshinweise findet sich auf der Seite FreeBSD Security Advisories.

Sicherheitshinweise werden immer mit dem PGP-Schlüssel des FreeBSD-Security-Officers signiert und gemeinsam mit den zugehörigen Patches auf dem Server http://security.FreeBSD.org/ in den Unterverzeichnissen advisories sowie patches archiviert.

Der FreeBSD-Security-Officer gibt Sicherheitshinweise für die FreeBSD-Entwicklungszweige -STABLE und Security heraus. Für -CURRENT (der sich primär an &os;-Entwickler wendet), werden hingegen keine Sicherheitshinweise herausgegeben.

Sicherheitshinweise für die FreeBSD Ports-Sammlung werden auf der Seite FreeBSD VuXML veröffentlicht.

Wie Sie Ihr System aktualisieren können

Benutzer, die eine Binärversion von &os; (beispielsweise &rel.current; oder &rel2.current;) installiert haben, können ihr System einfach wie folgt aktualisieren:

# freebsd-update fetch
# freebsd-update install

Sollte dieser Weg fehlschlagen, folgen Sie bitte den Anweisungen des jeweiligen Sicherheitshinweises.

Beachten Sie, dass diese Art der Aktualisierung nur möglich ist, wenn Sie eine Binärversion von &os; installiert haben. Haben Sie Ihr System hingegen aus dem Quellcode gebaut, müssen Sie Ihren Quellcodebaum aktualisieren und das System neu bauen.

Unterstützte FreeBSD-Versionen

Jedes Release wird nur eine bestimmte Zeit vom Security Officer unterstützt.

Die folgende Tabelle enthält die Bezeichnungen und erwartete Lebenszeit aller aktuell unterstützten Entwicklungszweige (und deren Releases). Die Spalte Erwartetes EoL (end-of-life) gibt den frühestmöglichen Zeitpunkt an, an dem die Unterstützung für einen bestimmten Zweig eingestellt wird. Beachten Sie, dass dieser Zeitpunkt (falls nötig) auch nach hinten verschoben werden kann.

Ältere Versionen werden nicht mehr unterstützt und wir empfehlen allen Benutzern dringend, ihr System auf eine unterstützte Version zu aktualisieren:

Zweig Release Typ Releasedatum Erwartetes EoL
stable/12 n/a n/a n/a 30. Juni 2020 (TBD)
releng/12.0 12.0-RELEASE n/a 11. Dezember 2018 12.1-RELEASE + 3 Monate
stable/11 n/a n/a n/a 30. September 2021
releng/11.2 11.2-RELEASE n/a 28. Juni 2018 11.3-RELEASE + 3 Monate

Während der Entwicklung eines Releases werden -BETA- und -RC-Releases veröffentlicht. Diese Releases werden nur (im Rahmen der Möglichkeiten) für einige Wochen unterstützt und werden daher nicht auf dieser Seite aufgeführt. Wir raten Benutzern dringend davon ab, diese Versionen auf einem Produktivsystem einzusetzen.

Das FreeBSD-Supportmodell

Beginnend mit &os; 11.0-RELEASE wurde das Supportmodell angepasst, um einerseits eine schnellere Entwicklung zu ermöglichen und andererseits weiterhin zeitnahe Sicherheitsupdates für alle unterstützten Versionen bereitstellen zu können.

Unter dem aktuellen Supportmodell wird jede Hauptversion explizit für 5 Jahre unterstützt, während jede Unterversion nur noch 3 Monate nach Erscheinen der folgenden Unterversion unterstützt wird.

Diese Entscheidung wurde im Februar 2015 getroffen. Die Gründe dafür können in der offiziellen Ankündigung nachgelesen werden.

- -

Bitte beachten Sie aber, dass das Core Team gemeinsam mit den - Engineering, Security und Port Manager Teams entschieden hat, dieses - Modell (beginnend mit stable/12) zu überprüfen.

- -

Weitere Informationen dazu finden Sie in der - offiziellen Ankündigung vom November 2018.