diff --git a/de/Makefile b/de/Makefile
index 279d472950..cecfef28d3 100644
--- a/de/Makefile
+++ b/de/Makefile
@@ -1,87 +1,88 @@
# 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)
.include "Makefile.conf"
.endif
.if exists(../Makefile.inc)
.include "../Makefile.inc"
.endif
# These are turned into validated, normalized HTML files.
DOCS= applications.sgml
DOCS+= availability.sgml
DOCS+= features.sgml
DOCS+= internet.sgml
DOCS+= mailto.sgml
DOCS+= relnotes.sgml
DOCS+= where.sgml
# These will be directly installed.
#DATA= favicon.ico
#DATA+= robots.txt
#DATA+= freebsd.css
#DATA+= vendors.html
# Subdirectories
# SGML
SUBDIR= news
SUBDIR+= FAQ
SUBDIR+= handbook
SUBDIR+= platforms
SUBDIR+= releases
+SUBDIR+= security
.if !defined(WEB_ONLY) || empty(WEB_ONLY)
#SUBDIR+= ports
SUBDIR+= doc
.endif
.if defined(BUILD_RELNOTES)
SUBDIR+= relnotes
.endif
# These *must* be listed after the "doc" subdir, as they create symlinks
# in to it.
#.if !defined(WEB_ONLY) || empty(WEB_ONLY)
#SUBDIR+= tutorials
#.endif
# Non-SGML
SUBDIR+= gifs
COOKIE= FAQ handbook
WEBDIR?= data/de
# index.html is special, and generated from index.xsl and news/news.xml
DATA+= index.html
CLEANFILES+= index.html
WEBCHECK?= ${PREFIX}/bin/webcheck
WEBCHECKOPTS?= -ab ${WEBCHECKFLAGS}
WEBCHECKDIR?= /webcheck
WEBCHECKINSTALLDIR?= ${DESTDIR}${WEBCHECKDIR}
WEBCHECKURL?= http://www.FreeBSD.org/
webcheck:
@[ -d ${WEBCHECKINSTALLDIR} ] || ${MKDIR} ${WEBCHECKINSTALLDIR}
${WEBCHECK} ${WEBCHECKOPTS} -o ${WEBCHECKINSTALLDIR} ${WEBCHECKURL}
.include "${WEB_PREFIX}/share/mk/web.site.mk"
index.html: index.xsl ${XML_INCLUDES}\
${XML_NEWS_INCLUDES} ${XML_NEWS_NEWS} ${XML_NEWS_PRESS}\
${XML_MIRRORS} ${XML_ADVISORIES}
${XSLTPROC} ${XSLTPROCOPTS} \
-o $@ \
--param mirrors.xml "'${XML_MIRRORS}'" \
--param advisories.xml "'${XML_ADVISORIES}'" \
--param news.press.xml "'${XML_NEWS_PRESS}'" \
--param news.project.xml "'${XML_NEWS_NEWS}'" \
${.CURDIR}/index.xsl ${XML_NEWS_NEWS}
.if !defined(NO_TIDY)
-${TIDY} ${TIDYOPTS} ${.TARGET}
.endif
diff --git a/de/security/Makefile b/de/security/Makefile
index 9e3f8d5d85..49c76d175e 100644
--- a/de/security/Makefile
+++ b/de/security/Makefile
@@ -1,16 +1,24 @@
# $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"
.endif
.if exists(../Makefile.inc)
.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 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ veröffentlicht.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
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 @@
+
+
+
+
+
+ %includes;
+
+]>
+
+
+ &header;
+
+ Einführung
+
+ 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.
+
+ 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.
+
+ Inhalt
+
+
+
+ Der FreeBSD Security-Officer und das Security-Officer-Team
+
+ Um zügig sicherheitsrelevante Informationen mit anderen
+ auszutauschen, besitzt das FreeBSD Project einen zentralen
+ Ansprechpartner: Den FreeBSD Security-Officer.
+
+ Wenn Sie ein Sicherheitsproblem an das FreeBSD Project
+ melden wollen, schreiben Sie eine
+ E-Mail
+ an den Security-Officer. Beschreiben Sie in der
+ E-Mail die entdeckte Sicherheitslücke.
+
+ 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 <security-officer@FreeBSD.org>
+ an die folgenden Personen geliefert:
+
+
+
+ Der Security-Officer wird vom
+ FreeBSD-Security-Team
+ <security-team@FreeBSD.org> unterstützt.
+ Das Team besteht aus einer Gruppe von Committern, die vom
+ Security-Officer ausgewählt werden.
+
+ Verschlüsseln Sie E-Mails mit dem PGP-Schlüssel
+ des Security-Officers, wenn dies erforderlich
+ ist.
+
+
+ Umgang mit Informationen
+
+ 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, 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.
+
+ 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,
+
+ Eingesendete Sicherheitsprobleme können mit PGP geschützt
+ werden. Auf Wunsch werden die Antworten ebenfalls mit PGP
+ geschützt.
+
+
+ FreeBSD Sicherheits-Hinweise
+
+ 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.
+
+
+ -
+
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 RELENG_4.
+ Die daraus gebauten FreeBSD-Versionen werden beispielsweise
+ FreeBSD 4.6-STABLE genannt.
+
+
+ -
+
Jedes FreeBSD-Release besitzt einen Sicherheits-Zweig.
+ Die Tags der Sicherheits-Zweige haben Namen wie
+ RELENG_4_6. Die daraus gebauten FreeBSD-Versionen
+ tragen Namen wie FreeBSD 4.6-RELEASE-p7.
+
+
+
+ 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 Wartungsende
+ 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.
+
+
+
+ | Zweig |
+ Release |
+ Wartungsende |
+
+
+
+ | RELENG_4 |
+ - |
+ 31. Oktober 2004 |
+
+
+
+ | RELENG_4_8 |
+ 4.8-RELEASE |
+ 31. März 2004 |
+
+
+
+ | RELENG_4_9 |
+ 4.9-RELEASE |
+ 31. Oktober 2004 |
+
+
+
+ | RELENG_5_1 |
+ 5.1-RELEASE |
+ 28. Februar 2004 |
+
+
+
+ Ältere Releases werden nicht mehr gepflegt. Benutzer
+ solcher Releases sollten dringend auf eine oben aufgeführte
+ unterstützte Release aktualisieren.
+
+ Wie alle Entwicklungen werden Fehlerbehebungen zuerst
+ in den FreeBSD-CURRENT-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.
+
+ Ein paar Zahlen zu den im Jahr 2002 veröffentlichten Hinweisen:
+
+
+ - 44 Hinweise von unterschiedlicher Schwere betrafen das
+ Basissystem.
+ - 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.
+ - Es wurden 6 Mitteilungen herausgegeben, die auf
+ 95 Probleme mit Software Dritter aus der Ports-Collection
+ hinwiesen.
+
+
+ Die Hinweise werden an die folgenden FreeBSD-Mailinglisten
+ versendet:
+
+
+ - FreeBSD-security-notifications@FreeBSD.org
+ - FreeBSD-security@FreeBSD.org
+ - FreeBSD-announce@FreeBSD.org
+
+
+ Die Hinweise werden immer mit dem
+ PGP-Schlüssel
+ des FreeBSD-Security-Officers signiert. Die Hinweise werden
+ zusammen mit den Fehlerbehebungen in unserem
+ FTP
+ CERT-Repository abgelegt. Zurzeit sind folgende Hinweise
+ verfügbar (die Liste kann ein paar Tage alt sein,
+ die neusten Hinweise finden Sie auf unserem
+ FTP-Server):
+
+ &advisories.html.inc;
+
+
+ Mailinglisten zum Thema Sicherheit
+
+ Wenn Sie ein FreeBSD-System administrieren oder benutzen,
+ sollten Sie eine oder mehrere der nachstehenden Listen
+ abonnieren:
+
+
+
+
+ Richtlinien zum sicheren Programmieren
+
+
+ - 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:
+
+
+ - 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!
+
+
- Wenn Sie Benutzereingaben auf unerwünschte Zeichen
+ prüfen, suchen Sie nicht nach diesen
+ unerwünschten Zeichen. Prüfen Sie stattdessen,
+ dass die Eingabe nur aus erlaubten Zeichen besteht.
+ Die allgemeine Regel lautet: Verbieten Sie alles, was
+ nicht ausdrücklich erlaubt ist.
+
+ - 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.
+
+ - 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!
+
+ - Jedes Mal, wenn Sie die Funktionen open() oder stat()
+ benutzen, fragen Sie sich: "Was passiert, wenn die
+ Funktionen auf einen symbolischen Link angewendet
+ werden?"
+
+ - Benutzen Sie mkstemp() anstelle von Funktionen wie
+ mktemp() oder tempnam(). Achten Sie auf Race-Conditions
+ insbesondere im Verzeichnis /tmp. Es gibt nur wenige
+ atomare Operationen in Verzeichnissen:
+
+
+ - Anlegen eines Verzeichnisses. Diese Operation
+ gelingt oder schlägt fehl.
+ - Öffnen einer Datei mit O_CREAT | O_EXCL.
+
+
+ - Legen Sie temporäre Dateien immer mit mkstemp(),
+ an, da mit dieser Funktion Race-Conditions
+ und falsche Zugriffsrechte verhindert werden.
+
+ - 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 nicht vertraut werden.
+
+ - 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 jeder Pfadangabe des Benutzers,
+ wenn ein Programm unter root-Rechten (SUID) läuft.
+
+ - Achten Sie auf Sicherheitslöcher, wenn Daten
+ gespeichert werden. Um unberechtigte Zugriffe zu verhindern,
+ werden temporäre Dateien mit den Zugriffsrechten
+ 600 angelegt.
+
+ - 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.
+
+ - 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.
+
+
+
+ - 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.
+
+ - 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.
+
+ - Wenn Sie Quelltext auf Sicherheitsprobleme untersuchen,
+ beachten Sie bitte die nachstehenden Hinweise:
+
+
+ - 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.
+
+ - 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.
+
+ - 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.
+
+ - 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.
+
+ - Anmerkung für Committer: Stellen Sie Problembehebungen
+ aus -CURRENT auch in -STABLE ein, wenn es nötig ist.
+
+ - 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.
+
+
+
+ - Achten Sie auf Programme, die komplizierte Funktionen zur
+ Signalbehandlung besitzen. Viele Funktionen verschiedener
+ Bibliotheken sind nicht reentrant
+
+
- Schauen sie sich den Gebrauch der Funktion realloc()
+ genau an – die Funktion wird oft falsch verwendet.
+
+ - 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:
+
+
+ char buf[1024];
+ struct foo { ... };
+ ...
+SCHLECHT:
+ xxx(buf, 1024)
+ xxx(yyy, sizeof(struct foo))
+GUT:
+ xxx(buf, sizeof(buf))
+ xxx(yyy, sizeof(yyy))
+
+
+ Verwechseln sie nicht die Größe eines Zeigers
+ mit der Größe der Daten, auf die der Zeiger zeigt!
+
+ - Wenn Sie char foo[###] 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.
+
+ - Schließen Sie Dateideskriptoren so schnell wie
+ möglich – die stdio-Puffer werden so wahrscheinlich
+ schneller entleert. In Bibliotheksfunktionen müssen
+ Dateideskriptoren immer close-on-exec (sie
+ werden nach fork()/exec() automatisch geschlossen) angelegt
+ werden.
+
+
+ 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.
+
+ Zusätzliche Ressourcen und mehr über sicheres
+ Programmieren finden Sie auf der Webseite
+ How to Write Secure Code.
+
+
+ FreeBSD sichern
+
+ FreeBSD, oder jedes andere &unix; System, können
+ Sie mit den nachstehenden Schritten sichern:
+
+
+ - Deaktivieren Sie potentiell gefährliche Programme:
+
+ 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.
+
+ Einige Werkzeuge, wie swapinfo, die Sie vielleicht nicht
+ besonders nützlich finden, stellen ebenfalls ein
+ Sicherheitsrisiko dar. Wenn Sie mit chmod ug-s filename
+ 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.
+
+ Neben Programmen sollten Sie auch Dienste deaktivieren,
+ die Sie nicht benötigen. In den Dateien
+ /etc/inetd.conf und /etc/rc.conf sollten
+ Sie alle Dienste deaktivieren, die Sie nicht benutzen.
+
+ - Schließen Sie Sicherheitslöcher (oder wie Sie
+ den Crackern einen Schritt voraus sind):
+
+ Abonnieren Sie die FreeBSD
+ Sicherheits-Mailinglisten. 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.
+
+ - Datensicherungen – Reparieren Sie Ihr System nach
+ einem Sicherheitsvorfall:
+
+ 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.
+
+ - Installieren Sie Software, die den Status des Systems
+ überwacht:
+
+ 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.
+
+ - Schulen Sie die Benutzer des Systems:
+
+ 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.
+
+
+ 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
+ http://www.FreeBSD.org/~jkb/howto.html.
+
+ Sicherheit ist ein kontinuierlicher Prozess. Verfolgen
+ Sie die Entwicklungen im Sicherheits-Umfeld.
+
+
+ Maßnahmen bei einem Sicherheitsvorfall
+
+
+ - Bestimmen Sie das Ausmaß des Vorfalls
+
+ Welche Rechte hat der Angreifer erlangt? Hat der
+ Angreifer root-Zugriff bekommen? Oder hat der
+ Angreifer lediglich normale Benutzerrechte erhalten?
+
+ - Bestimmen Sie, ob sich etwas am Systemzustand (Kernel
+ oder Userland) verändert hat
+
+ 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.
+
+ - Finden Sie heraus wie der Einbruch verübt
+ wurde
+
+ 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
+ FreeBSD
+ Security-Officer.
+
+ - Schließen Sie das Sicherheitsloch
+
+ Installieren Sie neue Software oder wenden Sie Fehlerbehebungen
+ auf alte Software an. Sperren Sie missbrauchte
+ Benutzerkonten.
+
+ - Weitere Ressourcen
+
+ Das CERT bietet
+ genaue
+ Anleitungen zum Umgang mit Sicherheitsvorfällen.
+
+
+ Weitere Informationsquellen
+
+
+
+ &footer
+
+