MFbed: Add the translated security page.

This commit is contained in:
Martin Heinen 2004-01-11 00:32:03 +00:00
parent bd6661e246
commit 4c2c5fab41
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/www/; revision=19588
4 changed files with 734 additions and 5 deletions

View file

@ -1,7 +1,7 @@
# The FreeBSD Documentation Project
# The FreeBSD German Documentation Project
# $FreeBSD$
# $FreeBSDde: de-www/Makefile,v 1.20 2003/12/26 11:50:22 mheinen Exp $
# $FreeBSDde: de-www/Makefile,v 1.21 2004/01/05 11:08:11 mheinen Exp $
# basiert auf: 1.105
.if exists(Makefile.conf)
@ -35,6 +35,7 @@ SUBDIR+= FAQ
SUBDIR+= handbook
SUBDIR+= platforms
SUBDIR+= releases
SUBDIR+= security
.if !defined(WEB_ONLY) || empty(WEB_ONLY)
#SUBDIR+= ports
SUBDIR+= doc

View file

@ -1,6 +1,6 @@
# $FreeBSD$
# $FreeBSDde: de-www/security/Makefile,v 1.1 2003/05/11 17:43:18 mheinen Exp $
# basiert auf: 1.7
# $FreeBSDde: de-www/security/Makefile,v 1.2 2004/01/05 11:08:12 mheinen Exp $
# basiert auf: 1.9
.if exists(../Makefile.conf)
.include "../Makefile.conf"
@ -9,8 +9,16 @@
.include "../Makefile.inc"
.endif
#DOCS= security.sgml
DOCS= security.sgml
#INDEXLINK= security.html
INDEXLINK= security.html
.include "${WEB_PREFIX}/share/mk/web.site.mk"
CLEANFILES+= advisories.html.inc
security.html: advisories.html.inc
advisories.html.inc: mkindex.xsl ${XML_ADVISORIES}
${XSLTPROC} ${XSLTPROCOPTS} -o ${.TARGET} \
${.CURDIR}/mkindex.xsl ${XML_ADVISORIES}

50
de/security/mkindex.xsl Normal file
View file

@ -0,0 +1,50 @@
<?xml version="1.0"?>
<!--
$FreeBSD$
$FreeBSDde: de-www/security/mkindex.xsl,v 1.1 2004/01/05 11:08:12 mheinen Exp $
basiert auf: 1.2
-->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:import href="../includes.xsl"/>
<xsl:variable name="base" select="'.'"/>
<xsl:variable name="date" select="'$FreeBSD$'"/>
<xsl:variable name="title" select="'untitled'"/>
<xsl:variable name="ftpbase" select="'ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/'" />
<xsl:variable name="ftpbaseold" select="'ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/old/'" />
<xsl:variable name="ulopen" select="'&lt;ul&gt;'" />
<xsl:variable name="ulclose" select="'&lt;/ul&gt;'" />
<xsl:output type="xml" encoding="iso-8859-1"
omit-xml-declaration="yes" />
<xsl:template match="/">
<xsl:value-of select="$ulopen" disable-output-escaping="yes" />
<xsl:for-each select="descendant::advisory|descendant::release">
<xsl:choose>
<xsl:when test="self::release">
<xsl:value-of select="$ulclose" disable-output-escaping="yes" />
<p><xsl:value-of select="name"/> ver&#246;ffentlicht.</p>
<xsl:value-of select="$ulopen" disable-output-escaping="yes" />
</xsl:when>
<xsl:when test="self::advisory">
<li>
<xsl:choose>
<xsl:when test="./name/@role='old'">
<a><xsl:attribute name="href"><xsl:value-of select="concat($ftpbaseold, name, '.asc')" /></xsl:attribute><xsl:value-of select="concat(name, '.asc')" /></a>
</xsl:when>
<xsl:otherwise>
<a><xsl:attribute name="href"><xsl:value-of select="concat($ftpbase, name, '.asc')" /></xsl:attribute><xsl:value-of select="concat(name, '.asc')" /></a> </xsl:otherwise>
</xsl:choose>
</li>
</xsl:when>
</xsl:choose>
</xsl:for-each>
<xsl:value-of select="$ulclose" disable-output-escaping="yes" />
</xsl:template>
</xsl:stylesheet>

670
de/security/security.sgml Normal file
View file

