Das FreeBSD-Core-Team hat die Zuständigkeit für sicherheitsrelevante Fragen an den FreeBSD-Security-Officer @@ -79,7 +79,7 @@ insbesondere die nachstehenden Rechte:
Ein neuer Security-Officer wird vom vorigen Security-Officer - ernannt und vom Core-Team im Amt bestätigt. Der - Security-Officer ist gegenüber dem Core-Team + ernannt und vom Core Team im Amt bestätigt. Der + Security-Officer ist gegenüber dem Core Team verantwortlich.
Die Mitglieder des Security-Officer-Teams werden vom diff --git a/de_DE.ISO8859-1/htdocs/security/reporting.xml b/de_DE.ISO8859-1/htdocs/security/reporting.xml new file mode 100644 index 0000000000..93543c9bf9 --- /dev/null +++ b/de_DE.ISO8859-1/htdocs/security/reporting.xml @@ -0,0 +1,182 @@ + + + + + + +]> + + +
+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:
+ +Der Security-Officer oder ein Mitglied des Security-Officer-Teams + wird Sie ansprechen, nachdem Sie ein Problem gemeldet haben.
+ +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.
+ + +Damit Sicherheitsprobleme schnell bearbeitet werden, + werden E-Mails an den Security-Officer Alias <security-officer@FreeBSD.org> + an folgende Personen weitergeleitet:
+ +| &a.des.email; | +Security Officer | +
| &a.delphij.email; | +Deputy Security Officer | +
| &a.simon.email; | +Security Officer Emeritus | +
| &a.cperciva.email; | +Security Officer Emeritus | +
| &a.rwatson.email; | +Release Engineering liaison, + TrustedBSD-Project, Experte für Sicherheitsarchitekturen |
+
Der Security-Officer wird vom FreeBSD Security Team + (<secteam@FreeBSD.org>), + einer von ihm ausgewählten Gruppe von Committern, + unterstützt.
+ + +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.
+ + diff --git a/de_DE.ISO8859-1/htdocs/security/security.xml b/de_DE.ISO8859-1/htdocs/security/security.xml index 2a7c067044..86e75152f9 100644 --- a/de_DE.ISO8859-1/htdocs/security/security.xml +++ b/de_DE.ISO8859-1/htdocs/security/security.xml @@ -2,7 +2,7 @@ - + @@ -19,302 +19,123 @@Diese Webseite gibt Einsteigern und erfahrenen Benutzern - Hilfestellungen zum Thema Sicherheit. Bei FreeBSD wird - Sicherheit groß geschrieben: Wir arbeiten ständig - daran, das Betriebssystem so sicher wie möglich zu machen.
+Bei FreeBSD wird Sicherheit groß geschrieben: Wir arbeiten ständig + daran, das Betriebssystem so sicher wie möglich zu machen. Diese + Seit erklärt, was Sie tun müssen, wenn Ihr System von einer + Sicherheitslücke betroffen ist.
-Melden Sie Sicherheitsprobleme in FreeBSD direkt an das - Security-Team oder, +
Melden Sie Sicherheitsprobleme in FreeBSD 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). Wenn Sie ein Problem melden, geben Sie bitte - folgende Informationen an:
+ Security Officers). Weitere Informationen finden Sie auf der + Seite FreeBSD Sicherheitsprobleme melden. + +Der Security-Officer oder ein Mitglied des Security-Officer-Teams - wird Sie ansprechen, nachdem Sie ein Problem gemeldet haben.
+ +Eine vollständige Liste aller bekannten Sicherheitslücken finden + Sie hier.
-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.
+ +Für die meisten Benutzer ist der einfachste Weg, ihr + unterstütztes &os; &rel.current; oder &rel2.current;-System + zu aktualisieren, die Ausführung der folgenden Befehle:
-Damit Sicherheitsprobleme schnell bearbeitet werden, - wird die E-Mail an das Security-Officer Alias an drei - Personen ausgeliefert: den Security-Officer, den - Deputy-Security-Officer und ein Mitglied des - Core-Teams. Zurzeit werden E-Mails an <security-officer@FreeBSD.org> - an die folgenden Personen geliefert:
+ # freebsd-update fetch| &a.simon; <simon@FreeBSD.org> | -Security Officier | -
| &a.cperciva; <cperciva@FreeBSD.org> | -Security Officer Emeritus | -
| &a.rwatson; <rwatson@FreeBSD.org> | -Release-Engineering, - TrustedBSD-Project, Experte für Sicherheitsarchitektur |
-
Der Security-Officer wird vom FreeBSD Security Team - (<secteam@FreeBSD.org>), - einer von ihm ausgewählten Gruppe von Committern, - unterstützt.
- - -Generell veröffentlicht der Security-Officer nach einer - angemessenen Zeit alle Informationen über ein Sicherheitsproblem. - Die 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 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 (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 Einreichen - 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.
- - +Sollte dieser Weg fehlschlagen, folgen Sie bitte den Anweisungen + des jeweiligen Sicherheitshinweises.
+ +Der FreeBSD-Security-Officer gibt Sicherheitshinweise - für verschiedene FreeBSD-Entwicklungszweige heraus: - Die -STABLE-Zweige und die Sicherheits-Zweige. - Für den -CURRENT-Zweig werden keine - Sicherheitshinweise herausgegeben.
- -Die -STABLE-Zweige haben Namen wie RELENG_7. Auf - diesen Zweigen erstellte Versionen tragen Namen wie - FreeBSD 7.0-STABLE.
-Jedes FreeBSD-Release besitzt einen Sicherheits-Zweig. - Die Tags der Sicherheits-Zweige haben Namen wie - RELENG_7_0. Die daraus gebauten FreeBSD-Versionen - tragen Namen wie FreeBSD 7.0-RELEASE-p1.
-Sicherheitshinweise für die FreeBSD-Ports-Collection - werden auf der Seite FreeBSD VuXML - veröffentlicht.
- -Jeder Zweig wird vom Security-Officer nur für eine begrenzte - Zeit gewartet. Die Zweige werden in Klassen - eingeteilt, die den Wartungszeitraum bestimmen:
- -Die Einteilung und Wartungsenden der momentan unterstützten - Releases finden Sie in der folgenden Tabelle. Die Spalte - Wartungsende gibt den frühest möglichen - Zeitpunkt an, an dem ein Zweig aus der Wartung läuft. - Beachten Sie, dass die Zeiträume verlängert werden - können, aber nur besondere Umstände dazu führen, - dass ein Zweig vorzeitig aus der Wartung genommen wird.
+Die folgende Tabelle enthält die Bezeichnungen und erwartete + Lebenszeit aller aktuell unterstützten Entwicklungszweige. 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.
+| Zweig | Release | -Klasse | -veröffentlicht | -Wartungsende | +Typ | +Releasedatum | +Erwartetes EoL | ||
|---|---|---|---|---|---|---|---|---|---|
| RELENG_7 | +stable/9 | n/a | n/a | n/a | -28. Februar 2013 | +31. Dezember 2016 | |||
| RELENG_7_4 | -7.4-RELEASE | -erweitert | -24. Februar 2011 | -28. Februar 2013 | +releng/9.3 | +9.3-RELEASE | +Erweitert | +16. Juli 2014 | +31. Dezember 2016 |
| RELENG_8 | +stable/10 | n/a | n/a | n/a | letztes Release + 2 Jahre | ||||
| RELENG_8_3 | -8.3-RELEASE | -erweitert | -18. April 2012 | -30. April 2014 | +releng/10.1 | +10.1-RELEASE | +Erweitert | +14. November 2014 | +31. Dezember 2016 |
| RELENG_9 | -n/a | -n/a | -n/a | -letztes Release + 2 Jahre | +releng/10.2 | +10.2-RELEASE | +Normal | +13. August 2015 | +31. Dezember 2016 |
| RELENG_9_0 | -9.0-RELEASE | -normal | -10. Januar 2012 | -31. Januar 2013 | +releng/10.3 | +10.3-RELEASE | +Erweitert | +4. April 2016 | +30. April 2018 |
Ältere Releases werden nicht mehr gepflegt. Benutzer - solcher Releases sollten dringend auf eine oben aufgeführte - unterstützte Release aktualisieren.
+Ältere Versionen werden nicht mehr unterstützt und wir empfehlen + allen Benutzern dringend, ihr System auf eine unterstützte + Version zu aktualisieren. Eine Liste aller nicht mehr unterstützten + Versionen finden Sie hier.
-Die Hinweise werden an die folgenden FreeBSD-Mailinglisten +
Sicherheitshinweise werden an die folgenden FreeBSD-Mailinglisten versendet:
Die Hinweise werden immer mit dem +
Sicherheitshinweise werden immer mit dem PGP-Schlüssel des FreeBSD-Security-Officers signiert und gemeinsam mit den zugehörigen Patches auf dem Server advisories sowie patches archiviert.
- -Der FreeBSD-Security-Officer gibt Sicherheitshinweise + für verschiedene FreeBSD-Entwicklungszweige heraus: + Die -STABLE-Zweige und die Sicherheits-Zweige (für + den -CURRENT-Zweig werden hingegen keine Sicherheitshinweise + herausgegeben).
-Die folgenden Versionen werden nicht mehr unterstützt. Die - folgende Auflistung dient daher nur Informationszwecken.
+Die -STABLE-Zweige haben Namen wie stable/10. Auf + diesen Zweigen erstellte Versionen tragen Namen wie + FreeBSD 10.1-STABLE.
+| Zweig | -Release | -Klasse | -veröffentlicht | -Wartungsende | -
|---|---|---|---|---|
| RELENG_4 | -n/a | -n/a | -n/a | -31. Januar 2007 | -
| RELENG_4_11 | -4.11-RELEASE | -Erweitert | -25. Januar 2005 | -31. Januar 2007 | -
| RELENG_5 | -n/a | -n/a | -n/a | -31. Mai 2008 | -
| RELENG_5_3 | -5.3-RELEASE | -Erweitert | -6. November 2004 | -31. Oktober 2006 | -
| RELENG_5_4 | -5.4-RELEASE | -Normal | -9. Mai 2005 | -31. Oktober 2006 | -
| RELENG_5_5 | -5.5-RELEASE | -Erweitert | -25. Mai 2006 | -31. Mai 2008 | -
| RELENG_6 | -n/a | -n/a | -n/a | -30. November 2010 | -
| RELENG_6_0 | -6.0-RELEASE | -Normal | -4. November 2005 | -31. Januar 2007 | -
| RELENG_6_1 | -6.1-RELEASE | -Erweitert | -9. Mai 2006 | -31. Mai 2008 | -
| RELENG_6_2 | -6.2-RELEASE | -Normal | -15. Januar 2007 | -31. Mai 2008 | -
| RELENG_6_3 | -6.3-RELEASE | -Erweitert | -18. Januar 2008 | -31. Januar 2010 | -
| RELENG_6_4 | -6.4-RELEASE | -Erweitert | -28. November 2008 | -30. November 2010 | -
| RELENG_7_0 | -7.0-RELEASE | -Normal | -27. Februar 2008 | -30. April 2009 | -
| RELENG_7_1 | -7.1-RELEASE | -Erweitert | -04. Januar 2009 | -28. Februar 2011 | -
| RELENG_7_2 | -7.2-RELEASE | -Normal | -4. Mai 2009 | -30. Juni 2010 | -
| RELENG_7_3 | -7.3-RELEASE | -erweitert | -23. März 2010 | -31. März 2012 | -
| RELENG_8_0 | -8.0-RELEASE | -Normal | -25. November 2009 | -30. November 2010 | -
| RELENG_8_1 | -8.1-RELEASE | -erweitert | -23. Juli 2010 | -31. Juli 2012 | -
| RELENG_8_2 | -8.2-RELEASE | -normal | -24. Februar 2011 | -31. Juli 2012 | -