Sicherheit ist die Verantwortung eines jeden Einzelnen. Ein schwacher Einstiegspunkt in einem System kann einem Eindringling Zugriff auf wichtige Informationen verschaffen, was sich verheerend auf das gesamte Netzwerk auswirken kann. Eines der Grundprinzipien der Informationssicherheit sind die Vertraulichkeit, Integrität und Verfügbarkeit von Informationssystemen.
Diese Grundprinzipien sind ein fundamentales Konzept der Computer-Sicherheit, da Kunden und Benutzer erwarten, dass ihre Daten geschützt sind. Zum Beispiel erwartet ein Kunde, dass seine Kreditkarteninformationen sicher gespeichert werden (Vertraulichkeit), dass seine Aufträge nicht hinter den Kulissen geändert werden (Integrität) und dass er zu jeder Zeit Zugang zu seinen Informationen hat (Verfügbarkeit).
Um diese Grundprinzipien zu implementieren, wenden Sicherheitsexperten das sogenannte Defense-in-Depth-Konzept an. Die Idee dahinter ist, mehrere Sicherheitsschichten zu addieren, so dass nicht die gesamte Systemsicherheit gefährdet ist, wenn eine einzelne Sicherheitsschicht kompromittiert wird. Beispielsweise ist es nicht ausreichend, ein Netzwerk oder ein System nur mit einer Firewall zu sichern. Der Systemadministrator muss auch Benutzerkonten überwachen, die Integrität von Binärdateien prüfen und sicherstellen, dass keine bösartigen Programme installiert sind. Um eine effektive Sicherheitsstrategie zu implementieren, muss man Bedrohungen verstehen und wissen, wie man sich dagegen verteidigen kann.
Was ist eine Bedrohung, wenn es um Computer-Sicherheit geht? Bedrohungen beschränken sich nicht nur auf entfernte Angreifer, die sich unerlaubten Zugriff auf ein System verschaffen wollen. Zu den Bedrohungen zählen auch Mitarbeiter, bösartige Software, nicht autorisierte Netzwerkgeräte, Naturkatastrophen, Sicherheitslücken und sogar konkurrierende Unternehmen.
Der Zugriff auf Netzwerke und Systeme erfolgt ohne Erlaubnis, manchmal durch Zufall, oder von entfernten Angreifern, und in einigen Fällen durch Industriespionage oder ehemalige Mitarbeiter. Als Anwender müssen Sie vorbereitet sein und auch zugeben, wenn ein Fehler zu einer Sicherheitsverletzung geführt hat. Melden Sie Probleme umgehend dem verantwortlichen Sicherheitspersonal. Als Administrator ist es wichtig, Bedrohungen zu kennen und darauf vorbereitet zu sein, mögliche Schäden zu mildern.
Wenn Sicherheit auf Systeme angewendet wird, empfiehlt es sich mit der Sicherung der Benutzerkonten zu beginnen und dann die Netzwerkschicht zu sichern. Dabei ist zu beachten, dass die Sicherheitsrichtlinien des Systems und des Unternehmens eingehalten werden. Viele Unternehmen haben bereits eine Sicherheitsrichtlinie, welche die Konfiguration von technischen Geräten abdeckt. Die Richtlinie sollte die Konfiguration von Arbeitsplatzrechnern, Desktops, mobilen Geräten, Mobiltelefonen, Produktions- und Entwicklungsservern umfassen. In einigen Fällen ist bereits eine Standardvorgehensweise vorhanden. Fragen Sie im Zweifelsfall das Sicherheitspersonal.
Der übrige Teil dieser Einführung beschreibt, wie einige grundlegende Sicherheitskonfigurationen auf einem FreeBSD-System durchgeführt werden. Der Rest des Kapitels zeigt einige spezifische Werkzeuge, die verwendet werden können, um eine Sicherheitsrichtlinie auf einem FreeBSD-System zu implementieren.
Ein guter Ausgangspunkt für die Absicherung des Systems
ist die Prüfung der Benutzerkonten. Stellen Sie sicher, dass
root
ein starkes
Passwort besitzt und dass dieses Passwort nicht weitergegeben
wird. Deaktivieren Sie alle Konten, die keinen Zugang zum
System benötigen.
Es existieren zwei Methoden, um die Anmeldung über ein
Benutzerkonto zu verweigern. Die erste Methode ist, das
Konto zu sperren. Dieses Beispiel sperrt das Benutzerkonto
toor
:
#
pw lock
toor
Bei der zweiten Methode wird der Anmeldevorgang
verhindert, indem die Shell auf
/usr/sbin/nologin
gesetzt wird. Nur der
Superuser kann die Shell für andere Benutzer ändern:
#
chsh -s /usr/sbin/nologin
toor
Die Shell /usr/sbin/nologin
verhindert, dass dem Benutzer bei der Anmeldung am System eine
Shell zugeordnet wird.
In manchen Fällen wird die Systemadministration auf
mehrere Benutzer aufgeteilt. FreeBSD bietet zwei Methoden, um
solche Situationen zu handhaben. Bei der ersten und nicht
empfohlenen Methode wird ein gemeinsames root Passwort der
Mitglieder der Gruppe wheel
verwendet. Hier gibt
der Benutzer su
und das Passwort für
wheel
ein, wenn er
die Rechte des Superusers benötigt. Der Benutzer sollte dann
nach der Beendigung der administrativen Aufgaben
exit
eingeben. Um einen Benutzer zu dieser
Gruppe hinzuzufügen, bearbeiten Sie
/etc/group
und fügen Sie den Benutzer an
das Ende des Eintrags wheel
hinzu. Die
Benutzer müssen durch Komma und ohne Leerzeichen getrennt
werden.
Die zweite und empfohlene Methode ein Benutzerkonto zu teilen wird über den Port oder das Paket security/sudo realisiert. Dieses Programm bietet zusätzliche Prüfungen, bessere Benutzerkontrolle und es kann auch konfiguriert werden, einzelnen Benutzern Zugriff auf bestimme, privilegierte Befehle zu gestatten.
Benutzen Sie nach der Installation
visudo
, um
/usr/local/etc/sudoers
zu bearbeiten.
Dieses Beispiel erstellt eine neue Gruppe webadmin
und fügt das
Benutzerkonto trhodes
dieser Gruppe hinzu.
Anschließend wird die Gruppe so konfiguriert, dass es
Gruppenmitgliedern gestattet wird apache24
neu zu starten:
#
pw groupadd webadmin -M trhodes -g 6000
#
visudo
%webadmin ALL=(ALL) /usr/sbin/service apache24 *
Passwörter sind ein notwendiges Übel. Wenn sie verwendet
werden müssen, sollten sie sehr komplex sein und dazu sollte
eine leistungsfähige Hash-Funktion gewählt werden, um die
Version des Passworts zu verschlüsseln, die in der
Passwortdatenbank gespeichert wird. FreeBSD unterstützt die
Hash-Funktionen DES,
MD5, SHA256,
SHA512, sowie
Blowfish Hash-Funktionen in seiner
crypt()
-Bibliothek. Das in der
Voreinstellung verwendete SHA512 sollte
nicht durch eine weniger sichere Hash-Funktion getauscht
werden. Es kann jedoch durch den besseren
Blowfish-Algorithmus ersetzt werden.
Blowfish ist nicht Bestandteil von AES und ist nicht kompatibel mit allen Federal Information Processing Standards (FIPS). Die Verwendung wird in einigen Umgebungen vielleicht nicht gestattet.
Um zu bestimmen, welche Hash-Funktion das Passwort eines
Benutzers verschlüsselt, kann der Superuser den Hash für den
Benutzer in der Passwortdatenbank von FreeBSD nachsehen. Jeder
Hash beginnt mit einem Zeichen, mit dem die verwendete
Hash-Funktion identifiziert werden kann. Bei
DES gibt es allerdings kein führendes
Zeichen. MD5 benutzt das Zeichen
$
. SHA256 und
SHA512 verwenden das Zeichen
$6$
. Blowfish benutzt das Zeichen
$2a$
. In diesem Beispiel wird das Passwort
von dru
mit dem
Hash-Algorithmus SHA512 verschlüsselt, da
der Hash mit $6$
beginnt. Beachten Sie,
dass der verschlüsselte Hash und nicht das Passwort selbst, in
der Passwortdatenbank gespeichert wird:
#
grep dru /etc/master.passwd
dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh
Der Hash-Mechanismus wird in der Login-Klasse des
Benutzers festgelegt. In diesem Beispiel wird die
voreingestellte Login-Klasse für den Benutzer verwendet. Der
Hash-Algorithmus wird mit dieser Zeile in
/etc/login.conf
gesetzt:
:passwd_format=sha512:\
Um den Algorithmus auf Blowfish zu ändern, passen Sie die Zeile wie folgt an:
:passwd_format=blf:\
Führen Sie anschließend
cap_mkdb /etc/login.conf
aus, wie in Abschnitt 13.13.1, „Login-Klassen konfigurieren“ beschrieben. Beachten Sie, dass
vorhandene Passwort-Hashes durch diese Änderung nicht
beeinträchtigt werden. Das bedeutet, dass alle Passwörter neu
gehasht werden sollten, indem die Benutzer mit
passwd
ihr Passwort ändern.
Für die Anmeldung auf entfernten Rechnern sollte eine Zwei-Faktor-Authentifizierung verwendet werden. Ein Beispiel für eine Zwei-Faktor-Authentifizierung ist „etwas, was Sie besitzen“ (bspw. einen Schlüssel) und „etwas, was Sie wissen“ (bspw. das Passwort für diesen Schlüssel). Da OpenSSH Teil des FreeBSD-Basissystems ist, sollten alle Anmeldungen über das Netzwerk über eine verschlüsselte Verbindung mit einer schlüsselbasierten Authentifizierung stattfinden. Passwörter sollten hier nicht verwendet werden. Weitere Informationen finden Sie in Abschnitt 13.8, „OpenSSH“. Kerberos-Benutzer müssen eventuell zusätzliche Änderungen vornehmen, um OpenSSH in Ihrem Netzwerk zu implementieren. Diese Änderungen sind in Abschnitt 13.5, „Kerberos“ beschrieben.
Die Durchsetzung einer starken Passwort-Richtlinie für lokale Benutzerkonten ist ein wesentlicher Aspekt der Systemsicherheit. In FreeBSD kann die Länge, Stärke und Komplexität des Passworts mit den Pluggable Authentication Modules (PAM) implementiert werden.
In diesem Abschnitt wird gezeigt, wie Sie die minimale und
maximale Passwortlänge und die Durchsetzung von gemischten
Zeichen mit dem Modul pam_passwdqc.so
konfigurieren. Dieses Modul wird aufgerufen, wenn ein
Benutzer sein Passwort ändert.
Um dieses Modul zu konfigurieren, müssen Sie als Superuser
die Zeile mit pam_passwdqc.so
in
/etc/pam.d/passwd
auskommentieren.
Anschließend bearbeiten Sie die Zeile, so dass sie den
vorliegenden Passwort-Richtlinien entspricht:
password requisite pam_passwdqc.so min=disabled,disabled,disabled,12,10 similar=deny retry=3
enforce=users
Dieses Beispiel legt gleich mehrere Anforderungen für neue
Passwörter fest. Die Einstellung min
kontrolliert die Passwortlänge. Es verfügt über fünf Werte,
weil dieses Modul fünf verschiedene Arten von Passwörtern
definiert, basierend auf der Komplexität. Die Komplexität
wird durch die Art von Zeichen definiert, die in einem
Passwort vorhanden sind, wie zum Beispiel Buchstaben, Zahlen
und Sonderzeichen. Die verschiedenen Arten von Passwörtern
werden in pam_passwdqc(8) beschrieben. In diesem
Beispiel sind die ersten drei Arten von Passwörtern
deaktiviert, was bedeutet, dass Passwörter, die dieser
Komplexitätsstufe entsprechen, nicht akzeptiert werden,
unabhängig von der Länge des Passworts. Die
12
legt eine Richtlinie von mindestens
zwölf Zeichen fest, wenn das Passwort auch drei Arten von
Komplexität aufweist. Die 10
legt eine
Richtlinie fest, die auch Passwörter mit mindestens zehn
Zeichen zulassen, wenn das Passwort Zeichen mit vier Arten
von Komplexität aufweist.
Die Einstellung similar
verbietet
Passwörter, die dem vorherigen Passwort des Benutzers ähnlich
sind. Die Einstellung retry
bietet dem
Benutzer drei Möglichkeiten, ein neues Passwort
einzugeben.
Sobald diese Datei gespeichert wird, sehen Benutzer bei der Änderung ihres Passworts die folgende Meldung:
%
passwd
Changing local password for trhodes Old Password: You can now choose the new password. A valid password should be a mix of upper and lower case letters, digits and other characters. You can use a 12 character long password with characters from at least 3 of these 4 classes, or a 10 character long password containing characters from all the classes. Characters that form a common pattern are discarded by the check. Alternatively, if noone else can see your terminal now, you can pick this as your password: "trait-useful&knob". Enter new password:
Wenn ein Passwort nicht den Richtlinien entspricht, wird es mit einer Warnung abgelehnt und der Benutzer bekommt die Möglichkeit, es erneut zu versuchen, bis die Anzahl an Wiederholungen erreicht ist.
Die meisten Passwort-Richtlinien erzwingen, dass
Passwörter nach einer bestimmten Anzahl von Tagen ablaufen.
Um dieses Limit in FreeBSD zu konfigurieren, setzen Sie es für
die Login-Klasse des Benutzers in
/etc/login.conf
. Die voreingestellte
Login-Klasse enthält dazu ein Beispiel:
# :passwordtime=90d:\
Um für diese Login-Klasse das Passwort nach 90 Tagen
ablaufen zu lassen, entfernen Sie das Kommentarzeichen
(#
), speichern Sie die Änderungen und
führen Sie cap_mkdb /etc/login.conf
aus.
Um das Passwort für einzelne Benutzer ablaufen zu lassen,
geben Sie pw
ein Ablaufdatum oder die
Anzahl von Tagen, zusammen mit dem Benutzer an:
#
pw usermod -p
30-apr-2015
-ntrhodes
Wie zu sehen ist, wird das Ablaufdatum in der Form von Tag, Monat und Jahr angegeben. Weitere Informationen finden Sie in pw(8).
Ein Rootkit ist eine nicht autorisierte Software die versucht, Root-Zugriff auf ein System zu erlangen. Einmal installiert, wird diese bösartige Software normalerweise eine Hintertür für den Angreifer installieren. Realistisch betrachtet sollte ein durch ein Rootkit kompromittiertes System nach der Untersuchung von Grund auf neu installiert werden. Es besteht jedoch die enorme Gefahr, dass sogar das Sicherheitspersonal oder Systemingenieure etwas übersehen, was ein Angreifer dort platziert hat.
Wird ein Rootkit erkannt, ist dies bereits ein Zeichen dafür, dass das System an einem bestimmten Zeitpunkt kompromittiert wurde. Meist neigen diese Art von Anwendungen dazu, sehr gut versteckt zu sein. Dieser Abschnitt zeigt das Werkzeug security/rkhunter, mit dem Rootkits erkannt werden können.
Nach der Installation dieses Ports oder Pakets kann das System mit dem folgenden Kommando überprüft werden. Das Programm generiert eine ganze Menge Informationen und Sie werden diverse Male ENTER drücken müssen:
#
rkhunter -c
Nachdem der Prozess abgeschlossen ist, wird eine Statusmeldung auf dem Bildschirm ausgegeben. Die Meldung enthält die Anzahl der überprüften Dateien, verdächtige Dateien, mögliche Rootkits und weitere Informationen. Während der Überprüfung erscheinen allgemeine Sicherheitswarnungen, zum Beispiel über versteckte Dateien, die Auswahl von OpenSSH-Protokollen und bekannte, anfällige Versionen installierter Anwendungen. Diese können nun direkt, oder nach detaillierter Analyse untersucht werden.
Jeder Administrator sollte wissen, was auf den Systemen
läuft, für die er verantwortlich ist. Werkzeuge von
Drittanbietern, wie rkhunter oder
sysutils/lsof, sowie native Befehle wie
netstat
oder ps
, können
eine große Menge an Informationen über das System anzeigen.
Machen Sie sich Notizen darüber, was „normal“
ist, und fragen Sie nach, wenn Ihnen etwas suspekt erscheint.
Eine Beeinträchtigung zu verhindern ist ideal, aber die
Erkennung einer Beeinträchtigung ist ein Muss.
Die Überprüfung von System- und Binärdateien ist wichtig, da sie Systemadministratoren Informationen über Systemänderungen zur Verfügung stellt. Eine Software, die das System auf Änderungen überwacht wird Intrustion Detection System (IDS) genannt.
FreeBSD bietet native Unterstützung für ein einfaches IDS-System. Obwohl die täglichen Sicherheits-E-Mails den Administrator über Änderungen in Kenntnis setzen, werden diese Informationen lokal gespeichert und es besteht die Möglichkeit, dass ein Angreifer diese Informationen manipulieren kann, um Änderungen am System zu verbergen. Daher ist es empfehlenswert, einen eigenen Satz an Signaturen zu erstellen und diese dann in einem schreibgeschützten Verzeichnis, oder vorzugsweise auf einem USB-Stick oder auf einem entfernten Server zu speichern.
Das im Basissystem enthaltene Werkzeug
mtree kann verwendet werden, um
eine Spezifikation des Inhalts eines Verzeichnisses zu
erzeugen. Hierbei wird ein Startwert
(Seed) oder eine numerische
Konstante benutzt, um die Spezifikation zu erstellen und um
sicherzustellen, dass sich die Spezifikation nicht geändert
hat. Dadurch kann festgestellt werden, ob eine Datei oder
eine Binärdatei verändert wurde. Da ein Angreifer den
Seed nicht kennt, ist es ihm fast unmöglich die
Prüfsummen von Dateien zu manipulieren. Das folgende Beispiel
generiert einen Satz mit SHA256-Prüfsummen
für jede Binärdatei unterhalb von /bin
und speichert diese Werte in einer versteckten Datei im
Heimatverzeichnis von root
unter dem Namen
/root/.bin_chksum_mtree
:
#
mtree -s
3483151339707503
-c -K cksum,sha256digest -p/bin
>/root/.bin_chksum_mtree
#
mtree: /bin checksum: 3427012225
3483151339707503
stellt den
Seed dar. Diesen Wert sollten Sie sich merken, aber
nicht mit anderen Personen teilen.
Die Ausgabe von
/root/.bin_chksum_mtree
sollte ähnlich
der folgenden sein:
# user: root # machine: dreadnaught # tree: /bin # date: Mon Feb 3 10:19:53 2014 # . /set type=file uid=0 gid=0 mode=0555 nlink=1 flags=none . type=dir mode=0755 nlink=2 size=1024 \ time=1380277977.000000000 \133 nlink=2 size=1170 time=1380277977.000000000 \ cksum=484492447 \ sha256digest=6207490fbdb5ed1904441fbfa941279055c3e24d3a4049aeb45094596400662a cat size=12096 time=1380277975.000000000 cksum=3909216944 \ sha256digest=65ea347b9418760b247ab10244f47a7ca2a569c9836d77f074e7a306900c1e69 chflags size=8168 time=1380277975.000000000 cksum=3949425175 \ sha256digest=c99eb6fc1c92cac335c08be004a0a5b4c24a0c0ef3712017b12c89a978b2dac3 chio size=18520 time=1380277975.000000000 cksum=2208263309 \ sha256digest=ddf7c8cb92a58750a675328345560d8cc7fe14fb3ccd3690c34954cbe69fc964 chmod size=8640 time=1380277975.000000000 cksum=2214429708 \ sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7
Der Report enthält den Rechnernamen, das Datum und die Uhrzeit der Spezifikation, sowie den Namen des Benutzers, der die Spezifikation erstellt hat. Für jede Binärdatei im Verzeichnis gibt es eine Prüfsumme, Größe, Uhrzeit und einen SHA256-Hashwert.
Um sicherzustellen, dass die binären Signaturen nicht verändert wurden, vergleichen Sie den Inhalt des aktuellen Verzeichnisses mit der zuvor erstellen Spezifikation. Speichern Sie die Ergebnisse in einer Datei. Dieses Kommando benötigt den Seed, der verwendet wurde um die ursprüngliche Spezifikation zu erstellen:
#
mtree -s
3483151339707503
-p/bin
</root/.bin_chksum_mtree
>>/root/.bin_chksum_output
#
mtree: /bin checksum: 3427012225
Dies sollte die gleiche Prüfsumme für
/bin
produzieren, wie die ursprüngliche
Spezifikation. Wenn keine Änderungen an den Binärdateien in
diesem Verzeichnis aufgetreten sind, wird die Ausgabedatei
/root/.bin_chksum_output
leer sein. Um
eine Änderung zu simulieren, ändern Sie mit
touch
das Datum von
/bin/cat
und führen Sie die Verifikation
erneut aus:
#
touch /bin/cat
#
mtree -s
3483151339707503
-p/bin
</root/.bin_chksum_mtree
>>/root/.bin_chksum_output
#
more /root/.bin_chksum_output
cat changed modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014
Es wird empfohlen, Spezifikationen für Verzeichnisse zu
erstellen, welche Binärdateien, Konfigurationsdateien und
sensible Daten enthalten. In der Regel werden Spezifikationen
für /bin
, /sbin
,
/usr/bin
, /usr/sbin
,
/usr/local/bin
,
/usr/local/sbin
,
/etc
und
/usr/local/etc
erstellt.
Mit security/aide steht ein
fortgeschrittenes IDS-System zur Verfügung,
aber in den meisten Fällen bietet mtree
die
Funktionalität, die von Administratoren benötigt wird. Es ist
jedoch sehr wichtig den Seed und die Prüfsummen in der
Ausgabe vor böswilligen Benutzern verborgen zu halten.
Weitere Informationen zu mtree
finden Sie
in mtree(8).
Unter FreeBSD können viele Systemfunktionen mit
sysctl
konfiguriert werden. Dieser
Abschnitt behandelt ein paar Sicherheitsmerkmale mit denen
Denial of Service
(DoS) verhindert werden sollen. Weitere
Informationen über die Benutzung von
sysctl
und wie Werte vorübergehend oder
auch permanent geändert werden können, finden Sie in Abschnitt 11.9, „Einstellungen mit sysctl(8)“.
Jedes Mal wenn eine Einstellung mit
sysctl
geändert wird, vergrößert sich die
Wahrscheinlichkeit eines unerwünschten Schadens, was die
Verfügbarkeit des Systems beeinflusst. Alle Änderungen
sollten überwacht und wenn möglich, vorher auf einem
Testsystem ausprobiert werden, bevor sie auf einem
Produktivsystem verwendet werden.
In der Voreinstellung startet FreeBSD in der Sicherheitsstufe
(Securelevel)
-1
. Dieser Modus wird
„unsicherer Modus“ genannt, da die
unveränderlichen Datei-Flags ausgeschaltet werden können und
dadurch von allen Geräten gelesen und geschrieben werden kann.
Solange die Einstellung nicht über sysctl
oder in den Startskripten geändert wird, verbleibt die
Sicherheitsstufe auf -1
. Die
Sicherheitsstufe kann während des Systemstarts erhöht werden.
Dazu muss in /etc/rc.conf
kern_securelevel_enable
auf
YES
und kern_securelevel
auf den gewünschten Wert gesetzt werden. Weitere
Informationen zu diesen Einstellungen und den verfügbaren
Sicherheitsstufen finden Sie in security(7) und
init(8).
Das Erhöhen der Sicherheitsstufe kann zu Problemen mit Xorg führen.
Die Einstellungen
net.inet.tcp.blackhole
und
net.inet.udp.blackhole
können benutzt
werden, um eingehende SYN-Pakete an
geschlossenen Ports zu blockieren, ohne ein
RST-Paket als Antwort zu senden.
Standardmäßig wird jedoch ein RST-Paket
gesendet, um zu zeigen, dass der Port geschlossen ist. Das
ändern dieser Voreinstellung bietet einen gewissen Schutz
gegen Portscans. Diese Portscans versuchen herauszufinden,
welche Anwendungen auf einem System ausgeführt werden. Setzen
Sie net.inet.tcp.blackhole
auf
2
und
net.inet.udp.blackhole
auf
1
. Weitere Informationen zu diesen
Einstellungen finden Sie in blackhole(4).
Die Einstellung
net.inet.icmp.drop_redirect
hilft dabei,
sogenannte Redirect-Angriffe zu verhindern. Ein
Redirect-Angriff ist eine Art von DoS, die
massenhaft ICMP-Pakete Typ 5 versendet. Da
solche Pakete nicht benötigt werden, setzen Sie
net.inet.icmp.drop_redirect
auf
1
und
net.inet.ip.redirect
auf
0
.
Source Routing zur
Erfassung und zum Zugriff auf nicht-routbare Adressen im
internen Netzwerk. Dies sollte deaktiviert werden, da
nicht-routbare Adressen in der Regel nicht absichtlich
geroutet werden. Um diese Funktion zu deaktivieren, setzen
Sie net.inet.ip.sourceroute
und
net.inet.accept_sourceroute
auf
0
.
Wenn ein Netzwerkgerät Nachrichten an alle Rechner in
einem Subnetz senden muss, wird eine
ICMP-Echo-Request Nachricht an die
Broadcast-Adresse gesendet. Allerdings gibt es keinen guten
Grund für externe Rechner, solche Nachrichten zu verschicken.
Um alle externen Broadcast-Anfragen abzulehnen, setzen Sie
net.inet.icmp.bmcastecho
auf
0
.
Einige zusätzliche Einstellungen sind in security(7) dokumentiert.
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.