@ -0,0 +1,670 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD$">
<!ENTITY dedate "$FreeBSDde: de-www/security/security.sgml,v 1.2 2004/01/10 01:28:39 mheinen Exp $">
<!ENTITY reference "basiert auf: 1.149">
<!ENTITY title "FreeBSD Sicherheit">
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
<!ENTITY advisories.html.inc SYSTEM "advisories.html.inc">
]>
<html>
&header;
<h2>Einf&uuml;hrung</h2>
<p>Diese Webseite gibt Einsteigern und erfahrenen Benutzern
Hilfestellungen zum Thema Sicherheit. Bei FreeBSD wird
Sicherheit gro&szlig; geschrieben: Wir arbeiten st&auml;ndig
daran, das Betriebssystem so sicher wie m&ouml;glich zu machen.</p>
<p>Im Folgenden finden Sie Informationen zu verschiedenen
Sicherheitsaspekten, beispielsweise wie Sie ein System
vor bestimmten Angriffen sch&uuml;tzen und wenn Sie
ansprechen k&ouml;nnen, wenn Sie einen sicherheitsrelevanten
Fehler finden. Ein gesonderter Abschnitt f&uuml;r Entwickler
erl&auml;utert Ma&szlig;nahmen, die Sicherheistl&uuml;cken
in Programmen verhindern.</p>
<h2>Inhalt</h2>
<ul>
<li><a href="#sec">Der FreeBSD Security-Officer</a></li>
<li><a href="#pol">Umgang mit Informationen</a></li>
<li><a href="#adv">FreeBSD Sicherheits-Hinweise</a></li>
<li><a href="#ml">Mailinglisten zum Thema Sicherheit</a></li>
<li><a href="#spg">Richtlinien zum sicheren Programmieren</a></li>
<li><a href="#tat">FreeBSD sichern</a></li>
<li><a href="#misc">Ma&szlig;nahmen bei einem Sicherheitsvorfall</a></li>
</ul>
<a name="sec"></a>
<h2>Der FreeBSD Security-Officer und das Security-Officer-Team</h2>
<p>Um z&uuml;gig sicherheitsrelevante Informationen mit anderen
auszutauschen, besitzt das FreeBSD Project einen zentralen
Ansprechpartner: Den FreeBSD Security-Officer.</p>
<p>Wenn Sie ein Sicherheitsproblem an das FreeBSD Project
melden wollen, schreiben Sie eine
<a href="mailto:security-officer@FreeBSD.org">E-Mail
an den Security-Officer</a>. Beschreiben Sie in der
E-Mail die entdeckte Sicherheitsl&uuml;cke.</p>
<p>Damit Sicherheitsprobleme schnell bearbeitet werden,
wird die E-Mail an das Security-Officer Alias an vier
Personen ausgeliefert: den Security-Officer, den
Deputy-Security-Officer und zwei Mitglieder des
Core-Teams. Zurzeit werden E-Mails an <a
href="mailto:security-officer@FreeBSD.org">&lt;security-officer@FreeBSD.org&gt;</a>
an die folgenden Personen geliefert:</p>
<table>
<tr valign="top">
<td>Jacques Vidrine <a
href="mailto:nectar@FreeBSD.org">&lt;nectar@FreeBSD.org&gt;</a></td>
<td>Security-Officer</td>
</tr>
<tr valign="top">
<td>Chris Faulhaber <a
href="mailto:jedgar@FreeBSD.org">&lt;jedgar@FreeBSD.org&gt;</a></td>
<td>Deputy-Security-Officer</td>
</tr>
<tr valign="top">
<td>Robert Watson <a
href="mailto:rwatson@FreeBSD.org">&lt;rwatson@FreeBSD.org&gt;</a></td>
<td>FreeBSD Core-Team, Release-Engineering,<br>
TrustedBSD-Project, Experte f&uuml;r Sicherheitsarchitektur</td>
</tr>
<tr valign="top">
<td>Warner Losh <a
href="mailto:imp@FreeBSD.org">&lt;imp@FreeBSD.org&gt;</a></td>
<td>FreeBSD Core-Team, Security-Officer-Emeritus</td>
</tr>
</table>
<p>Der Security-Officer wird vom
<a href="mailto:security-team@FreeBSD.org">FreeBSD-Security-Team
&lt;security-team@FreeBSD.org&gt;</a> unterst&uuml;tzt.
Das Team besteht aus einer Gruppe von Committern, die vom
Security-Officer ausgew&auml;hlt werden.</p>
<p>Verschl&uuml;sseln Sie E-Mails mit dem <a
href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/public_key.asc">PGP-Schl&uuml;ssel
des Security-Officers</a>, wenn dies erforderlich
ist.</p>
<a name="pol"></a>
<h2>Umgang mit Informationen</h2>
<p>Generell ver&ouml;ffentlicht der Security-Officer nach einer
angemessenen Zeit alle Informationen &uuml;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.</p>
<p>Der Security-Officer <em>wird</em> einen oder mehrere der
<a href="mailto:admins@FreeBSD.org">Administratoren des
FreeBSD-Clusters</a> &uuml;ber Sicherheitsprobleme informieren,
die Ressourcen des FreeBSD Projects bedrohen.</p>
<p>Der Security-Officer kann weitere FreeBSD-Entwickler oder
externe Entwickler hinzuziehen, wenn dies zur Beurteilung
oder L&ouml;sung des Sicherheitsproblems notwendig ist.
Ein diskretes Vorgehen verhindert die unn&ouml;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.</p>
<p>Wenn gerade ein Release erstellt wird, kann der FreeBSD
Release-Engineer ebenfalls &uuml;ber das Sicherheitsproblem
und dessen Ausma&szlig;e unterrichtet werden. Damit k&ouml;nnen
fundierte Entscheidungen &uuml;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.</p>
<p>Der Security-Officer arbeitet eng mit anderen Organisationen
zusammen. Dazu z&auml;hlen Dritthersteller, die Quellcode
von FreeBSD benutzen (OpenBSD, NetBSD, Apple und andere
Hersteller, die Software auf Basis von FreeBSD vertreiben,
sowie die Linux-Vendor-Security Liste) und Organisationen,
die Sicherheitsproblemen und Sicherheitsvorf&auml;llen
nachgehen, beispielsweise das CERT. Oft haben Sicherheitsprobleme
Auswirkungen, die &uuml;ber FreeBSD hinausgehen. Sie
k&ouml;nnen auch (vielleicht weniger h&auml;ufig) gro&szlig;e
Teile des Internets betreffen. Unter diesen Umst&auml;nden
wird der Security-Officer andere Organisationen &uuml;ber
das Sicherheitsproblem informieren wollen. Wenn Sie das nicht
w&uuml;nschen, vermerken Sie das bitte explizit beim Einreichen
eines Sicherheitsproblems.</p>
<p>Besondere Anforderungen an den Umgang mit den eingereichten
Information m&uuml;ssen ausdr&uuml;cklich angegeben werden.</p>
<p>Wenn die Ver&ouml;ffentlichung des Sicherheitsproblems mit
dem Einsender und/oder anderen Lieferanten abgestimmt werden
soll, so muss dies ausdr&uuml;cklich beim Einreichen des
Problems angegeben werden. Ist dies nicht vermerkt, legt
der Security-Officer einen Zeitplan f&uuml;r die
Ver&ouml;ffentlichung des Problems fest. Der Zeitplan
ber&uuml;cksichtigt die m&ouml;glichst schnelle
Ver&ouml;ffentlichung und die zum Testen von L&ouml;sungen
ben&ouml;tigte Zeit. Wenn das Problem schon in &ouml;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.</p>
<p>Einsender von Sicherheitsproblemen sollte bewusst sein, dass
FreeBSD ein Open-Source-Projekt ist. Jede &Auml;nderung
des FreeBSD-Quellbaums ist &ouml;ffentlich und jedem
zug&auml;nglich. Stellt der Einsender einen Zeitplan
zur Verf&uuml;gung, sollte der Plan die Zeitspanne zwischen
der Aufnahme der Fehlerbehebung in den Quellbaum und der
Ver&ouml;ffentlichung ber&uuml;cksichtigen. Die Zeitspanne
ist n&ouml;tig, da der Hinweis, die Fehlerbehebungen und die
bin&auml;ren Patche mithilfe eines Versionierungs-Systems
erstellt werden,</p>
<p>Eingesendete Sicherheitsprobleme k&ouml;nnen mit PGP gesch&uuml;tzt
werden. Auf Wunsch werden die Antworten ebenfalls mit PGP
gesch&uuml;tzt.</p>
<a name="adv"></a>
<h2>FreeBSD Sicherheits-Hinweise</h2>
<p>Der FreeBSD-Security-Officer gibt Sicherheitshinweise
f&uuml;r verschiedene FreeBSD-Entwicklungszweige heraus:
Die <em>-STABLE-Zweige</em> und die <em>Sicherheits-Zweige</em>.
F&uuml;r den <em>-CURRENT-Zweig</em> werden keine
Sicherheitshinweise herausgegeben.</p>
<ul>
<li>
<p>Normalerweise gibt es nur einen -STABLE-Zweig. Bei einem
&Uuml;bergang von einer Hauptversion zu einer neuen
Hauptversion (wie von FreeBSD 4.X zu 5.X) gibt es
allerdings zeitweise zwei -STABLE-Zweige. Die Tags
der -STABLE-Zweige haben Namen wie <tt>RELENG_4</tt>.
Die daraus gebauten FreeBSD-Versionen werden beispielsweise
<tt>FreeBSD 4.6-STABLE</tt> genannt.</p>
</li>
<li>
<p>Jedes FreeBSD-Release besitzt einen Sicherheits-Zweig.
Die Tags der Sicherheits-Zweige haben Namen wie
<tt>RELENG_4_6</tt>. Die daraus gebauten FreeBSD-Versionen
tragen Namen wie <tt>FreeBSD 4.6-RELEASE-p7</tt>.</p>
</li>
</ul>
<p>Jeder Zweig wird vom Security-Officer nur f&uuml;r eine begrenzte
Zeit unterst&uuml;tzt, typischerweise f&uuml;r 12&nbsp;Monate
nach der Ver&ouml;ffentlichung. Wann die momentan
unterst&uuml;tzten Releases auslaufen, ist in der Tabelle
unten aufgef&uuml;hrt. Die Spalte <em>Wartungsende</em>
gibt den fr&uuml;hest m&ouml;glichen Zeitpunkt an, an dem
ein Zweig ausl&auml;uft. Beachten sie, dass die Zeitpunkte
nach hinten verschoben werden k&ouml;nnen, aber nur besondere
Umst&auml;nde dazu f&uuml;hren, dass ein Zweig vorher aus
der Wartung genommen wird.</p>
<table border="3" cellspacing="0" cellpadding="2">
<tr>
<th>Zweig</th>
<th>Release</th>
<th>Wartungsende</th>
</tr>
<tr>
<td>RELENG_4</td>
<td>-</td>
<td>31. Oktober 2004</td>
</tr>
<tr>
<td>RELENG_4_8</td>
<td>4.8-RELEASE</td>
<td>31. M&auml;rz 2004</td>
</tr>
<tr>
<td>RELENG_4_9</td>
<td>4.9-RELEASE</td>
<td>31. Oktober 2004</td>
</tr>
<tr>
<td>RELENG_5_1</td>
<td>5.1-RELEASE</td>
<td>28. Februar 2004</td>
</tr>
</table>
<p>&Auml;ltere Releases werden nicht mehr gepflegt. Benutzer
solcher Releases sollten dringend auf eine oben aufgef&uuml;hrte
unterst&uuml;tzte Release aktualisieren.</p>
<p>Wie alle Entwicklungen werden Fehlerbehebungen zuerst
in den <a href="../doc/en_US.ISO8859-1/books/handbook/cutting-edge.html#CURRENT">FreeBSD-CURRENT</a>-Zweig
gebracht. Nach einigen Tagen und Abschlu&szlig; der Tests
wird die Fehlerbehebung auf die unterst&uuml;tzten -STABLE-Zweige
angepasst und der Sicherheitshinweis wird ver&ouml;ffentlicht.</p>
<p>Ein paar Zahlen zu den im Jahr 2002 ver&ouml;ffentlichten Hinweisen:</p>
<ul>
<li>44 Hinweise von unterschiedlicher Schwere betrafen das
Basissystem.</li>
<li>12 Hinweise davon betrafen nur FreeBSD. Die restlichen
32&nbsp;Hinweise betrafen auch mindestens ein anderes
Betriebssystem. Dies wurde haupts&auml;chlich durch gemeinsam
benutzte Code-Teile verursacht.</li>
<li>Es wurden 6&nbsp;Mitteilungen herausgegeben, die auf
95&nbsp;Probleme mit Software Dritter aus der Ports-Collection
hinwiesen.</li>
</ul>
<p>Die Hinweise werden an die folgenden FreeBSD-Mailinglisten
versendet:</p>
<ul>
<li>FreeBSD-security-notifications@FreeBSD.org</li>
<li>FreeBSD-security@FreeBSD.org</li>
<li>FreeBSD-announce@FreeBSD.org</li>
</ul>
<p>Die Hinweise werden immer mit dem
<a href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/public_key.asc">PGP-Schl&uuml;ssel</a>
des FreeBSD-Security-Officers signiert. Die Hinweise werden
zusammen mit den Fehlerbehebungen in unserem
<a href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/index.html">FTP
CERT-Repository</a> abgelegt. Zurzeit sind folgende Hinweise
verf&uuml;gbar (die Liste kann ein paar Tage alt sein,
die neusten Hinweise finden Sie auf unserem
<a href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/">FTP-Server</a>):</p>
&advisories.html.inc;
<a name="ml"></a>
<h2>Mailinglisten zum Thema Sicherheit</h2>
<p>Wenn Sie ein FreeBSD-System administrieren oder benutzen,
sollten Sie eine oder mehrere der nachstehenden Listen
abonnieren:</p>
<table>
<tr>
<td><a href="http://lists.freebsd.org/mailman/listinfo/freebsd-security">freebsd-security</a></td>
<td>Allgemeine Diskussion &uuml;ber Sicherheit</td>
</tr>
<tr>
<td><a href="http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications">freebsd-security-notifications</a></td>
<td>Ank&uuml;ndigungen zum Thema Sicherheit (wenig Verkehr)</td>
</tr>
</table>
<a name="spg"></a>
<h2>Richtlinien zum sicheren Programmieren</h2>
<ul>
<li>Vertrauen Sie keinen Eingaben wie Kommandozeilenargumenten,
Umgebungsvariablen, Konfigurationsdateien, eingehenden
TCP/UDP/ICMP-Paketen, Namensaufl&ouml;sungen und Funktionsparametern.
Wenn Sie die L&auml;nge der eingehenden Daten oder die eingehenden
Daten selbst nicht kontrollieren k&ouml;nnen, sollten Sie
vorsichtig beim Kopieren der Daten sein. Achten Sie insbesondere
auf die folgenden Punkte:
<ul>
<li>Aufrufe von strcpy() und sprintf() mit Daten unbekannter
L&auml;nge. Wenn die L&auml;nge bekannt ist, verwenden Sie
strncpy() und snprintf() (oder sorgen Sie selbst daf&uuml;r,
dass Puffer nicht &uuml;berschrieben werden, wenn die
L&auml;nge unbekannt ist). Verwenden Sie nie gets()
oder sprintf(), Punkt!
<li>Wenn Sie Benutzereingaben auf unerw&uuml;nschte Zeichen
pr&uuml;fen, suchen Sie <em>nicht</em> nach diesen
unerw&uuml;nschten Zeichen. Pr&uuml;fen Sie stattdessen,
dass die Eingabe <em>nur</em> aus erlaubten Zeichen besteht.
Die allgemeine Regel lautet: Verbieten Sie alles, was
nicht ausdr&uuml;cklich erlaubt ist.</li>
<li>Lesen Sie die Hilfeseiten der Funktionen strncpy() und
strncat(). Sie m&uuml;ssen verstanden haben, wie die
Funktionen arbeiten. Mit strncpy() wird die abschlie&szlig;ende
\0 vielleicht nicht angeh&auml;ngt, mit strncat() schon.</li>
<li>Achten Sie auf den Missbrauch der Funktionen
strvis() und getenv(). Bei strvis() ist oft der Ziel-String
zu kurz. getenv() kann l&auml;ngere Zeichenfolgen
zur&uuml;ckgeben als Sie erwarten. Beide Funktionen
werden oft ausgenutzt um ein Programm anzugreifen.
Meist wird dabei der Stack oder Variablen &uuml;berschrieben
oder Umgebungsvariablen enthalten unerwartete Werte.
Wenn Ihr Programm Umgebungsvariablen ben&ouml;tigt, werden
Sie paranoid, werden Sie richtig paranoid!</li>
<li>Jedes Mal, wenn Sie die Funktionen open() oder stat()
benutzen, fragen Sie sich: "Was passiert, wenn die
Funktionen auf einen symbolischen Link angewendet
werden?"</li>
<li>Benutzen Sie mkstemp() anstelle von Funktionen wie
mktemp() oder tempnam(). Achten Sie auf <em>Race-Conditions</em>
insbesondere im Verzeichnis /tmp. Es gibt nur wenige
atomare Operationen in Verzeichnissen:
<ul>
<li>Anlegen eines Verzeichnisses. Diese Operation
gelingt oder schl&auml;gt fehl.</li>
<li>&Ouml;ffnen einer Datei mit O_CREAT | O_EXCL.</li>
</ul>
<li>Legen Sie tempor&auml;re Dateien immer mit mkstemp(),
an, da mit dieser Funktion <em>Race-Conditions</em>
und falsche Zugriffsrechte verhindert werden.</li>
<li>Wenn ein Angreifer Pakete auf ein beliebiges System
umleiten kann, dann hat er die vollst&auml;ndige
Kontrolle &uuml;ber Daten, die wir erhalten. Diesen
Daten kann <b>nicht</b> vertraut werden.</li>
<li>Setzen Sie nie voraus, dass eine Konfigurationsdatei
richtig formatiert ist oder mit dem passenden Werkzeug
erstellt wurde. Verlassen Sie sich nicht darauf, dass
Benutzereingaben, wie Terminalnamen oder Spracheinstellungen,
frei von Zeichenfolgen wie '/' oder '../../../' sind,
wenn diese Eingaben in Pfadnamen verwendet werden k&ouml;nnen.
Mi&szlig;trauen Sie <b>jeder</b> Pfadangabe des Benutzers,
wenn ein Programm unter root-Rechten (SUID) l&auml;uft.</li>
<li>Achten Sie auf Sicherheitsl&ouml;cher, wenn Daten
gespeichert werden. Um unberechtigte Zugriffe zu verhindern,
werden tempor&auml;re Dateien mit den Zugriffsrechten
600 angelegt.</li>
<li>Beschr&auml;nken Sie sich nicht auf die &uuml;blichen
Verd&auml;chtigen, wenn Sie ein Programm mit erh&ouml;hten
Rechten kontrollieren. Pr&uuml;fen Sie Zeile f&uuml;r Zeile
des Programms, da es neben strcpy() noch viele andere
Ursachen f&uuml;r Puffer&uuml;berl&auml;ufe gibt.</li>
<li>Die Aufgabe erh&ouml;hter Rechte alleine verhindert
keinen Einbruch. Ein Angreifer kann Code auf dem
Stack platzieren, der die Rechte wiedererlangt,
bevor /bin/sh ausgef&uuml;hrt wird.</li>
</ul>
</li>
<li>Verwalten Sie UIDs, geben Sie erh&ouml;hte Rechte so
schnell wie m&ouml;glich auf und geben Sie die Rechte
wirklich auf. Es ist unzureichend, zwischen der EUID und
der UID zu wechseln. Benutzen Sie die Funktion setuid()
wo Sie k&ouml;nnen.</li>
<li>Verzichten Sie im Fehlerfall auf die Ausgabe von
Konfigurationsdateien. Eine Zeilennummer und vielleicht
die Spaltennummer der Zeile reichen v&ouml;llig aus. Dies
gilt f&uuml;r alle Bibliotheken und Programme, die SUID
oder SGID laufen.</li>
<li>Wenn Sie Quelltext auf Sicherheitsprobleme untersuchen,
beachten Sie bitte die nachstehenden Hinweise:
<ul>
<li>Arbeiten Sie mit einem zweiten Pr&uuml;fer zusammen.
Wenn Sie sich bei einer Problembehebung nicht ganz
sicher sind, lassen Sie die Behebung durch den zweiten
Pr&uuml;fer begutachten. Falls Sie sich unsicher sind,
&auml;ndern Sie nichts. Es ist peinlich, wenn durch
die Behebung eines Sicherheitsproblems neue Probleme
entstehen.</li>
<li>Zu den letzten, die eine Problembehebung pr&uuml;fen,
sollte jemand mit commit-Rechten geh&ouml;ren. Diese
Person wird die Problembehebung nochmals begutachten
und in den CVS-Baum einbringen.</li>
<li>Schicken Sie &Auml;nderungen zur Begutachtung immer
im context- oder unified-Ausgabeformat von diff ein;
die &Auml;nderungen k&ouml;nnen so leicht mit patch(1)
weiterverarbeitet werden. Reichen Sie nicht die
vollst&auml;ndigen Dateien ein. Die Differenzen
sind leichter zu lesen und lassen sich leichter auf
einen lokalen Quellbaum anwenden, besonders wenn sie
mehrere &Auml;nderungen enthalten. Erzeugen Sie die
Differenzen bitte aus dem -CURRENT-Entwicklungszweig.</li>
<li>Testen Sie immer die &Auml;nderungen (&uuml;bersetzen
Sie die betroffenen Quellen und lassen Sie das neue
Programm laufen), bevor Sie &Auml;nderungen einschicken.
Niemand will kaputte Fehlerbehebungen pr&uuml;fen und
das Vertrauen in den Ersteller der Behebung sinkt, weil
er sich offensichtlich nicht die M&uuml;he gemacht hat,
die &Auml;nderung zu pr&uuml;fen. Wenn Sie Zugang zu
Maschinen brauchen, auf denen eine bestimmte Software-Version
installiert ist, fragen Sie einfach. Genau f&uuml;r
solche F&auml;lle besitzt das Projekt die entsprechenden
Mittel.</li>
<li>Anmerkung f&uuml;r Committer: Stellen Sie Problembehebungen
aus -CURRENT auch in -STABLE ein, wenn es n&ouml;tig ist.</li>
<li>Passen Sie den Quelltext nicht grundlos an Ihren
Stil oder ihre Vorlieben an &ndash; das erschwert
die Begutachtung der &Auml;nderung nur unn&ouml;tig.
F&uuml;hren Sie nur dann Stil&auml;nderungen durch,
wenn es daf&uuml;r berechtigte Gr&uuml;nde gibt.</li>
</ul>
</li>
<li>Achten Sie auf Programme, die komplizierte Funktionen zur
Signalbehandlung besitzen. Viele Funktionen verschiedener
Bibliotheken sind nicht reentrant
<li>Schauen sie sich den Gebrauch der Funktion realloc()
genau an &ndash; die Funktion wird oft falsch verwendet.</li>
<li>Wenn Sie feste Puffergr&ouml;&szlig;en verwenden,
benutzen Sie die Funktion sizeof(). Sie verhindert Fehler,
wenn die Puffergr&ouml;&szlig;e ver&auml;ndert aber
der restliche Quelltext nicht angepasst wird. Ein Beispiel:
<pre>
char buf[1024];
struct foo { ... };
...
SCHLECHT:
xxx(buf, 1024)
xxx(yyy, sizeof(struct foo))
GUT:
xxx(buf, sizeof(buf))
xxx(yyy, sizeof(yyy))
</pre>
Verwechseln sie nicht die Gr&ouml;&szlig;e eines Zeigers
mit der Gr&ouml;&szlig;e der Daten, auf die der Zeiger zeigt!</li>
<li>Wenn Sie <tt>char foo[###]</tt> sehen, pr&uuml;fen Sie
jeden Gebrauch der Variablen foo und stellen Sie sicher,
dass kein Puffer&uuml;berlauf m&ouml;glich ist. Wenn Sie
einen Puffer&uuml;berlauf nicht verhindern k&ouml;nnen
(das gibt es wirklich), fordern Sie den Speicher f&uuml;r
den Puffer wenigstens mit malloc() an. Dies verhindert
m&ouml;gliche Zugriffe auf den Stack.</li>
<li>Schlie&szlig;en Sie Dateideskriptoren so schnell wie
m&ouml;glich &ndash; die stdio-Puffer werden so wahrscheinlich
schneller entleert. In Bibliotheksfunktionen m&uuml;ssen
Dateideskriptoren immer <em>close-on-exec</em> (sie
werden nach fork()/exec() automatisch geschlossen) angelegt
werden.</li>
</ul>
<p>Der Port its4 ist ein brauchbares Audit-Werkzeug.
Sie finden den Port unter /usr/ports/security/its4/.
Der Port pr&uuml;ft automatisch C-Quelltexte und zeigt
Problemstellen auf. Das Werkzeug ist f&uuml;r eine erste
Pr&uuml;fung gut geeignet, allerdings sollten Sie sich
nicht nur auf den Port its4 verlassen. Ein vollst&auml;ndiger
Audit sollte von einem Menschen durchgef&uuml;hrt werden,
der den ganzen Quelltext untersucht.</p>
<p>Zus&auml;tzliche Ressourcen und mehr &uuml;ber sicheres
Programmieren finden Sie auf der Webseite
<a href="http://www.shmoo.com/securecode/">How to Write Secure Code</a>.</p>
<a name="tat"></a>
<h2>FreeBSD sichern</h2>
<p>FreeBSD, oder jedes andere &unix; System, k&ouml;nnen
Sie mit den nachstehenden Schritten sichern:</p>
<ul>
<li>Deaktivieren Sie potentiell gef&auml;hrliche Programme:<br>
Viele Programme laufen unter besonders berechtigten
Benutzern (SUID), um auf bestimmte Ressourcen zuzugreifen.
UUCP oder PPP zum Beispiel ben&ouml;tigen einen
speziellen Netzwerk-Port, sendmail ben&ouml;tigt
Zugriff auf das Spool-Verzeichnis und einen speziellen
Netzwerk-Port. Wenn Sie UUCP nicht
verwenden, k&ouml;nnen Sie es auch deaktivieren.
Nat&uuml;rlich m&uuml;ssen Sie Ihr System gut kennen,
um entscheiden zu k&ouml;nnen, welche Programme Sie
nicht ben&ouml;tigen und welche Programme Sie vielleicht
sp&auml;ter einmal ben&ouml;tigen werden.<br>
Einige Werkzeuge, wie swapinfo, die Sie vielleicht nicht
besonders n&uuml;tzlich finden, stellen ebenfalls ein
Sicherheitsrisiko dar. Wenn Sie mit <tt>chmod ug-s filename</tt>
das SUID-Bit des Programms entfernen, k&ouml;nnen Sie
swapinfo immer noch als root ausf&uuml;hren. Es ist
allerdings keine gute Idee so viele SUID-Bits zu
entfernen, dass Sie nur noch als root arbeiten k&ouml;nnen.<br>
Neben Programmen sollten Sie auch Dienste deaktivieren,
die Sie nicht ben&ouml;tigen. In den Dateien
<tt>/etc/inetd.conf</tt> und <tt>/etc/rc.conf</tt> sollten
Sie alle Dienste deaktivieren, die Sie nicht benutzen.</li>
<li>Schlie&szlig;en Sie Sicherheitsl&ouml;cher (oder wie Sie
den Crackern einen Schritt voraus sind):<br>
Abonnieren Sie die <a href="#ml">FreeBSD
Sicherheits-Mailinglisten</a>. So erhalten Sie Informationen
&uuml;ber Sicherheitsl&ouml;cher und deren Behebung. Sobald
eine L&ouml;sung f&uuml;r ein Sicherheitsproblem existiert,
wenden Sie die L&ouml;sung an.</li>
<li>Datensicherungen &ndash; Reparieren Sie Ihr System nach
einem Sicherheitsvorfall:<br>
Halten Sie aktuelle Datensicherungen und eine saubere
Kopie des Betriebssystems (zum Beispiel auf CD-ROM) vor.
Stellen Sie sicher, dass die Datensicherungen keine
von Angreifern besch&auml;digte oder ver&auml;nderte
Daten enthalten.</li>
<li>Installieren Sie Software, die den Status des Systems
&uuml;berwacht:<br>
Programme wie die TCP-Wrapper oder Tripwire (beide
sind als Paket oder aus den Ports installierbar) helfen,
die Vorg&auml;nge auf einem System zu &uuml;berwachen.
Mit diesen Werkzeugen werden Sie Einbr&uuml;che leichter
erkennen. Lesen Sie auch die t&auml;glichen Ausgaben
der /etc/security-Skripten, die root zugeschickt werden.</li>
<li>Schulen Sie die Benutzer des Systems:<br>
Benutzer sollten wissen, was sie tun. Niemand sollte einem
Anderen sein Passwort geben. Die Benutzer sollen keine leicht
zu erratenden Passw&ouml;rter verwenden. Kl&auml;ren Sie
die Benutzer dar&uuml;ber auf, dass sie f&uuml;r die System-
und Netzwerksicherheit mitverantwortlich sind.</li>
</ul>
<p>Das FreeBSD Security How-To enth&auml;lt weiterf&uuml;hrende
Tipps, mit denen Sie die Sicherheit Ihres Systems verbessern
k&ouml;nnen. Das How-To finden Sie unter der URL
<a href="http://www.FreeBSD.org/~jkb/howto.html">http://www.FreeBSD.org/~jkb/howto.html</a>.</p>
<p>Sicherheit ist ein kontinuierlicher Prozess. Verfolgen
Sie die Entwicklungen im Sicherheits-Umfeld.</p>
<a name="misc"></a>
<h2>Ma&szlig;nahmen bei einem Sicherheitsvorfall</h2>
<ul>
<li><b>Bestimmen Sie das Ausma&szlig; des Vorfalls</b><br>
Welche Rechte hat der Angreifer erlangt? Hat der
Angreifer root-Zugriff bekommen? Oder hat der
Angreifer lediglich normale Benutzerrechte erhalten?</li>
<li><b>Bestimmen Sie, ob sich etwas am Systemzustand (Kernel
oder Userland) ver&auml;ndert hat</b><br>
Welche Software wurde ver&auml;ndert? Wurde ein neuer
Kernel installiert? Wurden Systemprogramme (wie telnetd
oder login) ver&auml;ndert? Wenn ein Angreifer das
Betriebssystem ver&auml;ndert hat, sollten Sie das
System von einem sicheren Medium neu installieren.</li>
<li><b>Finden Sie heraus wie der Einbruch ver&uuml;bt
wurde</b><br>
Nutzte der Einbrecher ein bekanntes Sicherheitsloch aus?
In diesem Fall installieren Sie die richtigen Fehlerbehebungen.
Wurde der Einbruch durch eine Fehlkonfiguration m&ouml;glich?
War der Einbruch durch ein bisher unbekanntes Sicherheitsloch
m&ouml;glich? Wenn Sie glauben, ein neues Sicherheitsloch
entdeckt zu haben, benachrichtigen Sie bitte den
<a href="mailto:security-officer@FreeBSD.org">FreeBSD
Security-Officer</a>.</li>
<li><b>Schlie&szlig;en Sie das Sicherheitsloch</b><br>
Installieren Sie neue Software oder wenden Sie Fehlerbehebungen
auf alte Software an. Sperren Sie missbrauchte
Benutzerkonten.</li>
<li><b>Weitere Ressourcen</b><br>
Das <a href="http://www.cert.org">CERT</a> bietet
<a href="http://www.cert.org/nav/recovering.html">genaue
Anleitungen</a> zum Umgang mit Sicherheitsvorf&auml;llen.</li>
</ul>
<h2>Weitere Informationsquellen</h2>
<ul>
<li><a href="http://www.cerias.purdue.edu/coast/archive/index.html">The
COAST archive</a> enth&auml;lt eine gro&szlig;e Sammlung von
sicherheitsrelevantem Material.</li>
<li><a href="http://www.cerias.purdue.edu/infosec/hotlist/">The
Center for Education and Research in Information Assurance
and Security (CERIAS)</a> enth&auml;lt alles was Sie &uuml;ber
Sicherheit erfahren wollen.</li>
<li>Die Seiten verschiedener CERTs wie
<a href="http://www.cert.org">http://www.cert.org</a> und
<a href="http://www.auscert.org.au">http://www.auscert.org.au</a>.</li>
<li>Mailinglisten wie <a
href="http://www.securityfocus.com/forums/bugtraq/intro.html">Bugtraq</a>
und <a href="http://list.nfr.com/forum/firewall-wizards.html">Firewall
Wizards</a>.</li>
</ul>
&footer
</body>
</html>