diff options
| author | Martin Heinen <mheinen@FreeBSD.org> | 2004-01-11 00:32:03 +0000 |
|---|---|---|
| committer | Martin Heinen <mheinen@FreeBSD.org> | 2004-01-11 00:32:03 +0000 |
| commit | 4c2c5fab41175cdc039d7f4982ada7dc294c6fbb (patch) | |
| tree | 509919adec126328b3f955f2d9b5c54dc1a3b71e /de/security | |
| parent | bd6661e246691f41d269f8a37b7be4c29c396119 (diff) | |
Notes
Diffstat (limited to 'de/security')
| -rw-r--r-- | de/security/Makefile | 16 | ||||
| -rw-r--r-- | de/security/mkindex.xsl | 50 | ||||
| -rw-r--r-- | de/security/security.sgml | 670 |
3 files changed, 732 insertions, 4 deletions
diff --git a/de/security/Makefile b/de/security/Makefile index 9e3f8d5d85..49c76d175e 100644 --- a/de/security/Makefile +++ b/de/security/Makefile @@ -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} diff --git a/de/security/mkindex.xsl b/de/security/mkindex.xsl new file mode 100644 index 0000000000..e3742a129b --- /dev/null +++ b/de/security/mkindex.xsl @@ -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="'<ul>'" /> + <xsl:variable name="ulclose" select="'</ul>'" /> + + <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ö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> diff --git a/de/security/security.sgml b/de/security/security.sgml new file mode 100644 index 0000000000..4fbc08e0e1 --- /dev/null +++ b/de/security/security.sgml @@ -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ührung</h2> + + <p>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.</p> + + <p>Im Folgenden finden Sie Informationen zu verschiedenen + Sicherheitsaspekten, beispielsweise wie Sie ein System + vor bestimmten Angriffen schützen und wenn Sie + ansprechen können, wenn Sie einen sicherheitsrelevanten + Fehler finden. Ein gesonderter Abschnitt für Entwickler + erläutert Maßnahmen, die Sicherheistlü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ß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ü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ü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"><security-officer@FreeBSD.org></a> + an die folgenden Personen geliefert:</p> + + <table> + <tr valign="top"> + <td>Jacques Vidrine <a + href="mailto:nectar@FreeBSD.org"><nectar@FreeBSD.org></a></td> + <td>Security-Officer</td> + </tr> + <tr valign="top"> + <td>Chris Faulhaber <a + href="mailto:jedgar@FreeBSD.org"><jedgar@FreeBSD.org></a></td> + <td>Deputy-Security-Officer</td> + </tr> + <tr valign="top"> + <td>Robert Watson <a + href="mailto:rwatson@FreeBSD.org"><rwatson@FreeBSD.org></a></td> + <td>FreeBSD Core-Team, Release-Engineering,<br> + TrustedBSD-Project, Experte für Sicherheitsarchitektur</td> + </tr> + <tr valign="top"> + <td>Warner Losh <a + href="mailto:imp@FreeBSD.org"><imp@FreeBSD.org></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 + <security-team@FreeBSD.org></a> unterstützt. + Das Team besteht aus einer Gruppe von Committern, die vom + Security-Officer ausgewählt werden.</p> + + <p>Verschlüsseln Sie E-Mails mit dem <a + href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/public_key.asc">PGP-Schlüssel + des Security-Officers</a>, wenn dies erforderlich + ist.</p> + + <a name="pol"></a> + <h2>Umgang mit Informationen</h2> + + <p>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.</p> + + <p>Der Security-Officer <em>wird</em> einen oder mehrere der + <a href="mailto:admins@FreeBSD.org">Administratoren des + FreeBSD-Clusters</a> ü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ö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.</p> + + <p>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.</p> + + <p>Der Security-Officer arbeitet eng mit anderen Organisationen + zusammen. Dazu zä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ä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.</p> + + <p>Besondere Anforderungen an den Umgang mit den eingereichten + Information müssen ausdrücklich angegeben werden.</p> + + <p>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.</p> + + <p>Einsender von Sicherheitsproblemen sollte bewusst sein, dass + FreeBSD ein Open-Source-Projekt ist. Jede Änderung + des FreeBSD-Quellbaums ist öffentlich und jedem + zugänglich. Stellt der Einsender einen Zeitplan + zur Verfügung, sollte der Plan die Zeitspanne zwischen + der Aufnahme der Fehlerbehebung in den Quellbaum und der + Veröffentlichung berücksichtigen. Die Zeitspanne + ist nötig, da der Hinweis, die Fehlerbehebungen und die + binären Patche mithilfe eines Versionierungs-Systems + erstellt werden,</p> + + <p>Eingesendete Sicherheitsprobleme können mit PGP geschützt + werden. Auf Wunsch werden die Antworten ebenfalls mit PGP + geschützt.</p> + + <a name="adv"></a> + <h2>FreeBSD Sicherheits-Hinweise</h2> + + <p>Der FreeBSD-Security-Officer gibt Sicherheitshinweise + für verschiedene FreeBSD-Entwicklungszweige heraus: + Die <em>-STABLE-Zweige</em> und die <em>Sicherheits-Zweige</em>. + Für den <em>-CURRENT-Zweig</em> werden keine + Sicherheitshinweise herausgegeben.</p> + + <ul> + <li> + <p>Normalerweise gibt es nur einen -STABLE-Zweig. Bei einem + Ü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ür eine begrenzte + Zeit unterstützt, typischerweise für 12 Monate + nach der Veröffentlichung. Wann die momentan + unterstützten Releases auslaufen, ist in der Tabelle + unten aufgeführt. Die Spalte <em>Wartungsende</em> + gibt den frühest möglichen Zeitpunkt an, an dem + ein Zweig ausläuft. Beachten sie, dass die Zeitpunkte + nach hinten verschoben werden können, aber nur besondere + Umstände dazu fü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ä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>Ältere Releases werden nicht mehr gepflegt. Benutzer + solcher Releases sollten dringend auf eine oben aufgeführte + unterstü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ß der Tests + wird die Fehlerbehebung auf die unterstützten -STABLE-Zweige + angepasst und der Sicherheitshinweis wird veröffentlicht.</p> + + <p>Ein paar Zahlen zu den im Jahr 2002 veröffentlichten Hinweisen:</p> + + <ul> + <li>44 Hinweise von unterschiedlicher Schwere betrafen das + Basissystem.</li> + <li>12 Hinweise davon betrafen nur FreeBSD. Die restlichen + 32 Hinweise betrafen auch mindestens ein anderes + Betriebssystem. Dies wurde hauptsächlich durch gemeinsam + benutzte Code-Teile verursacht.</li> + <li>Es wurden 6 Mitteilungen herausgegeben, die auf + 95 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ü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ü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 über Sicherheit</td> + </tr> + <tr> + <td><a href="http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications">freebsd-security-notifications</a></td> + <td>Ankü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ösungen und Funktionsparametern. + Wenn Sie die Länge der eingehenden Daten oder die eingehenden + Daten selbst nicht kontrollieren kö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änge. Wenn die Länge bekannt ist, verwenden Sie + strncpy() und snprintf() (oder sorgen Sie selbst dafür, + dass Puffer nicht überschrieben werden, wenn die + Länge unbekannt ist). Verwenden Sie nie gets() + oder sprintf(), Punkt! + + <li>Wenn Sie Benutzereingaben auf unerwünschte Zeichen + prüfen, suchen Sie <em>nicht</em> nach diesen + unerwünschten Zeichen. Prüfen Sie stattdessen, + dass die Eingabe <em>nur</em> aus erlaubten Zeichen besteht. + Die allgemeine Regel lautet: Verbieten Sie alles, was + nicht ausdrücklich erlaubt ist.</li> + + <li>Lesen Sie die Hilfeseiten der Funktionen strncpy() und + strncat(). Sie müssen verstanden haben, wie die + Funktionen arbeiten. Mit strncpy() wird die abschließende + \0 vielleicht nicht angehä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ängere Zeichenfolgen + zurückgeben als Sie erwarten. Beide Funktionen + werden oft ausgenutzt um ein Programm anzugreifen. + Meist wird dabei der Stack oder Variablen überschrieben + oder Umgebungsvariablen enthalten unerwartete Werte. + Wenn Ihr Programm Umgebungsvariablen benö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ägt fehl.</li> + <li>Öffnen einer Datei mit O_CREAT | O_EXCL.</li> + </ul> + + <li>Legen Sie temporä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ändige + Kontrolle ü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önnen. + Mißtrauen Sie <b>jeder</b> Pfadangabe des Benutzers, + wenn ein Programm unter root-Rechten (SUID) läuft.</li> + + <li>Achten Sie auf Sicherheitslöcher, wenn Daten + gespeichert werden. Um unberechtigte Zugriffe zu verhindern, + werden temporäre Dateien mit den Zugriffsrechten + 600 angelegt.</li> + + <li>Beschränken Sie sich nicht auf die üblichen + Verdächtigen, wenn Sie ein Programm mit erhöhten + Rechten kontrollieren. Prüfen Sie Zeile für Zeile + des Programms, da es neben strcpy() noch viele andere + Ursachen für Pufferüberläufe gibt.</li> + + <li>Die Aufgabe erhöhter Rechte alleine verhindert + keinen Einbruch. Ein Angreifer kann Code auf dem + Stack platzieren, der die Rechte wiedererlangt, + bevor /bin/sh ausgeführt wird.</li> + </ul> + </li> + + <li>Verwalten Sie UIDs, geben Sie erhöhte Rechte so + schnell wie mö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önnen.</li> + + <li>Verzichten Sie im Fehlerfall auf die Ausgabe von + Konfigurationsdateien. Eine Zeilennummer und vielleicht + die Spaltennummer der Zeile reichen völlig aus. Dies + gilt fü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üfer zusammen. + Wenn Sie sich bei einer Problembehebung nicht ganz + sicher sind, lassen Sie die Behebung durch den zweiten + Prüfer begutachten. Falls Sie sich unsicher sind, + ändern Sie nichts. Es ist peinlich, wenn durch + die Behebung eines Sicherheitsproblems neue Probleme + entstehen.</li> + + <li>Zu den letzten, die eine Problembehebung prüfen, + sollte jemand mit commit-Rechten gehören. Diese + Person wird die Problembehebung nochmals begutachten + und in den CVS-Baum einbringen.</li> + + <li>Schicken Sie Änderungen zur Begutachtung immer + im context- oder unified-Ausgabeformat von diff ein; + die Änderungen können so leicht mit patch(1) + weiterverarbeitet werden. Reichen Sie nicht die + vollständigen Dateien ein. Die Differenzen + sind leichter zu lesen und lassen sich leichter auf + einen lokalen Quellbaum anwenden, besonders wenn sie + mehrere Änderungen enthalten. Erzeugen Sie die + Differenzen bitte aus dem -CURRENT-Entwicklungszweig.</li> + + <li>Testen Sie immer die Änderungen (übersetzen + Sie die betroffenen Quellen und lassen Sie das neue + Programm laufen), bevor Sie Änderungen einschicken. + Niemand will kaputte Fehlerbehebungen prüfen und + das Vertrauen in den Ersteller der Behebung sinkt, weil + er sich offensichtlich nicht die Mühe gemacht hat, + die Änderung zu prüfen. Wenn Sie Zugang zu + Maschinen brauchen, auf denen eine bestimmte Software-Version + installiert ist, fragen Sie einfach. Genau für + solche Fälle besitzt das Projekt die entsprechenden + Mittel.</li> + + <li>Anmerkung für Committer: Stellen Sie Problembehebungen + aus -CURRENT auch in -STABLE ein, wenn es nötig ist.</li> + + <li>Passen Sie den Quelltext nicht grundlos an Ihren + Stil oder ihre Vorlieben an – das erschwert + die Begutachtung der Änderung nur unnötig. + Führen Sie nur dann Stiländerungen durch, + wenn es dafür berechtigte Grü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 – die Funktion wird oft falsch verwendet.</li> + + <li>Wenn Sie feste Puffergrößen verwenden, + benutzen Sie die Funktion sizeof(). Sie verhindert Fehler, + wenn die Puffergröße verä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öße eines Zeigers + mit der Größe der Daten, auf die der Zeiger zeigt!</li> + + <li>Wenn Sie <tt>char foo[###]</tt> sehen, prüfen Sie + jeden Gebrauch der Variablen foo und stellen Sie sicher, + dass kein Pufferüberlauf möglich ist. Wenn Sie + einen Pufferüberlauf nicht verhindern können + (das gibt es wirklich), fordern Sie den Speicher für + den Puffer wenigstens mit malloc() an. Dies verhindert + mögliche Zugriffe auf den Stack.</li> + + <li>Schließen Sie Dateideskriptoren so schnell wie + möglich – die stdio-Puffer werden so wahrscheinlich + schneller entleert. In Bibliotheksfunktionen mü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üft automatisch C-Quelltexte und zeigt + Problemstellen auf. Das Werkzeug ist für eine erste + Prüfung gut geeignet, allerdings sollten Sie sich + nicht nur auf den Port its4 verlassen. Ein vollständiger + Audit sollte von einem Menschen durchgeführt werden, + der den ganzen Quelltext untersucht.</p> + + <p>Zusätzliche Ressourcen und mehr ü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önnen + Sie mit den nachstehenden Schritten sichern:</p> + + <ul> + <li>Deaktivieren Sie potentiell gefährliche Programme:<br> + + Viele Programme laufen unter besonders berechtigten + Benutzern (SUID), um auf bestimmte Ressourcen zuzugreifen. + UUCP oder PPP zum Beispiel benötigen einen + speziellen Netzwerk-Port, sendmail benötigt + Zugriff auf das Spool-Verzeichnis und einen speziellen + Netzwerk-Port. Wenn Sie UUCP nicht + verwenden, können Sie es auch deaktivieren. + Natürlich müssen Sie Ihr System gut kennen, + um entscheiden zu können, welche Programme Sie + nicht benötigen und welche Programme Sie vielleicht + später einmal benötigen werden.<br> + + Einige Werkzeuge, wie swapinfo, die Sie vielleicht nicht + besonders nützlich finden, stellen ebenfalls ein + Sicherheitsrisiko dar. Wenn Sie mit <tt>chmod ug-s filename</tt> + das SUID-Bit des Programms entfernen, können Sie + swapinfo immer noch als root ausführen. Es ist + allerdings keine gute Idee so viele SUID-Bits zu + entfernen, dass Sie nur noch als root arbeiten können.<br> + + Neben Programmen sollten Sie auch Dienste deaktivieren, + die Sie nicht benö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ßen Sie Sicherheitslö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 + über Sicherheitslöcher und deren Behebung. Sobald + eine Lösung für ein Sicherheitsproblem existiert, + wenden Sie die Lösung an.</li> + + <li>Datensicherungen – 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ädigte oder veränderte + Daten enthalten.</li> + + <li>Installieren Sie Software, die den Status des Systems + überwacht:<br> + + Programme wie die TCP-Wrapper oder Tripwire (beide + sind als Paket oder aus den Ports installierbar) helfen, + die Vorgänge auf einem System zu überwachen. + Mit diesen Werkzeugen werden Sie Einbrüche leichter + erkennen. Lesen Sie auch die tä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örter verwenden. Klären Sie + die Benutzer darüber auf, dass sie für die System- + und Netzwerksicherheit mitverantwortlich sind.</li> + </ul> + + <p>Das FreeBSD Security How-To enthält weiterführende + Tipps, mit denen Sie die Sicherheit Ihres Systems verbessern + kö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ßnahmen bei einem Sicherheitsvorfall</h2> + + <ul> + <li><b>Bestimmen Sie das Ausmaß 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ändert hat</b><br> + + Welche Software wurde verändert? Wurde ein neuer + Kernel installiert? Wurden Systemprogramme (wie telnetd + oder login) verändert? Wenn ein Angreifer das + Betriebssystem verändert hat, sollten Sie das + System von einem sicheren Medium neu installieren.</li> + + <li><b>Finden Sie heraus wie der Einbruch verü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öglich? + War der Einbruch durch ein bisher unbekanntes Sicherheitsloch + mö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ß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ä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ält eine groß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ält alles was Sie ü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> |