[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ weiter ]
Wenn das System installiert ist, können Sie es noch weiter absichern, indem Sie einige der in diesem Kapitel beschriebenen Schritte ausführen. Natürlich hängt dies vor allem von Ihrer Einrichtung ab, aber um physischen Zugriff zu verhindern, sollten Sie Änderen Sie das BIOS (noch einmal), Abschnitt 4.3, Ein Passwort für LILO oder GRUB einstellen, Abschnitt 4.4, Entfernen des Root-Promptes aus dem Kernel, Abschnitt 4.6, Einschränkung der Anmeldemöglichkeiten an der Konsole, Abschnitt 4.7 und Einschränkung des System-Neustarts von der Konsole aus, Abschnitt 4.8 lesen.
Bevor Sie sich mit einem Netzwerk verbinden, insbesondere wenn es sich um ein öffentliches Netzwerk handelt, sollten Sie wenigstens eine Sicherheitsaktualisierung (siehe Ausführen von Sicherheitsaktualisierungen, Abschnitt 4.2) durchführen. Daneben können Sie auch einen Schnappschuss Ihres Systems machen (siehe Einen Schnappschuss des Systems erstellen, Abschnitt 4.19).
Um Informationen zu verfügbaren Sicherheitsaktualisierungen und die
Debian-Sicherheits-Ankündigungen (DSA) zu erhalten, sollten Sie Debians
Security-Announce-Mailingliste abonnieren. Lesen Sie Das Sicherheitsteam von Debian, Abschnitt
7.1 für weitere Informationen, wie das Sicherheitsteam von Debian
arbeitet. Hinweise, wie Sie die Mailinglisten von Debian abonnieren, finden
Sie unter http://lists.debian.org
.
DSAs werden mit der Signatur des Sicherheitsteams von Debian unterschrieben,
die unter http://security.debian.org
erhältlich ist.
Sie sollten in Betracht ziehen, auch die Mailingliste
debian-security
zu abonnieren. Dort finden allgemeine Diskussionen
zu Sicherheitsthemen im Betriebssystem Debian statt. Sie können auf der Liste
sowohl mit gleichgesinnten Systemadministratoren als auch mit Entwicklern von
Debian und Programmautoren in Kontakt treten. Diese werden Ihre Fragen
beantworten und Ihnen Ratschläge geben.
FIXME: Add the key here too?
Sobald neue Sicherheitslöcher in einem Paket entdeckt wurden, reparieren sie
Debians Paketbetreuer und Originalautoren im Allgemeinen innerhalb von Tagen
oder sogar Stunden. Nachdem das Loch gestopft wurde, werden neue Pakete unter
http://security.debian.org
bereit
gestellt.
Wenn Sie eine Debian-Veröffentlichung installieren, müssen Sie berücksichtigen, dass es seit der Veröffentlichung Sicherheitsaktualisierungen gegeben haben könnte, nachdem entdeckt wurde, dass ein bestimmtes Paket verwundbar ist. Ebenso könnte es Zwischenveröffentlichungen gegeben haben, die diese Paketaktualisierungen enthalten. Für Debian 3.1 Sarge gab es vier Zwischenveröffentlichungen.
Während der Installation werden Sicherheitsaktualisierungen für Ihr System eingerichtet, offene Sicherheitsaktualisierungen heruntergeladen und Ihrem System hinzugefügt, sofern Sie sich nicht explizit dagegen entscheiden oder keine Internetverbindung besteht. Die Aktualisierungen werden noch vor dem ersten Systemstart eingespielt, damit das neue System sein Leben so aktuell wie möglich beginnt.
Um Ihr System manuell zu aktualisieren, fügen Sie die folgende Zeile in Ihre
/etc/apt/sources.list
ein. So werden Sie
Sicherheitsaktualisierungen automatisch erhalten, wann immer Sie Ihr System
aktualisieren. Ersetzen Sie [CODENAME] mit dem Namen der
Veröffentlichung, z.B. mit squeeze.
deb http://security.debian.org/ [CODENAME]/updates main contrib non-free
Hinweis: Falls Sie den Testing-Zweig einsetzen, sollten Sie die Sicherheitsspiegel für Testing verwenden. Das wird unter Sicherheitsunterstützung für den Testing-Zweig, Abschnitt 10.1.4 beschrieben.
Wenn Sie dies erledigt haben, stehen Ihnen zahlreiche Werkzeuge zur Verfügung,
mit denen Sie Ihr System aktualisieren können. Wenn Sie ein Desktop-System
einsetzen, können Sie eine Anwendung mit dem Namen
Update-notifier
verwenden[14], mit der Sie leicht prüfen können, ob neue
Aktualisierungen verfügbar sind. Damit können Sie Ihr System auch über den
Desktop auf den neusten Stand bringen (mit update-manager
).
Weitere Informationen finden Sie unter Überprüfung von Aktualisierungen auf dem
Desktop, Abschnitt 10.1.2.2. Für den Desktop können Sie auch
Synaptic
(GNOME), Kpackage
oder Adept
(KDE) einsetzen, die einen größeren Funktionsumfang aufweisen. Wenn Sie auf
einem textbasierten Terminal arbeiten, stehen Ihnen Aptitude
,
Apt
und Dselect
, wobei letzteres veraltet ist, zur
Verfügung:
Falls Sie die textbasierte Oberfläche von Aptitude
verwenden
wollen, müssen Sie zunächst u (für Update) und dann g
(für Upgrade) eingeben. Oder Sie führen auf der Befehlszeile Folgendes als
Root aus:
# aptitude update # aptitude upgrade
Falls Sie Apt
einsetzen möchten, müssen Sie obige Zeilen von
Aptitude
nur mit apt-get
ersetzen.
Falls Sie dselect
verwenden wollen, müssen Sie zuerst
aktualisieren ([U] für Update), dann installieren ([I] für Install) und
schließlich die installieren/aktualisierten Pakete konfigurieren ([C] für
Configure).
Wenn Sie möchten, können Sie der Datei /etc/apt/sources.list
die
Zeilen mit deb-src hinzufügen. Weitere Details finden Sie unter
apt(8)
.
Once you have executed a security update you might need to restart some of the system services. If you do not do this, some services might still be vulnerable after a security upgrade. The reason for this is that daemons that are running before an upgrade might still be using the old libraries before the upgrade [15].
From Debian Jessie and up, you can install the
needrestart
package, which will run automatically after each APT
upgrade and prompt you to restart services that are affected by the
just-installed updates. In earlier releases, you can run the
checkrestart
program (available in the debian-goodies
package) manually after your APT upgrade.
Einige Pakete (wie libc6
) werden diesen Test in der Postinst-Phase
für eine begrenzte Anzahl von Diensten durchführen, da ein Upgrade von
notwendigen Bibliotheken einige Anwendungen unbrauchbar machen kann, wenn sie
nicht neu gestartet werden [16].
Indem das System auf Runlevel 1 (Single User) und dann zurück auf Runlevel 3 (Multi User) gebracht wird, sollten die meisten (wenn nicht alle) Systemdienste neu gestartet werden. Dies ist aber keine Option, wenn Sie die Sicherheitsaktualisierung über eine Verbindung aus der Ferne (z.B. mit Ssh) vornehmen, da diese getrennt werden würde.
Excercise caution when dealing with security upgrades if you are doing them over a remote connection like ssh. A suggested procedure for a security upgrade that involves a service restart is to restart the SSH daemon and then, immediately, attempt a new ssh connection without breaking the previous one. If the connection fails, revert the upgrade and investigate the issue.
Stellen Sie zunächst sicher, dass Ihr Kernel durch das Paketsystem verwaltet wird. Wenn Sie die Installation mit dem Installationssystem von Debian 3.0 oder früher durchgeführt haben, ist Ihr Kernel nicht in das Paketsystem integriert und könnte veraltet sein. Sie können das leicht überprüfen, indem Sie Folgendes ausführen:
$ dpkg -S `readlink -f /vmlinuz` linux-image-2.6.18-4-686: /boot/vmlinuz-2.6.18-4-686
Wenn Ihr Kernel nicht vom Paketsystem verwaltet wird, werden Sie anstatt der
obigen Nachricht die Rückmeldung bekommen, dass das Paketverwaltungsprogramm
kein Paket finden konnte, das mit der Datei verbunden ist. Die obige Meldung
besagt, dass die Datei, die mit dem laufenden Kernel verbunden ist, vom Paket
linux-image-2.6.18-4-686
zur Verfügung gestellt wird. Sie
müssen also zuerst ein Paket mit einem Kernel-Image von Hand installieren.
Das genaue Kernel-Image, das Sie installieren sollten, hängt von Ihrer
Architektur und Ihrer bevorzugten Kernelversion ab. Wenn Sie das einmal
erledigt haben, können Sie die Sicherheitsaktualisierungen des Kernels wie die
jedes anderen Pakets durchführen. Beachten Sie allerdings, dass
Kernelaktualisierungen nur für Aktualisierungen der gleichen
Kernelversion wie der Ihrigen durchgeführt werden. D.h. apt
wird nicht automatisch Ihren Kernel von 2.4 auf 2.6 aktualisieren (oder von
2.4.26 auf 2.4.27 [17]).
Das Installationssystem von aktuellen Debian-Veröffentlichungen wird den gewählten Kernel als Teil des Paketsystems behandeln. So können Sie überprüfen, welche Kernel Sie installiert haben:
$ COLUMNS=150 dpkg -l 'linux-image*' | awk '$1 ~ /ii/ { print $0 }'
Um festzustellen, ob Ihr Kernel aktualisiert werden muss, führen Sie Folgendes aus:
$ kernfile=`readlink -f /vmlinuz` $ kernel=`dpkg -S $kernfile | awk -F : '{print $1}'` $ apt-cache policy $kernel linux-image-2.6.18-4-686: Installiert: 2.6.18.dfsg.1-12 Installationskandidat: 2.6.18.dfsg.1-12 Versionstabelle: *** 2.6.18.dfsg.1-12 0 100 /var/lib/dpkg/status
Wenn Sie eine Sicherheitsaktualisierung durchführen, die auch das Kernel-Image umfasst, müssen Sie das System neu starten, damit die Sicherheitsaktualisierung Wirkung zeigen kann. Anderenfalls lassen Sie immer noch das alte (und verwundbare) Kernel-Image laufen.
Wenn Sie das System neu starten müssen (wegen eines Kernel-Upgrades), sollten
Sie sicherstellen, dass der Kernel fehlerfrei booten wird und die
Netzwerkverbindungen hergestellt werden, besonders wenn die Sicherheitsaktuali
sierung über eine Verbindung aus der Ferne wie mit SSH durchgeführt wird.
Für den ersten Fall können Sie Ihren Boot-Loader so konfigurieren, dass er
den Originalkernel lädt, wenn ein Fehler auftritt (für weiterführende
Informationen sollten Sie Remotely rebooting
Debian GNU/Linux machines
lesen). Im zweiten Fall müssen Sie ein
Skript verwenden, das die Netzwerkverbindungen testen kann und überprüft, ob
der Kernel das Netzwerksystem korrekt gestartet hat, und, wenn das nicht
geschehen ist, das System neu startet [18]. Dies sollte böse Überraschungen verhindern, wie wenn
Sie den Kernel aktualisieren und dann nach einem Reboot merken, dass die
Netzwerkhardware nicht richtig erkannt oder konfiguriert wurde, und Sie daher
eine weite Strecke reisen müssen, um das System wieder zum Laufen zu bringen.
Natürlich hilft es beim Debuggen von Reboot-Problemen aus der Ferne, wenn die
serielle Konsole des Systems [19] mit einem Konsolen- oder Terminalserver verbunden ist.
Erinnern Sie sich an Setzen Sie ein Passwort im BIOS, Abschnitt 3.1? Nun, jetzt sollten Sie, nachdem Sie nicht mehr von Wechseldatenträgern booten müssen, die Standard-BIOS-Einstellung ändern, so dass das System ausschließlich von der Festplatte bootet. Gehen Sie sicher, dass Sie Ihr BIOS-Passwort nicht verlieren, oder Sie werden nicht mehr ins BIOS zurückkehren können, um die Einstellung wieder zu ändern, damit Sie im Falle eines Festplattenfehlers Ihr System wiederherstellen können, indem Sie zum Beispiel eine CD-ROM benutzen.
Eine andere, weniger sichere, aber bequemere Möglichkeit ist es, das BIOS so einzustellen, dass es von der Festplatte bootet, und nur falls dies fehlschlägt zu versuchen, von austauschbaren Datenträgern zu booten. Übrigens wird dies oft so gemacht, weil viele Leute ihr BIOS-Passwort nur selten benutzen, so dass sie es leicht vergessen.
Jeder kann sehr einfach eine Root-Shell auf Ihrem System bekommen, indem er einfach <Name-Ihres-Bootimages> init=/bin/sh am Bootprompt eingibt. Nachdem die Passwörter geändert und das System neu gestartet wurde, hat die Person uneingeschränkten Root-Zugang und kann nach Belieben alles auf Ihrem System machen. Nach dieser Prozedur haben Sie keinen Root-Zugang mehr zu Ihrem System, weil Sie das Root-Passwort nicht kennen.
Um sicher zu stellen, dass dies nicht passieren kann, sollten Sie den Boot-Loader mit einem Passwort schützen. Sie können zwischen einem globalen Passwort und Passwörtern für bestimmte Images wählen.
Für LILO müssen Sie die Konfigurationsdatei /etc/lilo.conf
bearbeiten und eine password- und restricted-Zeile,
wie im folgenden Beispiel, einfügen:
image=/boot/2.2.14-vmlinuz label=Linux read-only password=hackmich restricted
Stellen Sie danach sicher, dass die Konfigurationsdatei nicht für alle lesbar
ist, um zu verhindern, dass lokale Benutzer das Passwort lesen können. Haben
Sie dies getan, rufen Sie lilo auf. Wenn Sie die restricted-Zeile
weglassen, wird LILO immer nach dem Passwort fragen, egal ob LILO Parameter
übergeben wurden oder nicht. Die Standard-Zugriffsrechte auf
/etc/lilo.conf
erlauben Root das Lesen und Schreiben und der
Gruppe von lilo.conf, ebenfalls Root, das Lesen.
Wenn Sie GRUB anstelle von LILO verwenden, bearbeiten Sie
/boot/grub/menu.lst
und fügen Sie die folgenden zwei Zeilen am
Anfang ein (dabei ersetzen Sie natürlich hackmich mit dem
vorgesehenen Passwort). Dies verhindert, dass Benutzer die Booteinträge
verändern können. timeout 3 legt eine Wartedauer von 3 Sekunden
fest, bevor Grub
den Standard-Eintrag bootet.
timeout 3 password hackmich
Um die Integrität Ihres Passwortes zusätzlich abzusichern, können Sie Ihr
Passwort verschlüsselt ablegen. Das Dienstprogramm
grub-md5-crypt
erzeugt ein gehashtes Passwort, das mit GRUBs
Verschlüsselungsalgorithmus (MD5) kompatibel ist. Um Grub
mitzuteilen, dass ein Passwort im MD5-Format verwendet wird, benutzen Sie die
folgende Anweisung:
timeout 3 password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0
Der Parameter --md5 wurde hinzugefügt, um bei Grub
einen
MD5-Authentifizierungsprozess zu erzwingen. Das angegebene Passwort ist die
mit MD5 verschlüsselte Version von »hackmich«. MD5-Passwörter sind
Klartext-Passwörtern vorzuziehen. Weitere Informationen über
Grub
-Passwörter können Sie im Paket grub-doc
finden.
Hinweis: Dies betrifft alle Standard-Kernel, die nach Debian 3.1 veröffentlicht wurden.
Die Linux-Kernel 2.6 enthalten die Möglichkeit, während des Bootvorgangs auf
eine Root-Shell zuzugreifen. Dies geschieht, wenn beim Laden von Initramfs ein
Fehler auftritt. Dadurch kann der Administrator auf eine Rettungs-Shell mit
Root-Rechten zugreifen. Mit dieser Shell können von Hand Module geladen
werden, falls eine automatische Erkennung scheitern sollte. Dieses Verhalten
ist Standard für ein von Initramfs-tools
erzeugtes Initramfs.
Folgende Fehlermeldung wird auftreten:
"ALERT! /dev/sda1 does not exist. Dropping to a shell!
In order to remove this behavior you need to set the following boot
argument:panic=0. Add this to the variable
GRUB_CMDLINE_LINUX in /etc/default/grub
and issue
update-grub
or to the append section of
/etc/lilo.conf
.
Hinweis: Dies trifft nicht auf Kernel zu, die in Debian 3.1 enthalten sind, da die Wartezeit auf Null verändert wurde.
Linux 2.4-Kernel bieten kurz nach dem Laden des Cramfs einen Weg, Zugriff auf
eine Root-Shell zu bekommen, also während das System bootet. Es erscheint
eine Meldung, die dem Administrator erlaubt, eine ausführbare Shell mit
Root-Privilegien zu öffnen. Diese Shell kann dazu benutzt werden, manuell
Module zu laden, falls die automatische Erkennung fehlschlägt. Dies ist das
Standard-Verhalten bei initrd
's linuxrc
. Die
folgende Meldung wird erscheinen:
Press ENTER to obtain a shell (waits 5 seconds)
Um dieses Verhalten zu entfernen, müssen Sie
/etc/mkinitrd/mkinitrd.conf
bearbeiten und folgenden Eintrag
setzen:
# DELAY Anzahl Sekunden, die das linuxrc Skript warten soll, # um den Benutzer Eingriffe zu erlauben, bevor das System hochgefahren # wird DELAY=0
Erstellen Sie anschließend Ihr Ramdisk-Image neu. Dies können Sie zum Beispiel so tun:
# cd /boot # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
oder (vorzugsweise) so:
# dpkg-reconfigure -plow kernel-image-2.4.x-yz
Manche Sicherheitsrichtlinien können Administratoren dazu zwingen, sich erst
als Benutzer mit ihrem Passwort auf dem System einzuloggen und dann Superuser
zu werden (mit Su
oder Sudo
). Eine solche Richtlinie
wird in Debian durch Bearbeitung der Dateien /etc/pam.d/login
und
/etc/securetty
(falls Sie PAM verwenden) implementiert.
Die Datei /etc/pam.d/login
[20] aktiviert das Modul pam_securetty.so. Wenn es richtig
konfiguriert ist, wird Root, wenn er sich auf einer unsicheren Konsole anmelden
will, nicht nach einem Passwort gefragt, sondern sein Anmeldeversuch wird
abgelehnt.
In securetty
[21]
entfernen Sie oder fügen Sie Terminals hinzu, auf denen sich Root anmelden
darf. Falls Sie nur lokalen Zugang zur Konsole erlauben wollen, benötigen Sie
console, ttyX [22] und vc/X (falls Sie die
devfs-Schnittstelle verwenden). Sie sollten auch ttySX [23] hinzufügen, wenn Sie eine
serielle Konsole für den lokalen Zugang verwenden (wobei X eine ganze Zahl
ist; es kann wünschenswert sein, mehrere Instanzen zu verwenden). Die
Standardeinstellung in Wheezy [24] beinhaltet viele tty-Konsolen, serielle Schnittstellen und
virtuelle Konsolen sowie den X-Server und das console-Gerät. Sie
können das ohne Probleme anpassen, wenn Sie nicht derartige viele Konsolen
benutzen. Sie können die Anzahl der Konsolen und Schnittstellen in
/etc/inittab
überprüfen [25]. Weiterführende Informationen zu Terminal-Schnittstellen
finden Sie im Text-Terminal-HOWTO
.
Wenn Sie PAM benutzen, können Sie auch andere Änderungen am Login-Prozess,
die auch Einschränkungen für einzelne Benutzer oder Gruppen zu bestimmten
Zeiten enthalten können, durch Konfiguration der Datei
/etc/pam.d/login
vornehmen. Eine interessante Eigenschaft, die
man auch abschalten kann, ist die Möglichkeit, sich mit einem leeren Passwort
(Null-Passwort) anzumelden. Diese Eigenschaft kann eingeschränkt werden,
indem Sie nullok aus folgender Zeile entfernen:
auth required pam_unix.so nullok
Wenn eine Tastatur an Ihr System angeschlossen ist, kann es jeder (ja, wirklich jeder) mit physischem Zugang zu Ihrem System neu starten, ohne sich an Ihrem System anmelden zu müssen, einfach indem er die Tastenkombination Strg+Alt+Entf drückt (auch als Affengriff bekannt). Dies könnte gegen Ihre Sicherheitsrichtlinien verstoßen (oder auch nicht).
Dies ist schwerwiegender, wenn das Betriebssystem in einer virtuellen Umgebung läuft. Dann erstreckt sich diese Fähigkeit auch auf Benutzer, die Zugriff auf die virtuelle Konsole haben (was auch über das Netzwerk geschehen könnte). Beachten Sie zudem, dass in einer solchen Umgebung diese Tastenkombination ständig verwendet wird (um in einigen grafischen Benutzeroberflächen eine Login-Shell zu öffnen), so dass ein Systemadministrator sie virtuell auslösen kann und das System neu startet.
Es gibt zwei Möglichkeiten, dies einzuschränken:
mit einer Konfiguration, mit der nur bestimmte Benutzer das System neu starten dürfen,
diese Eigenschaft vollständig zu deaktivieren.
Wenn Sie dies einschränken wollen, müssen Sie in /etc/inittab
sicherstellen, dass die Zeile, die ctrlaltdel enthält,
shutdown
mit der Option -a aufruft.
Standardmäßig enthält Debian diese Optionen:
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Die Option -a ermöglicht es, einigen Benutzern zu
erlauben, das System neu zu starten (vgl. die Handbuchseite
shutdown(8)
). Dazu müssen Sie die Datei
/etc/shutdown.allow
erstellen und die Namen der Benutzer, die das
System neu booten dürfen, eintragen. Wenn der Affengriff in einer
Konsole ausgeführt wird, wird geprüft, ob irgendeiner der Benutzer, die in
der Datei aufgelistet sind, angemeldet ist. Wenn es keiner von ihnen ist, wird
Shutdown
das System nicht neu starten.
Wenn Sie die Tastenkombination Strg+Alt+Entf deaktivieren möchten, müssen Sie
nur die Zeile mit ctrlaltdel in /etc/inittab
auskommentieren.
Vergessen Sie nicht, init q auszuführen, nachdem Sie diese Datei bearbeitet haben, damit die Änderungen wirksam werden.
Die Tastenkombination Magische S-Abf (Magic SysRq) erlaubt es Benutzern einer Konsole eines Linux-Systems, bestimmte systemnahe Befehle auszuführen, indem gleichzeitig Alt+S-Abf und eine bestimmte Taste gedrückt wird. Die Taste S-Abf wird auf vielen Tastaturen mit Druck bezeichnet.
Seit der Veröffentlichung von Etch ist die Tastenkombination Magische S-Abf im
Linux-Kernel aktiviert, damit die Benutzer einer Konsole bestimmte Privilegien
erhalten können. Ob dies auf Ihr System zutrifft, erkennen Sie daran, ob
/proc/sys/kernel/sysrq
existiert, und an dessen Wert:
$ cat /proc/sys/kernel/sysrq 438
Der oben gezeigte Standardwert erlaubt alle S-Abf-Funktionen mit Ausnahme der Möglichkeit, Signale an Prozesse zu senden. Zum Beispiel können Benutzer, die an der Konsole angemeldet sind, alle Systeme nur-lesend neu einhängen, das System neu starten oder eine Kernelpanik auslösen. Wenn alle Fähigkeit aktiviert sind oder in älteren Kernel-Versionen (früher als 2.6.12), wird der Wert einfach 1 sein.
Sie sollten diese Fähigkeit deaktivieren, wenn der Zugang zur Konsole nicht
auf angemeldete Benutzer beschränkt ist, nämlich wenn die Konsole an ein
Modem angebunden ist, es leichten physischen Zugang zum System gibt oder es in
einer virtuellen Umgebung läuft und andere Benutzer auf die Konsole zugreifen
können. Dafür müssen Sie /etc/sysctl.conf
bearbeiten und
folgende Zeile einfügen:
# Schaltet die Magische S-Abf-Taste ab kernel.sysrq = 0
Weitere Informationen finden Sie im security
chapter in the Remote Serial Console HOWTO
, in der Kernel SysRQ
documentation
und dem Wikipedia-Eintrag zur
Magischen S-Abf-Taste
.
Wenn Sie ein Ext-Dateisystem (ext2, ext3
oder ext4) einhängen, können Sie verschiedene Optionen mit dem
mount-Befehl oder in /etc/fstab
verwenden. Dies ist zum Beispiel
mein fstab-Eintrag für meine /tmp
-Partition:
/dev/hda7 /tmp ext2 defaults,nosuid,noexec,nodev 0 2
Achten Sie auf den Abschnitt mit den Optionen. Die Option nosuid ignoriert komplett alle setuid- und setgid-Bits, während noexec das Ausführen von Programmen unterhalb des Einhängepunkts verbietet und nodev Gerätedateien ignoriert. Das hört sich toll an, aber:
ist nur auf ext2 oder ext3-Dateisysteme anwendbar,
kann leicht umgangen werden.
Die Option noexec, die verhindert, dass Programme ausgeführt werden können, ließ sich in früheren Kernelversionen leicht umgehen:
alex@joker:/tmp# mount | grep tmp /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev) alex@joker:/tmp# ./date bash: ./date: Keine Berechtigung alex@joker:/tmp# /lib/ld-linux.so.2 ./date So 3. Dec 17:49:23 CET 2000
Neuere Versionen des Kernels verarbeiten aber die Option noexec richtig:
angrist:/tmp# mount | grep /tmp /dev/hda3 on /tmp type ext3 (rw,noexec,nosuid,nodev) angrist:/tmp# ./date bash: ./tmp: Keine Berechtigung angrist:/tmp# /lib/ld-linux.so.2 ./date ./date: error while loading shared libraries: ./date: failed to map segment from shared object: Operation not permitted
However, many script kiddies have exploits which try to create and execute
files in /tmp
. If they do not have a clue, they will fall into
this pit. In other words, a user cannot be tricked into executing a trojanized
binary in /tmp
e.g. when /tmp
is accidentally added
into the local PATH.
Seien Sie sich auch bewusst, dass manche Skripte darauf aufbauen, dass
/tmp
ausführbare Rechte hat. Bemerkenswerterweise hatte (oder
hat?) Debconf Probleme bei dieser Sache, weitere Informationen enthält Fehler
116448
.
Nachfolgend ein gründlicheres Beispiel. Eine Anmerkung dazu:
/var
könnte auch noexec enthalten, aber manche Software [26] verwahrt ihre Programme
unterhalb von /var
. Dasselbe gilt für die Option nosuid.
/dev/sda6 /usr ext3 defaults,ro,nodev 0 2 /dev/sda12 /usr/share ext3 defaults,ro,nodev,nosuid 0 2 /dev/sda7 /var ext3 defaults,nodev,usrquota,grpquota 0 2 /dev/sda8 /tmp ext3 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda9 /var/tmp ext3 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda10 /var/log ext3 defaults,nodev,nosuid,noexec 0 2 /dev/sda11 /var/account ext3 defaults,nodev,nosuid,noexec 0 2 /dev/sda13 /home ext3 rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota 0 2 /dev/fd0 /mnt/fd0 ext3 defaults,users,nodev,nosuid,noexec 0 0 /dev/fd0 /mnt/floppy vfat defaults,users,nodev,nosuid,noexec 0 0 /dev/hda /mnt/cdrom iso9660 ro,users,nodev,nosuid,noexec 0 0
/tmp
noexec setzen
Seien Sie vorsichtig, wenn Sie /tmp
noexec setzen und neue
Software installieren wollen, da manche Software es während der Installation
benutzt. Apt
ist ein solches Programm (siehe http://bugs.debian.org/116448
),
wenn nicht APT::ExtractTemplates::TempDir (siehe
apt-extracttemplates(1)
) passend konfiguriert wurde. Sie können
diese Variable in /etc/apt/apt.conf
auf ein anderes Verzeichnis
als /tmp
mit exec-Privilegien setzen.
Wenn Sie auf /usr
nur lesenden Zugriff erlauben, werden Sie nicht
in der Lage sein, neue Pakete auf Ihrem Debian-GNU/Linux-System zu
installieren. Sie werden es erst mit Schreibzugriff erneut einhängen müssen,
die Pakete installieren und dann wieder nur mit lesendem Zugriff einhängen.
Apt
kann so konfiguriert werden, dass Befehle vor und nach dem
Installieren von Paketen ausgeführt werden. Daher müssen Sie es passend
konfigurieren.
Dafür müssen Sie /etc/apt/apt.conf
bearbeiten und Folgendes
einfügen:
DPkg { Pre-Invoke { "mount /usr -o remount,rw" }; Post-Invoke { "mount /usr -o remount,ro" }; };
Beachten Sie, dass das Post-Invoke mit der Fehlermeldung »/usr ist belegt« scheitern kann. Dies passiert vorwiegend, wenn Sie eine Datei benutzen, die aktualisiert wurde. Sie können diese Programme finden, indem Sie Folgendes ausführen:
# lsof +L1
Halten Sie diese Programme an oder starten Sie sie erneut und rufen dann
Post-Invoke manuell auf. Achtung! Das bedeutet, dass Sie
wahrscheinlich jedes Mal Ihre Sitzung von X (falls Sie eine laufen haben) neu
starten müssen, wenn Sie ein größeres Upgrade Ihres Systems durchführen.
Sie müssen entscheiden, ob ein nur lesbares /usr
zu Ihrem System
passt. Vergleichen Sie auch diese discussion
on debian-devel about read-only /usr
.
PAM (Pluggable Authentication Modules) erlaubt Systemadministratoren,
auszuwählen, wie Anwendungen Benutzer authentifizieren. Beachten Sie, dass
PAM nichts machen kann, solange die Anwendung nicht mit Unterstützung für PAM
kompiliert wurde. Die meisten Anwendungen, die mit Debian geliefert werden,
haben diese Unterstützung eingebaut. Vor Version 2.2 hatte Debian keine
Unterstützung für PAM. Die derzeitige Standardkonfiguration für jeden
Dienst, der PAM benutzt, ist es, UNIX-Authentifizierung zu emulieren (lesen Sie
/usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz
, um mehr darüber
zu erfahren, wie PAM-Dienste unter Debian arbeiten sollten).
Jede Anwendung mit PAM-Unterstützung stellt eine Konfigurationsdatei unter
/etc/pam.d/
zur Verfügung, in welcher Sie ihr Verhalten
einstellen können:
welches Verfahren zur Authentifizierung benutzt wird
welches Verfahren innerhalb einer Sitzung benutzt wird
wie Passwörter überprüft werden
Die folgende Beschreibung ist weit davon entfernt, vollständig zu sein. Für
weitere Informationen können Sie die Linux-PAM Guides
lesen. Diese Dokumentation ist auf Ihrem System unter
/usr/share/doc/libpam-doc/html/
verfügbar, wenn Sie
libpam-doc
installieren.
PAM offers you the possibility to go through several authentication steps at
once, without the user's knowledge. You could authenticate against a Berkeley
database and against the normal passwd
file, and the user only
logs in if the authentication succeeds in both. You can restrict a lot with
PAM, just as you can open your system doors very wide. So be careful. A
typical configuration line has a control field as its second element.
Generally it should be set to requisite, which returns a login
failure if one module fails.
Sehen Sie sich /etc/pam.d/common-password
an, die von
/etc/pam.d/passwd
eingebunden wird. [27] Andere Dateien in
/etc/pam.d/
lesen diese Datei ein, um die Verwendung eines
Passworts durch Programme, die einen Zugriff auf das System erlauben, wie etwa
das Konsolen-Login (Login), grafische Login-Manager (z.B.
Gdm oder Lightdm) und Login aus der Ferne (etwa mit
Sshd), zu definieren.
Sie müssen sicherstellen, dass das Modul pam_unix.so die Option »sha512« verwendet, damit die Passwörter verschlüsselt werden. In Debian Squeeze ist dies standardmäßig eingerichtet.
Die Zeile mit der Konfiguration des Moduls pam_unix sollte etwa so aussehen:
password [success=1 default=ignore] pam_unix.so nullok obscure minlen=8 sha512
Dieser Ausdruck
erzwingt die Verschlüsselung von Passwörtern mit der Hashfunktion SHA-512, wenn sie gespeichert werden (Option sha512),
aktiviert die Überprüfung der Komplexität eines Passworts, wie sie in der
Handbuchseite pam_unix(8)
beschrieben wird (Option
obscure),
erfordert, dass das Passwort mindestens acht Zeichen lang ist (Option min).
Sie müssen sicherstellen, dass in PAM-Anwendungen verschlüsselte Passwörter verwendet werden, weil dies Wörterbuchangriffe erschwert. Zugleich wird es dadurch möglich, Passwörter mit mehr als acht Zeichen einzusetzen.
Da mit diesem Modul auch definiert wird, wie Passwörter geändert werden, weil
es von Chpasswd eingebunden wird, können Sie die
Passwortsicherheit Ihres Systems erhöhen, indem sie
libpam-cracklib
installieren und folgenden Ausdruck in die
Konfigurationsdatei /etc/pam.d/common-password
eintragen:
# Gehen Sie sicher, dass Sie libpam-cracklib zuerst installiert haben, # sonst werden Sie sich nicht einloggen können password required pam_cracklib.so retry=3 minlen=12 difok=3 password [success=1 default=ignore] pam_unix.so obscure minlen=8 sha512 use_authok
Also, was macht diese Beschwörungsformel nun genau? Die erste Zeile lädt das
PAM-Modul cracklib, welches einen Passwort-Sicherheitscheck bereitstellt. Es
fragt nach einem neuen Passwort mit mindestens zwölf Zeichen [28], einer Differenz von
mindestens drei Zeichen zum alten Passwort und erlaubt drei Versuche. Cracklib
benötigt ein Paket mit Wörterlisten (wie wngerman
,
wenglish
, wspanish
, ...). Stellen Sie also sicher,
dass Sie ein passendes Paket für Ihre Sprache installiert haben. Ansonsten
ist Cracklib nicht verwendbar.
Die zweite Zeile (mit dem Module pam_unix.so) ist – wie oben beschrieben – der Standard in Debian mit Ausnahme der Option use_authok. Diese Option ist notwendig, wenn pam_unix.so nach pam_cracklib.so aufgerufen wird, damit das Passwort vom zuerst aufgerufenen Modul weitergereicht wird. Anderenfalls muss der Benutzer sein Passwort zweimal eingegeben.
Weitere Informationen über die Konfiguration von Cracklib finden Sie in der
Handbuchseite pam_cracklib(8)
und dem Artikel Linux Password
Security with pam_cracklib
von Hal Pomeranz.
Mit dem PAM-Modul Cracklib richten Sie eine Richtlinie ein, welche die Verwendung guter Passwörter erzwingt.
Als Alternative können Sie auch PAM-Module einsetzen, die eine
Zwei-Faktor-Authentifizierung verwenden, wie z.B. libpam-barada
,
libpam-google-authenticator
, libpam-oath
,
libpam-otpw
, libpam-poldi
, libpam-usb
oder libpam-yubico
. Diese Module ermöglichen es, sich mit einer
externen Authentifizierungsmethode am System anzumelden, etwa mit einer
Chipkarte, einem USB-Stick oder Einmal-Passwörtern, die mit einer externen
Anwendung, z.B. auf einem Mobiltelefon, erzeugt wurden.
Please note that these restrictions apply to all users but not to the password changes done by the root user. The root user will be able to set up any password (any length or complexity) for personal use or others regardless of the restrictions defined here.
Um sicher zu stellen, dass sich der Benutzer Root nur an lokalen Terminals
anmelden kann, sollten Sie die folgende Zeile in /etc/pam.d/login
einfügen:
auth requisite pam_securetty.so
Danach sollten Sie die Liste der Terminals in /etc/securetty
ändern, auf denen sich Root unmittelbar anmelden darf (wie in Einschränkung der Anmeldemöglichkeiten an
der Konsole, Abschnitt 4.7 beschrieben). Alternativ dazu können Sie auch
das pam_access-Modul aktivieren und
/etc/security/access.conf
bearbeiten. Dieses Vorgehen erlaubt
eine allgemeinere und feiner abgestimmte Zugangssteuerung, leider fehlen aber
vernünftige Protokollmeldungen (diese sind in PAM nicht standardisiert und
sind ein besonders unbefriedigendes Problem). Wir werden zu
access.conf
in Kürze zurückkehren.
The following line should be enabled in /etc/pam.d/login
to set up
user resource limits.
session required pam_limits.so
Dies schränkt die Systemressourcen ein, die ein Benutzer nutzen darf (siehe Ressourcen-Nutzung begrenzen: Die Datei
limits.conf
, Abschnitt 4.11.2 weiter unten). Sie können zum
Beispiel die Anzahl der Logins, die man haben kann, einschränken (für eine
Gruppe von Benutzern oder systemweit), die Anzahl der Prozesse, den belegten
Speicher etc.
Wenn Sie Su
schützen möchten, so dass nur manche Leute es
benutzen können, um Root auf Ihrem System zu werden, müssen Sie eine neue
Gruppe »wheel« zu Ihrem System hinzufügen (das ist der sauberste Weg, da
keine Datei solche Gruppenrechte bisher benutzt). Fügen Sie Root und die
anderen Benutzer, die zu Root su
en können sollen, zu dieser
Gruppe hinzu. Ergänzen Sie anschließend /etc/pam.d/su/
um die
folgende Zeile:
auth requisite pam_wheel.so group=wheel debug
Dies stellt sicher, dass nur Personen aus der Gruppe »wheel« su
benutzen können, um Root zu werden. Andere Benutzer wird es nicht möglich
sein, Root zu werden. Tatsächlich werden sie eine ablehnende Nachricht
bekommen, wenn sie versuchen, Root zu werden.
If you want only certain users to authenticate at a PAM service, this is quite
easy to achieve by using files where the users who are allowed to login (or
not) are stored. Imagine you only want to allow users 'ref' to log in via
ssh
. So you put them into /etc/sshusers-allowed
and
write the following into /etc/pam.d/ssh
:
auth required pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail
Da es eine Reihe von Sicherheitslücken mit so genannten unsicheren temporären
Dateien zum Beispiel in Thttpd (vgl. DSA-883-1
) gab,
lohnt es sich, das Paket libpam-tmpdir
zu installieren. Sie
müssen dann lediglich Folgendes zu /etc/pam.d/common-session
hinzuzufügen:
session optional pam_tmpdir.so
Es gab auch eine Diskussion, dies standardmäßig in Debian einzufügen. Sehen
Sie sich http://lists.debian.org/debian-devel/2005/11/msg00297.html
für weitere Informationen an.
Zuletzt, aber nicht am unwichtigsten, erstellen Sie
/etc/pam.d/other
mit den folgenden Zeilen:
auth required pam_securetty.so auth required pam_unix_auth.so auth required pam_warn.so auth required pam_deny.so account required pam_unix_acct.so account required pam_warn.so account required pam_deny.so password required pam_unix_passwd.so password required pam_warn.so password required pam_deny.so session required pam_unix_session.so session required pam_warn.so session required pam_deny.so
Diese Zeilen stellen für alle Anwendungen, die PAM unterstützen, eine gute Standardkonfiguration dar (Zugriff wird standardmäßig verweigert).
limits.conf
Sie sollten sich wirklich ernsthaft mit dieser Datei beschäftigen. Hier
können Sie Ihren Benutzern Ressourcengrenzen vorgeben. In alten
Veröffentlichungen war die Konfigurationsdatei /etc/limits.conf
.
Aber in neueren Versionen (mit PAM) sollte stattdessen die Konfigurationsdatei
/etc/security/limits.conf
benutzt werden.
Wenn Sie die Ressourcennutzung nicht einschränken, kann jeder Benutzer mit einer gültigen Shell auf Ihrem System (oder sogar ein Einbrecher, der das System durch einen Dienst kompromittierte, oder ein außer Kontrolle geratener Daemon) so viel CPU, Speicher, Stack etc. benutzen, wie das System zur Verfügung stellen kann. Dieses Problem der Überbeanspruchung von Ressourcen kann mit der Nutzung von PAM gelöst werden.
Es gibt einen Weg, Ressourcengrenzen zu manchen Shells hinzuzufügen (zum
Beispiel hat Bash
ulimit
, siehe
bash(1)
). Aber da nicht alle die gleichen Höchstgrenzen zur
Verfügung stellen und der Benutzer seine Shell ändern kann (siehe
chsh(1)
), ist es besser, die Höchstgrenzen in den PAM-Modulen zu
platzieren, da diese unabhängig von der verwendeten Shell Anwendung finden und
auch PAM-Module betreffen, die nicht shellorientiert sind.
Ressourcengrenzen werden vom Kernel verhängt, aber sie müssen durch
limits.conf
konfiguriert werden und die PAM-Konfiguration der
verschiedenen Dienste muss das passende PAM laden. Sie können herausfinden,
welche Dienste Höchstgrenzen durchsetzen, indem Sie Folgendes ausführen:
$ find /etc/pam.d/ \! -name "*.dpkg*" | xargs -- grep limits |grep -v ":#"
Für gewöhnlich setzen Login
, Ssh
und die grafischen
Sitzungsmanager (Gdm
, Kdm
und Xdm
)
Benutzerhöchstgrenzen durch, aber Sie sollte dies auch in anderen
Konfigurationsdateien für PAM wie für Cron
vornehmen, um zu
verhindern, dass System-Daemons alle Systemressourcen aufbrauchen.
Die konkreten Begrenzungen, die Sie festlegen wollen, hängt von den Ressourcen Ihres Systems ab. Das ist einer der Hauptgründe, warum keine Höchstgrenzen in der Standardinstallation enthalten sind.
So setzt die Konfiguration im Beispiel unten eine Begrenzung von 100 Prozessen für alle Benutzer (um Fork-Bomben [29] zu vermeiden), eine Begrenzung auf 10 MB Speicher pro Prozess und ein Höchstgrenze von 10 gleichzeitigen Logins durch. Benutzer in der Gruppe adm haben höhere Begrenzungen und können Dateien mit einem Speicherabbild schreiben, wenn sie das wollen (es gibt also nur eine weiche Begrenzung).
* soft core 0 * hard core 0 * hard rss 1000 * hard memlock 1000 * hard nproc 100 * - maxlogins 1 * hard data 102400 * hard fsize 2048 @adm hard core 100000 @adm hard rss 100000 @adm soft nproc 2000 @adm hard nproc 3000 @adm hard fsize 100000 @adm - maxlogins 10
Dies könnten die Höchstgrenzen eines Standardbenutzers (einschließlich der System-Daemons) sein:
$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) 102400 file size (blocks, -f) 2048 max locked memory (kbytes, -l) 10000 max memory size (kbytes, -m) 10000 open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 100 virtual memory (kbytes, -v) unlimited
Und dies die Höchstgrenzen für einen Administrator:
$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) 102400 file size (blocks, -f) 100000 max locked memory (kbytes, -l) 100000 max memory size (kbytes, -m) 100000 open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 2000 virtual memory (kbytes, -v) unlimited
Lesen Sie für weitere Informationen:
Seifried's
Securing Linux Step by Step
in dem Abschnitt Limiting users
overview
LASG
in dem
Abschnitt Limiting and monitoring users
/etc/login.defs
Der nächste Schritt ist es, die grundlegende Konfiguration und die Aktionen
bei der Benutzeranmeldung zu bearbeiten. Beachten Sie, dass diese Datei kein
Bestandteil der PAM-Konfiguration ist. Sie ist eine Konfigurationsdatei, die
von den Programmen Login und Su berücksichtigt wird.
Es ist also wenig sinnvoll, sie auf Fälle abzustimmen, in denen keines der
beiden Programme wenigstens indirekt aufgerufen wird (Das Programm
Getty
, welches auf der Konsole läuft und die anfängliche
Anmeldeaufforderung zu Verfügung stellt, ruft Login
auf).
FAILLOG_ENAB yes
Wenn Sie diese Variable einschalten, werden fehlgeschlagene Anmeldeversuche protokolliert. Es ist wichtig, hier auf dem Laufendem zu bleiben, um jemanden zu ermitteln, der einen Brute-Force-Angriff versucht.
LOG_UNKFAIL_ENAB no
Wenn Sie diese Variable auf »yes« setzen, werden unbekannte Benutzernamen protokolliert, wenn eine Anmeldung scheitert. Es ist zu empfehlen, sie auf »no« (den Standard) zu belassen, da anderenfalls das Passwort eines Benutzers aufgezeichnet werden könnte (falls er nämlich versehentlich anstatt seines Benutzernames sein Passwort eingibt). Falls Sie sie dennoch auf »yes« setzen, müssen Sie sicherstellen, dass die Protokolldateien angemessene Zugriffsrechte haben (zum Beispiel 640, mit einer passenden Gruppenzugehörigkeit wie adm).
SYSLOG_SU_ENAB yes
Dies schaltet das Mitprotokollieren von su
-Versuchen im
Syslog
ein. Sehr wichtig auf ernsthaft betriebenen Maschinen,
aber beachten Sie, dass dies auch die Privatsphäre verletzen kann.
SYSLOG_SG_ENAB yes
Das gleiche wie bei SYSLOG_SU_ENAB, aber für das Programm
Sg
.
ENCRYPT_METHOD SHA512
Wie bereits erklärt, reduziert eine Verschlüsselung von Passwörtern die
Gefahr von Wörterbuchangriffen erheblich, da Sie längere Passwörter benutzen
können. Diese Definition muss mit dem Wert in
/etc/pam.d/common-password
übereinstimmen.
/etc/pam.d/login
bearbeitenSie können die Datei zur Konfiguration des Anmeldevorgangs anpassen, um eine strengere Richtlinie festzuschreiben. Zum Beispiel können Sie die Wartezeit zwischen zwei Anmeldeversuchen im Vergleich zur Standardkonfiguration erhöhen. Diese Standardvorgabe setzt eine Wartezeit von drei Sekunden:
auth optional pam_faildelay.so delay=3000000
Wenn Sie den Wert von delay erhöhen, wird es schwieriger, sich durch bloßes Ausprobieren von Passwörtern (brute force) erfolgreich am Terminal anzumelden. Wenn ein falsches Passwort eingegeben wird, muss ein möglicher Angreifer (oder ein normaler Benutzer!) viele Sekunden warten, bis er wieder eine Eingabeaufforderung erhält, wodurch das Durchprobieren von Passwörtern sehr zeitaufwendig werden kann. So müssen etwa Benutzer bei delay=10000000 zehn Sekunden warten, wenn sie das falsche Passwort eingeben.
In dieser Datei können Sie auch einrichten, dass das System dem Benutzer vor einer Anmeldung eine Nachricht anzeigt. Standardmäßig ist dies deaktiviert, wie Sie hier sehen können:
# auth required pam_issue.so issue=/etc/issue
Falls es Ihre Sicherheitsrichtlinie erfordert, können Sie mit dieser Datei
eine Standardnachricht, dass der Zugang zum System beschränkt und der
Benutzerzugang protokolliert wird, anzeigen lassen. Ein solcher Hinweis kann
in bestimmten Regionen und nach der jeweiligen Rechtsprechung notwendig sein.
Um dies zu aktivieren, müssen Sie nur die entsprechende Mitteilung in die
Datei /etc/issue
[30] eintragen und das Kommentarzeichen in der Zeile in
/etc/pam.d/login
entfernen, um das Modul pam_issue.so zu
aktivieren. In dieser Datei können Sie weitere Einstellungen vornehmen, die
für Ihre Sicherheit relevant sein könnten, wie zum Beispiel:
Regeln erstellen, welcher Benutzer zu welchen Zeiten auf das System zugreifen
kann, indem Sie das Modul pam_time.so aktivieren und
/etc/security/time.conf
entsprechend konfigurieren
(standardmäßig deaktiviert),
den Anmeldevorgang so einrichten, dass Benutzerbegrenzungen, die in
/etc/security/limits.conf
definiert sind, verwendet werden
(standardmäßig aktiviert),
dem Benutzer Informationen über die vorangegangene Anmeldung anzeigen (standardmäßig aktiviert),
nach erfolgter Anmeldung den Benutzern eine Nachricht (/etc/motd
und /run/motd.dynamic
) anzeigen (standardmäßig aktiviert).
/etc/ftpusers
Die Datei /etc/ftpusers
enthält eine Liste von allen Benutzern,
denen es nicht erlaubt ist, sich auf dem Rechner mit Ftp einzuloggen.
Benutzen Sie diese Datei nur, wenn Sie wirklich Ftp erlauben wollen (wozu im
Allgemeinen nicht geraten wird, da es Klartext-Passwörter benutzt). Wenn Ihr
Ftp-Daemon PAM unterstützt, können Sie dies ebenfalls benutzen, um Benutzern
bestimmte Dienste zu erlauben oder zu verbieten.
FIXME (FEHLER): Ist es ein Fehler, dass ftpusers
in Debian
standardmäßig nicht die Benutzer mit Administratorenrecht (in
base-passwd
) beinhaltet?
Folgender Befehl ist ein bequemer Weg, alle Systemkonten zu
/etc/ftpusers
hinzuzufügen:
$ awk -F : '{if ($3<1000) print $1}' /etc/passwd > /etc/ftpusers
Wenn es wirklich benötigt wird, dass Benutzer der Super-User (also Root,
d.Ü.) auf Ihrem System werden, zum Beispiel um Pakete zu installieren oder
neue Benutzer anzulegen, können Sie das Programm Su
benutzen, um
Ihre Identität zu wechseln. Sie sollten jeden Login als Benutzer Root
vermeiden und stattdessen das Programm Su
benutzen. Eigentlich
ist die beste Lösung, Su
zu entfernen und zu Sudo
zu
wechseln, da es eine feinere Steuerung und mehr Möglichkeiten bietet als
Su
. Wie auch immer, Su
ist verbreiteter und wird auf
vielen Unices eingesetzt.
sudo
allows the user to execute defined commands under another
user's identity, even as root. If the user is added to
/etc/sudoers
and authenticates correctly, the commands defined in
/etc/sudoers
get enabled. Violations, such as incorrect passwords
or trying to run a program you don't have permission for, are logged and mailed
to root.
Sie sollten /etc/security/access.conf
ebenfalls so verändern,
dass ein Login aus der Ferne in ein administratives Konto nicht erlaubt wird.
Auf diese Weise müssen Benutzer das Programm Su
(oder
Sudo
) aufrufen, um Administratorenrechte zu bekommen, so dass es
immer eine nachprüfbare Spur gibt.
Sie müssen die folgende Zeile zu Ihrer /etc/security/access.conf
hinzufügen, in Debians Standardkonfigurationsdatei ist ein Beispiel
auskommentiert:
-:wheel:ALL EXCEPT LOCAL
Vergessen Sie nicht, in /etc/pam.d/
das
pam_access-Module für jeden Dienst (oder die
Standardkonfiguration) anzuschalten, wenn Sie wollen, dass Ihre Änderungen an
/etc/security/access.conf
berücksichtigt werden.
Manchmal werden Sie denken, dass Sie einen Benutzer auf Ihrem System erstellen müssen, um einen bestimmten Dienst (Pop3-E-Mail-Server oder Ftp) anzubieten. Bevor Sie dies tun, denken Sie zuerst daran, dass die PAM-Implementierung in Debian GNU/Linux Ihnen erlaubt, Benutzer mit einer breiten Auswahl von externen Verzeichnisdiensten (Radius, LDAP etc.) zu überprüfen. Dies wird vom Paket libpam bewerkstelligt.
Wenn Sie einen Benutzer anlegen müssen und auf Ihr System aus der Ferne
zugegriffen werden kann, beachten Sie, dass es Benutzern möglich sein wird,
sich anzumelden. Sie können dies beheben, indem Sie diesen Benutzern Null
(/dev/null
) als Shell (sie muss in /etc/shells
aufgelistet sein) zuweisen. Wenn Sie den Benutzern erlauben wollen, auf das
System zuzugreifen, aber ihre Bewegungen einschränken wollen, können Sie
/bin/rbash
benutzen. Dies hat das gleiche Ergebnis, wie wenn Sie
die Option -r der Bash
(RESTRICTED SHELL,
siehe bash(1)
) verwendet hätten. Beachten Sie bitte, dass sogar
mit einer beschränkten Shell ein Benutzer, der auf ein interaktives Programm
zugreifen kann (das ihm erlaubt, eine Subshell auszuführen), diese Limitierung
der Shell umgehen kann.
Debian bietet zurzeit in seiner Unstable-Veröffentlichung (und wird es
vielleicht der nächsten Stable-Veröffentlichung hinzufügen) das Modul
pam_chroot
(in libpam-chroot
) an. Eine Alternative
hierzu ist es, die Dienste, die eine Fernanmeldung ermöglichen
(Ssh
und Telnet
), in einer
Chroot
-Umgebung laufen zu lassen. [31]
Wenn Sie einschränken wollen, wann ein Benutzer auf das System
zugreifen kann, müssen Sie /etc/security/access.conf
an Ihre
Bedürfnisse anpassen.
Informationen, wie man Benutzer, die auf das System mittels des Dienstes
Ssh
zugreifen, in eine Chroot
-Umgebung einsperrt,
wird in Chroot
-Umgebung für
SSH
, Anhang G beschrieben.
Wenn Sie wirklich paranoid sind, sollten Sie eine systemweite Einrichtung verwenden, um zu überwachen, was die Benutzer auf Ihrem System tun. In diesem Abschnitt werden einige Tipps vorgestellt, wie Sie verschiedene Werkzeuge verwenden.
Um sowohl die von den Benutzern ausgeführten Programme als auch deren
Ergebnisse zu überwachen, können Sie den Befehl script
verwenden. Sie können script
nicht als eine Shell einsetzen
(auch dann nicht, wenn Sie es zu /etc/shells
hinzufügen). Aber
Sie können in die Datei, welche den Startvorgang der Shell steuert, folgendes
eintragen:
umask 077 exec script -q -a "/var/log/sessions/$USER"
Wenn Sie dies systemweit vornehmen, bedeutet dies natürlich, dass die Shell
die weiteren persönlichen Startdateien nicht abarbeitet (weil die Shell von
script
überschrieben wird). Eine Alternative ist, dies in den
Startdateien des Benutzers vorzunehmen (dann kann der Benutzer aber dies
entfernen, vgl. dazu die Anmerkungen unten).
Sie müssen auch die Dateien im Überwachungsverzeichnis (im Beispiel
/var/log/sessions/
) so einrichten, dass die Benutzer in sie
schreiben, sie aber nicht löschen können. Dies kann zum Beispiel
bewerkstelligt werden, indem die Sitzungsdateien der Benutzer vorab erstellt
und mit chattr
auf append-only (nur anfügen) gesetzt
werden.
Eine sinnvolle Alternative für Systemadministratoren, die auch Zeitinformationen enthält, ist:
umask 077 exec script -q -a "/var/log/sessions/$USER-`date +%Y%m%d`"
Wenn Sie auswerten wollen, was die Benutzer in die Shell eingeben (aber nicht
was das Ergebnis ist), können Sie eine systemweite /etc/profile
so einrichten, dass alle Befehle in einer Chronikdatei gespeichert werden. Die
systemweite Einstellung muss so eingerichtet werden, dass Benutzer die
Überwachungsfähigkeit nicht aus ihrer Shell entfernen können. Ob dies
möglich ist, hängt von der Art der Shell ab. Sie müssen also sicherstellen,
dass alle Benutzer eine Shell verwenden, die das unterstützt.
Für die Bash zum Beispiel könnte /etc/profile
folgendermaßen
aufgebaut werden [32]:
HISTFILE=~/.bash_history HISTSIZE=10000 HISTFILESIZE=999999 # Verhindert, dass Benutzer Befehle eintragen, # die in die Verlaufsdatei ignoriert werden HISTIGNORE="" HISTCONTROL="" readonly HISTFILE readonly HISTSIZE readonly HISTFILESIZE readonly HISTIGNORE readonly HISTCONTROL export HISTFILE HISTSIZE HISTFILESIZE HISTIGNORE HISTCONTROL
Damit dies funktioniert, dürfen die Benutzer nur Informationen zur
.bash_history
-Datei hinzufügen. Sie müssen daher
zusätzlich die Option append-only (nur anfügen) mittels des
Programms Chattr
für die .bash_history
aller
Benutzer setzen [33].
Note that you could introduce the configuration above in the user's
.profile
. But then you would need to setup permissions properly
in such a way that prevents the user from modifying this file. This includes:
having the user's home directories not belong to the user (since the
user would be able to remove the file otherwise) but at the same time allow the
user to read the .profile
configuration file and write on the
.bash_history
. It would be good to set the immutable
flag (also using chattr
) for .profile
too if you do
it this way.
Die vorherigen Beispiele stellen eine einfache Art dar, um die Überwachung von
Benutzern einzurichten. Sie eignen sich aber nicht unbedingt für komplexe
Systeme oder für solche, auf denen die Benutzer überhaupt keine (oder
ausschließlich) Shells am Laufen haben. Sollte dies der Fall sein, schauen
Sie sich das Paket acct
an, das Werkzeuge zur Auswertung
(accounting utilities) enthält. Diese werden alle Befehle, die ein Benutzer
oder ein Prozess auf dem System ausführt, – auf die Kosten von
Plattenplatz – aufzeichnen.
Wenn Sie diese Auswertung aktivieren, werden alle Informationen über Prozesse
und Benutzer unter /var/account/
gespeichert, genauer gesagt in
pacct
. Das Accounting-Paket enthält einige Werkzeuge
(Sa
, Ac
und Lastcomm
) zur Analyse dieser
Daten.
Wenn Sie wirklich paranoid sind und jeden Befehl jedes Benutzers protokollieren
wollen, können Sie den Quellcode der Bash
so ändern, dass sie
alles, was der Benutzer eingibt, in einer anderen Datei ablegt. Oder Sie
lassen Ttysnoop
ununterbrochen jedes neue tty[34] überwachen und die Ausgaben
in einer Datei speichern. Ein anderes nützliches Programm ist
snoopy
(vergleichen Sie auch the project
page
). Dies ist ein für den Benutzer transparentes Programm, das
sich als eine Bibliothek einhängt und eine Hülle um
execve()-Aufrufe bildet. Jeder ausgeführte Befehl wird im
syslogd
aufgezeichnet, indem die
authpriv-Möglichkeit benutzt wird (üblicherweise wird dies unter
/var/log/auth.log
gespeichert).
Wenn Sie sehen wollen, was Benutzer tatsächlich tun, wenn sie sich am
System anmelden, können Sie die wtmp
-Datenbank benutzen, die alle
Anmeldeinformationen enthält. Diese Datei kann mit verschiedenen Werkzeugen
weiterverarbeitet werden, unter ihnen Sac
, das ein Profil für
jeden Benutzer ausgeben kann und zeigt, in welchem Zeitfenster sie sich für
gewöhnlich auf dem System anmelden.
Für den Fall, dass Sie Accounting aktiviert haben, können Sie auch die mitgelieferten Werkzeuge verwenden, um festzustellen, wann Benutzer auf das System zugreifen und was sie ausführen.
Abhängig von Ihren Benutzerrichtlinien möchten Sie ändern, wie Benutzer Informationen gemeinsam benutzen können. Dabei geht es um die Standardrechte von neu erstellten Dateien.
Das Standardwert von Umask ist in Debian 022. Das
bedeutet, dass die Gruppe des Benutzers und alle anderen Benutzers auf dem
System die Dateien (und Verzeichnisse) lesen und darauf zugreifen kann. Dieser
Wert wird in der Standardkonfigurationsdatei /etc/profile
gesetzt,
die von allen Shells verwendet wird.
If Debian's default value is too permissive for your system you will have to change the umask setting for all the shells. More restrictive umask settings include 027 (no access is allowed to new files for the other group, i.e. to other users in the system) or 077 (no access is allowed to new files to the members the user's group). Debian (by default[35]) creates one group per user so that only the user is included in its group. Consequently 027 and 077 are equivalent as the user's group contains only the user.
Dies ändern Sie, indem Sie eine passende Umask für alle Benutzer
einstellen. Dazu müssen Sie einen umask
-Aufruf in den
Konfigurationsdateien aller Shells einfügen: /etc/profile
(wird
von allen Shells beachtet, die kompatibel mit Bourne sind),
/etc/csh.cshrc
, /etc/csh.login
,
/etc/zshrc
und wahrscheinlich noch ein paar andere (je nachdem,
welche Shells Sie auf Ihrem System installiert haben). Sie können auch die
UMASK-Einstellung in /etc/login.defs
verändern. Von
all diesen Dateien erlangt die letzte, die von der Shell geladen wird, Vorrang.
Die Reihenfolge lautet: die Standard-Systemkonfiguration für die Shell des
Benutzers (d.h. /etc/profile
und andere systemweite
Konfigurationsdateien), dann die Shell des Benutzers (seine
~/.profile
) und ~/.bash_profile
etc.). Allerdings
können einige Shells mit dem nologin-Wert ausgeführt werden, was
verhindern kann, dass einige dieser Dateien ausgewertet werden. Sehen Sie in
der Handbuchseite Ihrer Shell für weitere Informationen nach.
Bei Anmeldungen, die von Login
Gebrauch machen, erhält die
UMASK-Festlegung in /etc/login.defs
Vorrang vor allen anderen
Einstellungen. Dieser Wert wird aber nicht von Anwendungen des Benutzers
beachtet, die nicht Login
verwenden, wie z.B. solche, die durch
Su
, Cron
oder Ssh
ausgeführt werden.
Vergessen Sie nicht, die Dateien unter /etc/skel/
zu überprüfen
und gegebenenfalls anzupassen, da dort die Standards für Benutzer festgelegt
werden, die mit dem Befehl adduser
erstellt werden.
Standardmäßig enthalten die Dateien in Debian keinen Aufruf von
umask
. Wenn sich aber ein solcher in Konfigurationsdateien
befindet, sind neue Benutzer eher geneigt, ihn ihren Bedürfnissen anzupassen.
Beachten Sie allerdings, dass ein Benutzer seine Umask-Einstellung ändern kann, wenn er es möchte, um sie großzügiger oder einschränkender zu machen, indem er seine Konfigurationsdateien verändert.
Das Paket libpam-umask
passt die Standard-Umask eines
Benutzers mit Hilfe von PAM an. Nachdem Sie das Paket installiert haben,
tragen Sie Folgendes in /etc/pam.d/common-session
ein:
session optional pam_umask.so umask=077
Zu guter Letzt sollte Sie in Betracht ziehen, die Standard-Umask von Root (022,
wird in /root/.bashrc
festgelegt) auf einen strengeren Wert zu
verändern. Damit kann verhindert werden, dass der Systemadministrator als
Root sensible Dateien in von allen lesbaren Verzeichnissen (wie z.B.
/tmp
) ablegt und sie so dem Durchschnittsbenutzer zugänglich
macht.
FIXME: Inhalt benötigt. Aufzeigen der Folgen beim Upgraden, wenn die
Paketrechte verändert werden, falls nicht dpkg-statoverride
verwendet wird (übrigens sollte ein derartig paranoider Administrator seine
Benutzer in eine Chroot
-Umgebung einsperren).
Wenn Sie einem Benutzer Zugriff auf das System mit einer Shell gewähren müssen, sollten Sie vorsichtig sein. Ein Benutzer kann normalerweise, wenn er sich nicht in einer streng abgeschirmten Umgebung befindet (z.B. in einem Chroot-Gefängnis), ziemlich viel Informationen über Ihr System sammeln. Darunter fallen:
Einige Konfigurationsdateien unter /etc
. Jedoch werden Debians
Standardrechte für sensible Dateien (die zum Beispiel Passwörter enthalten
könnten) den Zugriff auf kritische Informationen verhindern. Um zu sehen, auf
welche Dateien nur der Root-Benutzer zugreifen kann, führen Sie zum Beispiel
find /etc -type f -a -perm 600 -a -uid 0 als Superuser aus.
Ihre installierten Pakete. Indem entweder die Paketdatenbank und das
Verzeichnis /usr/share/doc/
angesehen wird oder indem versucht
wird, dies durch Anschauen der auf Ihrem System installierten Programme und
Bibliotheken zu raten.
Einige Protokolle unter /var/log
. Beachten Sie, dass auf einige
Protokolle nur Root und die adm-Gruppe zugreifen kann (versuchen
Sie find /var/log -type f -a -perm 640). Manche sind sogar
ausschließlich für Root verfügbar (sehen Sie sich find /var/log -type
f -a -perm 600 -a -uid 0 an).
Was kann ein Benutzer von Ihrem System sehen? Wahrscheinlich ziemlich viele Sachen, versuchen Sie mal Folgendes (und jetzt tief durchatmen):
find / -type f -a -perm +006 2>/dev/null find / -type d -a -perm +007 2>/dev/null
The output is the list of files that a user can see and the accessable directories.
Wenn Sie immer noch Benutzern einen Shellzugang zur Verfügung stellen wollen, sollten Sie die Informationen begrenzen, die man über anderen Benutzern einholen kann. Benutzer mit einer Shell haben die Neigung, eine ziemlich große Anzahl von Dateien in ihrem $HOME zu erstellen: Mailboxen, persönliche Daten, Konfigurationen für X/GNOME/KDE-Anwendungen ...
Unter Debian wird jeder Benutzer mit einer zugehörigen Gruppe erstellt. Verschiedene Benutzer gehören dabei nie zur selben Gruppe. Folgendes ist das Standardverhalten: Wenn ein Benutzerkonto angelegt wird, wird auch eine Gruppe mit dem gleichen Namen erstellt. Dieser Gruppe wird der Benutzer zugewiesen. Damit wird die Idee einer allgemeinen users-Gruppe überflüssig, die es Benutzern erschweren könnte, Informationen vor anderen Benutzern zu verstecken.
Allerdings wird das $HOME-Verzeichnis der Benutzer mit 0755-Rechten (lesbar von der Gruppe, lesbar von der Welt) erstellt. Die Rechte für die Gruppe sind kein Thema, da nur der Benutzer zu dieser Gruppe gehört. Allerdings könnten die Rechte für die Welt ein Problem darstellen, wobei dies von Ihren lokalen Richtlinien abhängt.
Sie können dieses Verhalten so abändern, dass das Erstellen eines Benutzers
andere Rechte für $HOME liefert. Um dieses Verhalten für
neue Benutzer zu ändern, wenn sie erstellt werden, ändern Sie in der
Konfigurationsdatei /etc/adduser.conf
DIR_MODE auf 0750
(nicht lesbar für die Welt) ab.
Benutzer können immer noch Informationen austauschen, aber nicht mehr unmittelbar in ihrem $HOME-Verzeichnis, es sei denn, dass sie dessen Recht verändert haben.
Wenn Sie den Lesezugriff auf die Home-Verzeichnisse für die Welt verhindert,
sollten Sie beachten, dass dann Benutzer ihre persönlichen Webseiten nicht
unter ~/public_html
erstellen können, da der Webserver einen Teil
des Pfads nicht lesen kann – und zwar das $HOME-Verzeichnis.
Wenn Sie es Benutzern erlauben wollen, ihre HTML-Seiten in ihrem
~/public_html
zu veröffentlichen, sollten Sie DIR_MODE
auf 0751 setzen. Das ermöglicht dem Webserver Zugriff auf das eigentliche
public_html
-Verzeichnis (welches selbst die Rechte 0755 haben
sollte). So kann er den von den Benutzern veröffentlichten Inhalt anbieten.
Natürlich sprechen wir hier nur über die Standardeinstellung. Benutzer
können grundsätzlich die Rechte für ihre eigenen Dateien nach ihrem
Gutdünken vergeben. Oder Sie können die Dinge, die für das Web bestimmt
sind, in einem getrennten Ort ablegen, der kein Unterverzeichnis vom
$HOME-Verzeichnis des Benutzers ist.
In vielen Fällen muss ein Administrator viele Benutzerkonten erstellen und
alle mit Passwörtern ausstatten. Der Administrator könnte natürlich einfach
als Passwort den Namen des Benutzerkontos vergeben. Dies wäre aber unter
Sicherheitsgesichtspunkten nicht sehr klug. Ein besseres Vorgehen ist es, ein
Programm zur Erzeugung von Passwörtern zu verwenden. Debian stellt die Pakete
makepasswd
, apg
und pwgen
zur
Verfügung, die Programme liefern (deren Name ist der gleiche wie der des
Pakets), die zu diesem Zweck verwendet werden können. Makepasswd
erzeugt wirklich zufällige Passwörter, gibt also der Sicherheit gegenüber
der Aussprechbarkeit den Vorzug. Dagegen versucht pwgen
,
bedeutungslose, aber aussprechbare Passwörter herzustellen (dies hängt
natürlich auch von Ihrer Muttersprache ab). Apg
liefert
Algorithmen für beide Möglichkeiten (Es gibt auch eine Client/Server-Version
dieses Programms. Diese befindet sich aber nicht im Debian-Paket).
Passwd
erlaubt nur die interaktive Zuweisung von Passwörtern (da
es direkt den tty-Zugang benutzt). Wenn Sie Passwörter ändern wollen, wenn
Sie eine große Anzahl von Benutzern erstellen, können Sie diese unter der
Verwendung von adduser
mit der
--disabled-login-Option erstellen, und danach usermod
oder chpasswd
[36]
benutzen (beide Programme stammen aus dem passwd
-Paket. Sie haben
sie also schon installiert). Wenn Sie lieber eine Datei verwenden, die alle
Informationen zur Erstellung von Benutzern als Batch-Prozess enthält, sind Sie
vielleicht mit newusers
besser dran.
Die Passwörter der Benutzer sind manchmal die schwächste Stelle der
Sicherheit eines Systems. Das liegt daran, dass manche Benutzer schwache
Passwörter für ihr Konto wählen (und je mehr Benutzer Zugang zum System
haben, umso größer die Chance, dass das passiert). Selbst wenn Sie
Überprüfungen mit dem PAM-Module cracklib und Grenzen für Passwörter
einsetzen, wie in Benutzerauthentifizierung: PAM,
Abschnitt 4.11.1 beschrieben wird, ist es Benutzern immer noch möglich,
schwache Passwörter zu verwenden. Da der Zugang der Benutzer auch den Zugang
aus der Ferne (hoffentlich über Ssh
) umfassen kann, ist es
wichtig, dass das Erraten von Passwörtern für Angreifer aus der Ferne so
schwierig wie möglich ist. Dies gilt insbesondere dann, wenn es ihnen
gelungen sein sollte, Zugriff auf wichtigen Informationen wie den Benutzernamen
oder sogar den Dateien passwd
und shadow
selbst zu
bekommen.
A system administrator must, given a big number of users, check if the
passwords they have are consistent with the local security policy. How to
check? Try to crack them as an attacker would if having access to the hashed
passwords (the /etc/shadow
file).
Ein Administrator kann john
oder crack
(beide
benutzen Brute-Force (rohe Gewalt) zum Knacken von Passwörtern) zusammen mit
einer passenden Wörterliste verwenden, um die Passwörter der Benutzer zu
überprüfen, und falls ein schlechtes Passwort entdeckt wird, geeignete
Schritte unternehmen. Sie können mit apt-cache search wordlist
nach Debian/GNU-Paketen suchen, die Wörterlisten enthalten, oder Sie besuchen
die klassischen Internetseiten mit Wörterlisten wie ftp://ftp.ox.ac.uk/pub/wordlists
oder ftp://ftp.cerias.purdue.edu/pub/dict
.
Untätige (idle) Benutzer stellen für gewöhnlich ein Sicherheitsproblem dar. Ein Benutzer kann untätig sein, da er Mittagessen ist, oder weil eine Verbindung aus der Ferne hängen blieb und nicht wieder hergestellt wurde. Unabhängig von den Gründen können untätige Benutzer zu einer Kompromittierung führen:
weil die Konsole des Benutzers vielleicht nicht verriegelt ist und damit ein Eindringling darauf zugreifen kann.
because an attacker might be able to re-attach to a closed network connection
and send commands to the remote shell (this is fairly easy if the remote shell
is not encrypted as in the case of telnet
).
In einige Systeme in der Ferne wurde sogar schon durch ein untätiges (und
abgelöstes) Screen
eingedrungen.
Die automatische Trennung von untätigen Benutzern ist gewöhnlich ein Teil der lokalen Sicherheitsrichtlinie, die durchgesetzt werden muss. Es gibt mehrere Arten, dies zu erreichen:
Wenn die Shell des Benutzers die Bash
ist, kann ein
Systemadministrator TMOUT einen Standardwert zuweisen (vergleich
bash(1)
). Das hat zur Folge, dass die Shell automatisch untätige
Benutzer aus der Ferne abmeldet. Beachten Sie, dass der Wert mit der Option
-o gesetzt werden muss. Ansonsten ist es den Benutzern möglich,
ihn zu verändern (oder zu löschen).
Installieren Sie Timeoutd
und konfigurieren Sie
/etc/timeouts
passend zu Ihren lokalen Sicherheitsrichtlinien.
Der Daemon achtet auf untätige Benutzer und beendet entsprechend ihre Shells.
Installieren Sie Autolog
und richten Sie es so ein, dass es
untätige Benutzer entfernt.
Vorzugswürdige Methoden sind die Daemonen Timeoutd
oder
Autolog
, da letzten Endes die Benutzer ihre Standardshell ändern
können oder zu einer anderen (unbeschränkten) Shell wechseln können, nachdem
sie ihre Standardshell gestartet haben.
TCP-Wrapper (Schutzumschläge für TCP) wurden entwickelt, als es noch keine
echten Paketfilter gab, aber Zugangskontrollen notwendig waren. Trotzdem sind
sie immer noch hoch interessant und nützlich. Ein TCP-Wrapper erlaubt Ihnen,
einem Host oder einer Domain einen Dienst anzubieten oder zu verweigern, und
standardmäßig Zugriff zu erlauben oder zu verweigern (das alles wird auf der
Anwendungsebene durchgeführt). Wenn Sie mehr Informationen haben möchten,
sehen Sie sich hosts_access(5)
an.
Viele der unter Debian installierten Dienste
werden entweder durch den TCP-Wrapper Service (tcpd
) aufgerufen,
oder wurden mit Unterstützung für libwrapper (Bibliothek für TCP-Wrapper) kompiliert.
Einerseits werden Sie bei manchen Diensten (einschließlich
telnet
, ftp
, netbios
, swat
und finger
), die in /etc/inetd.conf
konfiguriert
werden, sehen, dass die Konfigurationsdatei zuerst /usr/sbin/tcpd
aufruft. Andererseits, selbst wenn ein Dienst nicht über den
inetd
-Superdaemon ausgeführt wird, kann die Unterstützung von
TCP-Wrapper einkompiliert werden. Dienste, die unter Debian mit TCP-Wrappern
kompiliert wurden, sind ssh
, portmap
,
in.talk
, rpc.statd
, rpc.mountd
,
gdm
, oaf
(der GNOME-Aktivierungs-Daemon),
nessus
und viele andere.
Um herauszufinden, welche Pakete TCP-Wrapper benutzen[37], geben Sie Folgendes ein:
$ apt-cache rdepends libwrap0
Beachten Sie bitte Folgendes, wenn Sie tcpchk
(ein sehr
nützliches Programm zur Überprüfung der TCP-Wrapper-Konfiguration und
-Syntax) laufen lassen. Wenn Sie Stand-Alone-Dienste (alleinstehende Dienste,
also solche, die direkt mit der Wrapper-Bibliothek verbunden sind) der
host.deny
- oder host.allow
-Datei hinzufügen, wird
tcpchk
Sie warnen, dass er sie nicht finden kann, da er sie nur in
/etc/inetd.conf
sucht (die Handbuchseite ist an dieser Stelle
nicht sehr genau).
Jetzt kommt ein kleiner Trick und vielleicht die kleinste Alarmanlage zur
Erkennung von Eindringlingen: Im Allgemeinen sollten Sie eine anständige
Firewall als erste und TCP-Wrapper als zweite Verteidigungslinie haben. Der
Trick besteht nun darin, ein SPAWN-Kommando [38] in
/etc/hosts.deny
einzutragen, das immer dann eine Mail an Root
schickt, wenn ein Dienst abgewiesen wurde:
ALL: ALL: SPAWN ( \ echo -e "\n\ TCP Wrappers\: Verbindungsaufbau abgelehnt\n\ Von\: $(uname -n)\n\ Prozess\: %d (pid %p)\n\ Benutzer\: %u\n\ Host\: %c\n\ Datum\: $(date)\n\ " | /usr/bin/mail -s "Verbindung zu %d blockiert" root) &
Achtung: Das obige Beispiel kann sehr leicht zu DoS (Denial of Service, Verbindungsaufbau abgelehnt) führen, indem man versucht, sehr viele Verbindungen in kurzer Zeit aufzubauen. Viele E-Mails bedeuten viel Dateiaktivität, die lediglich durch das Senden von ein paar Paketen erreicht wird.
Es ist leicht einzusehen, dass die Behandlung von Protokollen und Alarmen eine wichtige Angelegenheit in einem sicheren System ist. Stellen Sie sich vor, ein System ist perfekt konfiguriert und zu 99% sicher. Wenn ein Angriff unter dieses 1% fällt, und es keine Sicherheitsmaßnahmen gibt, dies erstens zu erkennen und zweitens einen Alarm auszulösen, so ist das System überhaupt nicht sicher.
Debian GNU/Linux stellt Werkzeuge zur Verfügung, die die Analyse von
Protokolldateien übernehmen. Am beachtenswertesten sind swatch
[39], logcheck
oder loganalysis
(alle Pakete werden ein wenig Anpassung
benötigen, um unnötige Dinge aus den Berichten zu entfernen). Wenn sich das
System in Ihrer Nähe befindet, könnte es nützlich sein, das System-Protokoll
auf einer virtuellen Konsole auszugeben. Die ist nützlich, da Sie so (auch
von weiter weg oder im Vorbeigehen) sehen können, ob sich das System richtig
verhält. Debians /etc/syslog.conf
wird mit einer
auskommentierten Standardkonfiguration ausgeliefert. Um diese Ausgabe
einzuschalten, entfernen Sie die Kommentarzeichen vor den entsprechenden Zeilen
und starten syslog
neu (/etc/init.d/syslogd restart):
daemon,mail.*;\ news.=crit;news.=err;news.=notice;\ *.=debug;*.=info;\ *.=notice;*.=warn /dev/tty8
Um die Protokolle farbig zu gestalten, sollten Sie einen Blick auf
colorize
, ccze
oder glark
werfen. Es
gibt noch eine Menge über die Analyse von Protokollen zu sagen, das hier nicht
behandelt werden kann. Eine gute Quelle für weitere Informationen sind
Bücher wie Security log management:
identifying patterns in the chaos
. In jedem Fall sind selbst
automatische Werkzeuge dem besten Analysewerkzeug nicht gewachsen: Ihrem
Gehirn.
logcheck
Das Paket logcheck
ist in Debian auf drei Pakete verteilt:
logcheck
(das Hauptprogramm), logcheck-database
(eine
Datenbank regulärer Ausdrücke für das Programm) und logtail
(gibt Protokollzeilen aus, die noch nicht gelesen wurden). Der Standard unter
Debian (in /etc/cron.d/logcheck
) ist, dass logcheck
jede Stunde und nach jedem Neustart ausgeführt wird.
Wenn dieses Werkzeug in geeigneter Weise angepasst wurde, kann es sehr
nützlich sein, um den Administrator zu alarmieren, wenn etwas ungewöhnliches
auf dem System passiert. Logcheck
kann vollständig angepasst
werden, so dass es Mails über Ereignisse aus den Protokollen sendet, die Ihrer
Aufmerksamkeit bedürfen. Die Standard-Installation umfasst Profile zum
Ignorieren von Ereignissen und Verstößen gegen die Sicherheitsrichtlinie für
drei unterschiedliche Einsatzbereiche (Workstation, Server und paranoid). Das
Debian-Paket umfasst die Konfigurationsdatei
/etc/logcheck/logcheck.conf
, die vom Programm eingelesen wird, und
die definiert, an welchen Benutzer die Testergebnisse geschickt werden sollen.
Es stellt außerdem einen Weg für Pakete zur Verfügung, um neue Regeln in
folgenden Verzeichnisses zu erstellen:
/etc/logcheck/cracking.d/_packagename_
/etc/logcheck/violations.d/_packagename_
,
/etc/logcheck/violations.ignore.d/_packagename_
,
/etc/logcheck/ignore.d.paranoid/_packagename_
,
/etc/logcheck/ignore.d.server/_packagename_
, und
/etc/logcheck/ignore.d.workstation/_packagename_
. Leider benutzen
das noch nicht viele Pakete. Wenn Sie ein Regelwerk entwickelt haben, dass
für andere Benutzer nützlich sein könnte, schicken Sie bitte einen
Fehlerbericht für das entsprechende Paket (als ein wishlist-Fehler).
Mehr Informationen finden Sie unter
/usr/share/doc/logcheck/README.Debian
.
logcheck
konfiguriert man am besten, indem man nach der
Installation die Hauptkonfigurationsdatei
/etc/logcheck/logcheck.conf
bearbeitet. Verändern Sie den
Benutzer, an den die Berichte geschickt werden (standardmäßig ist das Root).
Außerdem sollten Sie auch den Schwellenwert für Berichte festlegen.
logcheck-database
hat drei Schwellenwerte mit steigender
Ausführlichkeit: Workstation (Arbeitsplatz), Server und paranoid. »server«
ist der Standardwert, »paranoid« wird nur für Hochsicherheitsmaschinen
empfohlen, auf denen so wenig Dienste wie möglich laufen. »workstation«
eignet sich für relativ geschützte, nicht kritische Maschinen. Wenn Sie neue
Protokoll-Dateien hinzufügen wollen, müssen Sie diese nur zu
/etc/logcheck/logcheck.logfiles
hinzufügen. Es ist für die
standardmäßige Syslog-Installation eingerichtet.
Wenn Sie dies geschafft haben, sollten Sie die nächsten Tage/Wochen/Monate die
verschickten Mails überprüfen. Falls Sie Nachrichten finden, die Sie nicht
erhalten wollen, fügen Sie die regulären Ausdrücke (regular expressions,
vergleiche regex(7)
und egrep(1)
), die zu diesen
Nachrichten passen, in
/etc/logcheck/ignore.d.reportlevel/local
ein.
Versuchen Sie, dass der reguläre Ausdruck mit der gesamten Protokollzeile
übereinstimmt. Details, wie man Regeln schreibt, finden Sie in
/usr/share/doc/logcheck-database/README.logcheck-database.gz
. Das
ist ein andauernder Prozess der Abstimmung. Wenn nur noch relevante Meldungen
verschickt werden, können Sie davon ausgehen, dass dieser Prozess beendet ist.
Beachten Sie, dass logcheck
, selbst wenn er läuft, Ihnen keine
Mail schickt, wenn er nichts Relevantes auf Ihrem System findet (so bekommen
Sie höchstens eine Mail pro Woche, wenn Sie Glück haben).
Debian wird mit einer Standardkonfiguration für Syslog (in
/etc/syslog.conf
) ausgeliefert, so dass Meldungen je nach System
in die passenden Dateien geschrieben werden. Das sollte Ihnen bereits bekannt
sein. Falls nicht, werfen Sie einen Blick auf die Datei
syslog.conf
und deren Dokumentation. Wenn Sie ein sicheres System
betreuen wollen, sollte Ihnen bekannt sein, wohin Protokoll-Meldungen geschickt
werden, so dass sie nicht unbeachtet bleiben.
Zum Beispiel ist es für viele Produktiv-Systeme sinnvoll, Meldungen auch auf der Konsole auszugeben. Aber bei vielen solcher Systeme ist es wichtig, eine neue Maschine zu haben, die für die anderen als ein Loghost fungiert (d.h. sie empfängt die Protokolle aller anderen Systeme).
Sie sollten auch an Mails für Root denken, da viele Programme zur
Sicherheitskontrolle (wie snort
) ihre Alarme an die Mailbox von
Root senden. Diese Mailbox zeigt normalerweise auf den ersten Benutzer, der
auf dem System erstellt wurde (prüfen Sie dazu /etc/aliases
).
Sorgen Sie dafür, dass Roots Mails irgendwo hin geschickt werden, wo sie auch
gelesen werden (lokal oder in der Ferne).
Es gibt noch andere Konten mit besonderen Funktionen und andere Aliase auf Ihrem System. Auf einem kleinen System ist es wohl am einfachsten, sicherzustellen, dass alle Aliase auf das Root-Konto verweisen, und dass Mails an Root in das persönliche Postfach des Systemadministrators weiter geleitet werden.
FIXME: It would be interesting to tell how a Debian system can send/receive
SNMP traps related to security problems (jfs). Check:
snmptrapfmt
, snmp
and snmpd
.
A loghost is a host which collects syslog data remotely over the network. If
one of your machines is cracked, the intruder is not able to cover the tracks,
unless hacking the loghost as well. So, the loghost should be especially
secure. Making a machine a loghost is simple. Just start the
syslogd
with syslogd -r and a new loghost is born.
In order to do this permanently in Debian, edit
/etc/default/syslogd
and change the line
SYSLOGD=""
in
SYSLOGD="-r"
Als nächstes konfigurieren Sie die anderen Maschinen, so dass sie ihre Daten
an den Loghost zu senden. Fügen Sie einen Eintrag, ähnlich dem Folgenden, zu
der /etc/syslog.conf
hinzu:
facility.level @Ihr_Loghost
Schauen Sie in die Dokumentation, um zu erfahren, wodurch Sie facility und level ersetzen können; sie sollten nicht wörtlich übernommen werden. Wenn Sie alles in der Ferne mitprotokollieren wollen, schreiben Sie einfach:
*.* @Ihr_Loghost
in Ihre syslog.conf
. Sowohl lokal als auch aus der Ferne
mitzuprotokollieren, ist die beste Lösung (ein Angreifer könnte davon
ausgehen, dass er seine Spuren verwischt hat, nachdem er die lokale Log-Datei
gelöscht hat). Für weitere Informationen sehen Sie sich die Handbuchseiten
syslog(3)
, syslogd(8)
und syslog.conf(5)
an.
It is not only important to decide how alerts are used, but also who has read/modify access to the log files (if not using a remote loghost). Security alerts which the attacker can change or disable are not worth much in the event of an intrusion. Also, you have to take into account that log files might reveal quite a lot of information about your system to an intruder who has access to them.
Einige Zugriffsrechte auf Protokolldateien sind nach der Installation nicht
gerade perfekt (aber das hängt natürlich von Ihrer lokalen
Sicherheitsrichtlinie ab). Zuerst einmal müssen /var/log/lastlog
und /var/log/faillog
nicht für normale Benutzer lesbar sein. In
der Datei lastlog
können Sie sehen, wer sich zuletzt angemeldet
hat. In faillog
befindet sich eine Zusammenfassung
fehlgeschlagener Anmeldeversuche. Der Autor empfiehlt, die Rechte von beiden
auf 660 zu setzen (mit chmod 660
). Werfen Sie einen kurzen Blick
auf Ihre Protokolldateien und entscheiden Sie sehr vorsichtig, welche
Protokolldateien Sie les- oder schreibbar für einen Benutzer mit einer anderen
UID als 0 und einer anderen Gruppe als »adm« oder »root« machen. Sie
können dies sehr leicht auf Ihrem System überprüfen:
# find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u (überprüfen, welchen Benutzern die Dateien unter /var/log gehören) # find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u (überprüfen, welchen Gruppen die Dateien unter /var/log gehören) # find /var/log -perm +004 (Dateien, die von jedem Benutzer gelesen werden können) # find /var/log \! -group root \! -group adm -exec ls -ld {} \; (Dateien, die nicht der Gruppe root oder adm gehören)
Um anzupassen, wie neue Protokolldateien erstellt werden, müssen Sie wahrscheinlich das Programm anpassen, das sie erstellt. Wenn die Protokolldateien ausgewechselt werden, können Sie das Verhalten der Erstellung und Auswechslung anpassen.
Debian GNU/Linux stellt verschiedene Patches für den Linux-Kernel zur Verfügung, welche die Sicherheit erhöhen:
Erkennung von Eindringlingen für Linux (Linux Intrusion Detection
, enthalten im
Paket lids-2.2.19
). Dieser Kernelpatch erleichtert Ihnen, Ihr
Linuxsystem abzuhärten, indem er Ihnen ermöglicht, Prozesse einzuschränken,
zu verstecken und zu schützten, sogar vor Root. Er führt Fähigkeiten für
eine zwingende Zugangskontrolle ein.
Linux Trustees
(im
Paket trustees
). Dieser Patch fügt ein ordentliches,
fortgeschrittenes Rechtemanagement Ihrem Linux-Kernel hinzu. Besondere
Objekte, die »trustees« (Treuhänder) genannt werden, sind mit jeder Datei
oder Verzeichnis verbunden. Sie werden im Speicher des Kernels abgelegt und
erlauben so eine schnelle Abfrage aller Rechte.
NSA Enhanced Linux (im Paket selinux
. Backports von Paketen, die
SELinux unterstützen, sind unter http://selinux.alioth.debian.org/
erhältlich. Weiterführende Informationen können Sie auf der SELinux in Debian Wiki Seite
und auf Manoj
Srivastavas
und Russell Cookers'
SELinux-Webseiten finden.
Der Exec-Shield-Patch
aus dem Paket kernel-patch-exec-shield
. Dieser Patch schützt vor
einigen Pufferüberläufen (stack smashing attacks).
Der Grsecurity-Patch
aus
den Paketen kernel-patch-2.4-grsecurity
und
kernel-patch-grsecurity2
[40] verwirklicht Mandatory Access Control durch RBAC und stellt
Schutz vor Pufferüberläufen durch PaX, ACLs, Zufälligkeit im Netzwerk (um
die Erkennung von Spuren des OS zu erschweren) und noch viele Features
mehr
zur Verfügung.
kernel-patch-adamantix
bietet die Patches an, die für die
Debian-Distribution Adamantix
entwickelt wurden.
Dieser Patch für den Kernel 2.4.x führt einige Sicherheitsfähigkeiten wie
nichtausführbaren Speicher durch den Einsatz von PaX
und Mandatory Access
Control auf Grundlage von RSBAC
ein. Andere Features sind
der
Random-PID-Patch
, ein mit AES verschlüsseltes Loop-Gerät,
Unterstützung von MPPE und eine Zurückportierung von IPSEC v2.6.
cryptoloop-source
: Dieser Patch erlaubt Ihnen, die Fähigkeiten
der Crypto-API des Kernels zu verwenden, um verschlüsselte Dateisysteme mit
dem Loopback-Gerät zu erstellen.
Kernel-Unterstützung von IPSEC (im Paket kernel-patch-openswan
).
Wenn Sie das IPsec-Protokoll mit Linux verwenden wollen, benötigen Sie diesen
Patch. Damit können Sie ziemlich leicht VPNs erstellen, sogar mit
Windows-Rechnern, da IPsec ein verbreiteter Standard ist. IPsec-Fähigkeiten
wurden in den Entwicklungskernel 2.5 eingefügt, so dass dieses Feature
standardmäßig im zukünftigen Kernel 2.6 enthalten sein wird. Homepage:
http://www.openswan.org
.
FIXME: Der neuste Kernel 2.4 in Debian enthält eine Rückeinbindung
des IPSEC-Codes aus 2.5. Kommentar dazu.
Die folgenden Sicherheitspatches für den Kernel sind nur noch für alte Kernelversionen in Woody verfügbar und werden nicht mehr weiterentwickelt:
POSIX Access Control Lists
(ACLs, Listen zur Zugangskontrolle) für Linux im Paket
kernel-patch-acl
. Dieser Kernelpatch stellt Listen zur
Zugangskontrolle zur Verfügung. Das ist eine fortgeschrittene Methode, um den
Zugang zu Dateien einzuschränken. Es ermöglicht Ihnen, den Zugang zu Dateien
und Verzeichnisses fein abzustimmen.
Der Patch für den Linux-Kernel Openwall
von Solar Designer,
der im Paket kernel-patch-2.2.18-openwall
enthalten ist. Er
enthält eine nützliche Anzahl von Beschränkungen des Kernels wie
eingeschränkte Verweise, FIFOs in /tmp
, ein begrenztes
/proc
-Dateisystem, besondere Handhabung von Dateideskriptoren,
einen nichtausführbaren Bereich des Stapelspeichers des Benutzers und andere
Fähigkeiten. Hinweis: Dieser Patch ist nur auf die Kernelversion 2.2
anwendbar, für 2.4 werden von Solar keine Pakete angeboten.
kernel-patch-int
. Auch dieser Patch fügt kryptografische
Fähigkeiten zum Linux-Kernel hinzu. Er war bis zu den Debian-Releases bis
Potato nützlich. Er funktioniert nicht mehr mit Woody. Falls Sie Sarge oder
eine neuere Version verwenden, sollten Sie einen aktuelleren Kernel einsetzen,
in dem diese Features bereits enthalten sind.
Wie auch immer, einige Patches werden von Debian noch nicht zur Verfügung
gestellt. Wenn Sie denken, dass manche von ihnen hinzugefügt werden sollten,
fragen Sie danach auf Arbeit-bedürfende und
voraussichtliche Pakete
.
Pufferüberlauf (buffer overflow) wird eine verbreitete Art von Angriffen auf Software [41] genannt, welche die unzureichende Überprüfung von Eingabegrenzen ausnutzen (ein Programmierfehler, der häufig bei der Programmiersprache C auftritt), um durch Programmeingaben Befehle auf der Maschine auszuführen. Diese Attacken über Server, die auf Verbindungen warten, oder über lokal installierte Software, die einem Benutzer größere Privilegien gewährt (setuid oder setgid) kann zu einem kompromittierten System führen.
Es gibt hauptsächlich vier Methoden, um sich gegen Pufferüberläufe zu schützen:
Patchen Sie den Kernel, um das Ausführen des Stapelspeichers zu verhindern. Sie können entweder Exec-Shield, OpenWall oder PaX (ist in den Grsecurity- und Adamantixpatches enthalten) verwenden.
Verbessern Sie den Quellcode, indem Sie Werkzeuge einsetzen, die Teile finden, die zu dieser Verwundbarkeit führen könnten.
Übersetzen Sie den Quellcode neu, um vernünftige Prüfungen einzuführen, um
Überläufe zu verhindern. Benutzen Sie dazu den Stack Smashing
Protector (SSP)
Patch für GCC (der von Adamantix
verwendet wird).
Debian GNU/Linux liefert bis einschließlich der Veröffentlichung 3.0
Software, um alle diese Methoden bis auf den Schutz bei der Übersetzung des
Quellcodes (das wurde aber schon in Fehler #213994
nachgefragt) zu
implementieren.
Beachten Sie, dass selbst wenn Debian einen Compiler zur Verfügung stellen würde, der Schutz vor Stapel- und Pufferüberläufen bieten würde, so doch alle Pakete neu übersetzt werden müssten, um diese Eigenschaft einzuführen. Tatsächlich ist das die Aufgabe der Distribution Adamantix (unter anderen Fähigkeiten). Die Auswirkungen dieses neuen Features auf die Stabilität der Software muss aber noch ermittelt werden (einige Programme und einige Prozessoren werden vielleicht deswegen nicht mehr funktionieren).
Seien Sie auf jeden Fall gewarnt, dass selbst diese Umgehungen des Problems
nicht vor Pufferüberläufen schützen können, da es Möglichkeiten gibt,
diese zu überlisten, wie in Ausgabe
58
des phrack-Magazins oder in COREs Advisory Multiple
vulnerabilities in stack smashing protection technologies
beschrieben.
Wenn Sie Ihren Schutz gegen Pufferüberläufe (unabhängig von der gewählten
Methode) testen wollen, können Sie paxtest
installieren und die
angebotenen Tests laufen lassen.
Ein Kernelpatch, der Schutz vor Pufferüberläufen bietet, ist der
Openwall-Patch, der diese im Linux-Kernel 2.2 verhindern soll. Für 2.4 oder
neuere Kernel müssen Sie die Umsetzung von Exec-Shield oder die von PaX (ist
im Grsecurity-Patch kernel-patch-2.4-grsecurity
und im
Adamantix-Patch kernel-patch-adamantix
enthalten) benutzen. Für
weitere Informationen zum Einsatz dieser Patches lesen Sie Den Kernel patchen, Abschnitt 4.14.
Zur Nutzung von Werkzeugen zum Aufspüren von Pufferüberläufen benötigen Sie
in jedem Fall Programmiererfahrung, um den Quellcode zu reparieren (und neu zu
kompilieren). Debian stellt beispielsweise bfbtester
(einen
Überlauftester, der Programme per Brute-Force (durch Testen aller
Möglichkeiten) nach Überläufen der Kommandozeile und von Umgebungsvariablen
durchtestet) bereit. Andere interessante Pakete sind auch rats
,
pscan
, flawfinder
und splint
.
Während der normalen Systemadministration müssen Sie immer mal wieder Dateien
auf Ihr System spielen oder von diesem holen. Auf sichere Art und Weise
Dateien von einem Host zu einem anderen zu kopieren, wird durch die Benutzung
des Paketes ssh
erreicht. Eine andere Möglichkeit ist die
Nutzung von ftpd-ssl
, einem ftp-Server der Secure Socket
Layer benutzt, um Übertragungen zu verschlüsseln.
Jede dieser Methoden benötigt natürlich einen speziellen Client. Debian
stellt Ihnen solche zur Verfügung, zum Beispiel enthält das Paket
ssh
das Programm scp
. Es arbeitet wie
rcp
, aber ist komplett verschlüsselt, so dass die bösen
Jungs noch nicht einmal herausbekommen können, WAS Sie kopieren. Passend
zu dem Server gibt es auch ein ftp-ssl
Client-Paket. Sie können
Clients für diese Software sogar für andere (nicht-UNIXoide) Betriebssysteme
finden. putty
und winscp
stellen eine
secure-copy-Implementierung für jede Version von Microsoft-Betriebssystemen
zur Verfügung.
Beachten Sie, dass die Verwendung von scp
den Benutzern Zugang zum
gesamten Dateisystem ermöglicht, es sei denn, dass es in eine
chroot
-Umgebung eingesperrt ist, wie es in SSH in ein Chroot-Gefängnis
einsperren, Abschnitt 5.1.1 beschrieben wird. Wahrscheinlich sogar
leichter (abhängig vom verwendeten Daemon) kann auch der FTP in eine
chroot
-Umgebung eingesperrt werden. Das wird in Absichern von FTP, Abschnitt
5.3 beschrieben. Falls Sie sich sorgen, dass Benutzer Ihre lokalen Dateien
durchsehen, und Sie verschlüsselte Kommunikation wünschen, können Sie einen
FTP-Daemon mit Unterstützung für SSL einrichten oder FTP mit Klartext und VPN
verbinden (siehe Virtual Private Networks
(virtuelle private Netzwerke), Abschnitt 8.5.
Es ist wichtig, eine gute Quota-Regelung zu haben, da es die Benutzer daran hindert, die Festplatten zu füllen.
Sie können zwei Arten von Quota-Systemen benutzen: Benutzer-Quota und Gruppen-Quota. Wie Sie sich sicher denken können, begrenzt ein User-Quota den Plattenplatz, den ein Benutzer belegen kann, und ein Gruppen-Quota macht dasselbe für Gruppen. Beachten Sie dies, wenn Sie die Größe der Quotas festlegen.
Es gibt ein paar wichtige Punkte, die Sie erwägen sollten, wenn Sie ein Quota-System aufsetzen:
Halten Sie die Quotas klein genug, so dass die Benutzer Ihren Festplattenplatz nicht aufzehren können.
Halten Sie die Quotas groß genug, so dass Benutzer sich nicht beschweren oder dass Ihr Mail-Quota Sie daran hindert, nach einer Weile Mails anzunehmen.
Nutzen Sie Quotas auf allen Bereichen, die Benutzer beschreiben können, auf
/home
ebenso wie auf /tmp
.
Für jede Partition und jedes Verzeichnis, auf das Benutzer Schreibzugriff haben, sollte ein Quota eingerichtet werden. Berechnen Sie eine sinnvolle Quota-Größe, die Benutzerfreundlichkeit und Sicherheit kombiniert, und weisen Sie diese zu.
Sie wollen also Quotas benutzen. Zuerst müssen Sie prüfen, ob Ihr Kernel
Quota unterstützt. Wenn nicht, müssen Sie ihn neu kompilieren. Prüfen Sie
anschließend, ob das Paket quota
installiert ist. Wenn nicht,
installieren Sie es.
Um Quota für die entsprechenden Dateisysteme einzuschalten, müssen Sie nur
die Einstellung defaults in Ihrer /etc/fstab
zu
defaults,usrquota ändern. Wenn Sie Gruppen-Quotas benötigen,
ersetzen Sie usrquota durch grpquota. Sie können
auch beides verwenden. Erstellen Sie dann leere quota.user
und
quota.group
in den Hauptverzeichnissen der Dateisysteme, auf denen
Sie Quotas einführen möchten (d.h. touch /home/quota.user
/home/quota.group für das Dateisystem /home
).
Starten Sie quota
neu, indem Sie /etc/init.d/quota
stop;/etc/init.d/quota start ausführen. Nun sollte quota laufen und
die Größen können festgelegt werden.
Bearbeiten der Quotas eines bestimmten Benutzer wird mit edquota -u <user> gemacht. Gruppen-Quotas können mit edquota -g <group> geändert werden. Setzen Sie dann die weiche und die harte Grenze und inode-Quotas, falls Sie es benötigen.
Mehr Informationen über Quotas finden Sie im Handbuch von quot und im
Mini-Howto von quota
(/usr/share/doc/HOWTO/de-html/mini/DE-Quota-HOWTO.html
). Sie
sollten auch einen Blick auf pam_limits.so
werfen.
Zusätzlich zu den normalen Unix-Rechten bieten die ext2- und ext3-Dateisysteme
eine Anzahl von besonderen Attributen, die Ihnen mehr Kontrolle über die
Dateien auf Ihrem System erlauben. Im Gegensatz zu den gewöhnlichen Rechten
werden diese Attribute nicht vom gebräuchlichen Befehl ls -l
angezeigt und können auch nicht mit chmod
geändert werden. Um
sie zu verwalten, brauchen Sie zwei weitere Programme, nämlich
lsattr
und chattr
(im Paket e2fsprogs
).
Beachten Sie, dass das bedeutet, dass diese Attribute normalerweise bei einem
Backup des Systems nicht gespeichert werden. Wenn Sie also eines verändern,
könnte es sich lohnen, die aufeinander folgenden chattr
-Befehle
in einem Skript zu speichern, damit Sie sie später wieder zuweisen können,
falls Sie ein Backup zurückspielen müssen.
Unter allen Attributen werden die zwei, die für die Erhöhung der Sicherheit am bedeutendsten sind, mit den Buchstaben »i« und »a« bezeichnet. Sie können nur vom Superuser vergeben (oder entfernt) werden:
Das Attribut »i« (»immutable«, unveränderlich): Eine Datei mit diesem Attribut kann weder verändert noch gelöscht oder umbenannt werden, nicht einmal vom Superuser. Auch ein Link auf sie kann nicht angelegt werden.
Das Attribut »a« (»append«, anfügen): Dieses Attribut hat den gleichen
Effekt wie das Attribut immutable, allerdings mit der Ausnahme, dass Sie immer
noch die Datei im Anfügen-Modus öffnen können. Das bedeutet, dass Sie ihr
immer noch Inhalt hinzufügen, aber den vorhanden Inhalt nicht verändern
können. Dieses Attribut ist besonders für die Protokolldateien nützlich,
die unter /var/log/
gespeichert werden. Beachten Sie aber, dass
sie durch Log-Rotations-Skripte manchmal verschoben werden.
Diese Attribute können auch für Verzeichnisse vergeben werden. In diesem Fall ist es jedem unmöglich, den Inhalt des Verzeichnisses zu verändern, also beispielsweise eine Datei umzubenennen oder zu löschen. Wenn das append-Attribut einem Verzeichnis zugewiesen wird, können nur noch Dateien erstellt werden.
It is easy to see how the 'a' attribute improves security, by giving to
programs that are not running as the superuser the ability to add data to a
file without modifying its previous content. On the other hand, the 'i'
attribute seems less interesting: after all, the superuser can already use the
basic Unix permissions to restrict access to a file, and an intruder that would
get access to the superuser account could always use the chattr
program to remove the attribute. Such an intruder may first be confused when
noticing not being able to remove a file, but you should not assume blindness -
after all, the intruder got into your system! Some manuals (including a
previous version of this document) suggest to simply remove the
chattr
and lsattr
programs from the system to
increase security, but this kind of strategy, also known as "security by
obscurity", is to be absolutely avoided, since it provides a false sense
of security.
Dieses Problem lösen Sie auf sichere Art und Weise, indem Sie die Fähigkeiten des Linux-Kernel verwenden, wie es in Proaktive Verteidigung, Abschnitt 10.4.2.1 beschrieben wird. Die hier interessante Fähigkeit heißt CAP_LINUX_IMMUTABLE: Wenn Sie es vom Satz der Fähigkeiten entfernen (indem Sie zum Beispiel den Befehl lcap CAP_LINUX_IMMUTABLE verwenden, ist es nicht mehr möglich, irgendwelche »a« oder »i« Attribute auf Ihrem System zu verändern, auch nicht durch den Superuser! Ein umfassende Strategie könnte also folgendermaßen aussehen:
Vergeben Sie die Attribute »a« und »i« an von Ihnen gewünschte Dateien.
Fügen Sie den Befehl lcap CAP_LINUX_IMMUTABLE einem der Skripten, die den Start des Systems steuern (startup scripts), hinzu.
Setzen Sie das Attribut »i« für dieses Skript, andere Startdateien und auch
das Programm lcap
selbst.
Führen Sie den oben genannten Befehl per Hand aus (oder starten Sie Ihr System neu, um sicherzustellen, dass alles wie gewünscht funktioniert).
Now that the capability has been removed from the system, an intruder cannot change any attribute on the protected files, and thus cannot change or remove the files. If the machine is forced to reboot (which is the only way to restore the capabilities bounding set), it will easily be detected, and the capability will be removed again as soon as the system restarts anyway. The only way to change a protected file would be to boot the system in single-user mode or using another bootdisk, two operations that require physical access to the machine !
Sind Sie sich sicher, dass /bin/login
auf Ihrer Festplatte immer
noch dasselbe Programm ist, das Sie vor ein paar Monaten installiert haben?
Was wäre, wenn es sich um eine gehackte Version handelt, die eingegebene
Passwörter in einer versteckten Datei ablegt oder sie als Klartext im ganzen
Internet herummailt?
Die einzige Methode, um einen gewissen Schutz dafür zu haben, ist es, die Dateien jede(n) Stunde/Tag/Monat (ich ziehe täglich vor) zu prüfen, indem man deren aktuelle und alte MD5-Summe vergleicht. Zwei unterschiedliche Dateien können keine gleichen MD5-Summen haben (die MD5-Summe umfasst 128 Bits, so ist die Wahrscheinlichkeit, dass zwei unterschiedliche Dateien eine gleiche MD5-Summe haben etwa 1 zu 3,4e3803). So sind Sie sicher, solange niemand den Algorithmus gehackt hat, der die MD5-Summen auf Ihrer Maschine erstellt. Dies ist, nun ja, extrem schwer und sehr unwahrscheinlich. Sie sollten diese Überprüfung Ihrer Programme als sehr wichtig ansehen.
Weit verbreitete Werkzeuge hierfür sind sxid
, aide
(Advanced Intrusion Detection Environment, fortgeschrittene Umgebung zur
Erkennung von Eindringlingen), tripwire
, integrit
und
samhain
. Das Installieren von debsums
wird Ihnen
helfen, die Integrität des Dateisystems zu überprüfen, indem Sie die
MD5-Summen jeder Datei gegen die MD5-Summe aus dem Debian-Archiv-Paket
vergleichen. Seien Sie aber gewarnt, dass diese Dateien sehr leicht von einem
Angreifer geändert werden können. Außerdem stellen nicht alle Pakete
MD5-Summen für die in ihnen enthaltenen Programme zur Verfügung. Weitere
Informationen finden Sie unter Regelmäßiges Überprüfung der
Integrität, Abschnitt 10.2 und Einen Schnappschuss
des Systems erstellen, Abschnitt 4.19.
You might want to use locate
to index the whole filesystem, if so,
consider the implications of that. The Debian findutils
package
contains locate
which runs as user nobody, and so it only indexes
files which are visible to everybody. However, if you change it's behaviour
you will make all file locations visible to all users. If you want to index
all the filesystem (not the bits that the user nobody can see) you can replace
locate
with the package slocate
. slocate is labeled
as a security enhanced version of GNU locate, but it actually provides
additional file-locating functionality. When using slocate
, the
user only sees the actually accessible files and you can exclude any files or
directories on the system. The slocate
package runs its update
process with higher privledges than locate, and indexes every file. Users are
then able to quickly search for every file which they are able to see.
slocate
doesn't let them see new files; it filters the output
based on your UID.
Sie sollten auch bsign
oder elfsign
einsetzen.
elfsign
bietet die Möglichkeit, digitale Signaturen an
ELF-Binaries anzufügen und diese Signaturen zu überprüfen. Die aktuelle
Fassung verwendet PKI, um die Checksummen der Binaries zu signieren. Dies hat
den Vorteil, dass festgestellt werden kann, ob das Binary verändert wurde und
wer es erstellt hat. bsign
verwendet GPG, elfsign
benutzt PKI-(X.509)-Zertifikate (OpenSSL).
Das Debian-Paket checksecurity
enthält einen
Cron
-Job, der täglich in
/etc/cron.daily/checksecurity
ausgeführt wird. [42]. Dieser Cron
-Job
führt das Skript /usr/sbin/checksecurity
aus, das Informationen
über Änderungen sichert.
The default behavior does not send this information to the superuser but,
instead keeps daily copies of the changes in
/var/log/setuid.changes
. You should set the MAILTO variable (in
/etc/checksecurity.conf
) to 'root' to have this information mailed
to the superuser. See checksecurity(8)
for more configuration
info.
FIXME: mehr (für Debian spezifischer) Inhalt benötigt
Viele Fähigkeiten des Kernels können während des Betriebs verändert werden,
indem etwas an das /proc
-Dateisystem geschickt wird, oder indem
sysctl
benutzt wird. Wenn Sie /sbin/sysctl -A
eingeben, können Sie sehen, was Sie einstellen können und welches die
Optionen sind. Veränderungen werden vorgenommen, indem /sbin/sysctl -w
variable=value ausgeführt wird (vergleiche sysctl(8)
).
Nur in seltenen Fällen müssen Sie hier etwas bearbeiten. Aber auch hier
können Sie die Sicherheit erhöhen. Zum Beispiel:
net/ipv4/icmp_echo_ignore_broadcasts = 1
Dies ist ein Windows-Emulator, weil es sich wie Windows bei Rundrufen (Broadcast-Ping) verhält, wenn es auf 1 gesetzt wird. Das bedeutet, dass ICMP-Echo-Anfragen, die an die Rundrufadresse geschickt werden, ignoriert werden. Anderenfalls macht es gar nichts.
Falls Sie verhindern wollen, dass Ihr System auf ICMP-Echo-Anfragen antwortet, müssen Sie nur diese Konfigurationsoption anschalten:
net/ipv4/icmp_echo_ignore_all = 1
Verwenden Sie Folgendes, um Pakete mit unmöglichen Adressen (erzeugt durch falsche Routen) in Ihrem Netzwerk zu protokollieren:
/proc/sys/net/ipv4/conf/all/log_martians = 1
Für weiterführende Informationen, welche Sachen mit
/proc/sys/net/ipv4/*
angestellt werden können, sollten Sie
/usr/src/linux/Documentation/filesystems/proc.txt
lesen. Alle
Optionen werden gründlich in
/usr/src/linux/Documentation/networking/ip-sysctl.txt
[43] beschrieben.
Diese Option ist ein zweischneidiges Schwert. Auf der einen Seite schützt es Ihr System vor dem Überfluten mit syn-Paketen. Auf der anderen Seite verletzt es definierte Standards (RFCs).
net/ipv4/tcp_syncookies = 1
Wenn Sie das dauerhaft für den Kernel festlegen wollen, müssen Sie in /etc/network/options syncookies=yes festlegen. Jedes Mal, wenn /etc/init.d/networking ausgeführt wird (was typischerweise beim Booten geschieht), wird diese Option wirksam. Dagegen wird folgendes nur eine einmalige Wirkung bis zum nächsten Neustart haben:
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
Diese Option ist nur verfügbar, wenn der Kernel mit CONFIG_SYNCOOKIES übersetzt wurde. Alle Kernel von Debian wurden mit dieser Option kompiliert. Sie können das folgendermaßen überprüfen:
$ sysctl -A |grep syncookies net/ipv4/tcp_syncookies = 1
Weitere Informationen zu TCP-Syncookies finden Sie unter http://cr.yp.to/syncookies.html
.
Wenn Sie die Netzwerkoptionen des Kernels konfigurieren, müssen Sie dafür sorgen, dass sie bei jedem Neustart des Systems geladen werden. Das nachfolgende Beispiel aktiviert neben vielen der oben vorgestellten Optionen auch noch ein paar andere nützliche Optionen.
Tatsächlich gibt es zwei Möglichkeiten, Ihr Netzwerk beim Booten
einzurichten. Sie können entweder /etc/sysctl.conf
konfigurieren
(siehe sysctl.conf(5)
) oder ein Skript einsetzen, das beim
Aktivieren der Netzwerkschnittstellen aufgerufen wird. Die erste Möglichkeit
wird auf alle Schnittstellen angewendet, die zweite erlaubt es Ihnen, die
Konfiguration für jede Schnittstelle separat zu wählen.
Ein Beispiel einer Konfiguration von /etc/sysctl.conf
, die einige
Netzwerkoptionen auf der Kernelebene absichert, wird unten gezeigt. Beachten
Sie darin den Kommentar, dass /etc/network/options
beim Ausführen
von /etc/init.d/networking
(dies ist in der Startsequenz nach
procps
) einige Werte überschreiben könnte, wenn sich Werte in
dieser Datei widersprechen.
# # /etc/sysctl.conf - Configuration file for setting system variables # See sysctl.conf (5) for information. Also see the files under # Documentation/sysctl/, Documentation/filesystems/proc.txt, and # Documentation/networking/ip-sysctl.txt in the kernel sources # (/usr/src/kernel-$version if you have a kernel-package installed) # for more information of the values that can be defined here. # # Be warned that /etc/init.d/procps is executed to set the following # variables. However, after that, /etc/init.d/networking sets some # network options with builtin values. These values may be overridden # using /etc/network/options. # #kernel.domainname = example.com # Additional settings - adapted from the script contributed # by Dariusz Puchala (see below) # Ignore ICMP broadcasts net/ipv4/icmp_echo_ignore_broadcasts = 1 # # Ignore bogus ICMP errors net/ipv4/icmp_ignore_bogus_error_responses = 1 # # Do not accept ICMP redirects (prevent MITM attacks) net/ipv4/conf/all/accept_redirects = 0 # _or_ # Accept ICMP redirects only for gateways listed in our default # gateway list (enabled by default) # net/ipv4/conf/all/secure_redirects = 1 # # Do not send ICMP redirects (we are not a router) net/ipv4/conf/all/send_redirects = 0 # # Do not forward IP packets (we are not a router) # Note: Make sure that /etc/network/options has 'ip_forward=no' net/ipv4/conf/all/forwarding = 0 # # Enable TCP Syn Cookies # Note: Make sure that /etc/network/options has 'syncookies=yes' net/ipv4/tcp_syncookies = 1 # # Log Martian Packets net/ipv4/conf/all/log_martians = 1 # # Turn on Source Address Verification in all interfaces to # prevent some spoofing attacks # Note: Make sure that /etc/network/options has 'spoofprotect=yes' net/ipv4/conf/all/rp_filter = 1 # # Do not accept IP source route packets (we are not a router) net/ipv4/conf/all/accept_source_route = 0
Um dieses Skript verwenden zu können, müssen Sie es zuerst unter z.B.
/etc/network/interface-secure
(der Name ist nur ein Beispiel)
erstellen und es wie folgt aus /etc/network/interfaces
aufrufen:
auto eth0 iface eth0 inet static address xxx.xxx.xxx.xxx netmask 255.255.255.xxx broadcast xxx.xxx.xxx.xxx gateway xxx.xxx.xxx.xxx pre-up /etc/network/interface-secure
In diesem Beispiel wird das Skript aufgerufen, um alle Netzwerkschnittstellen abzusichern, wie unten gezeigt wird, bevor die Schnittstelle eth0 aktiviert wird.
#!/bin/sh -e # Skriptname: /etc/network/interface-secure # # Verändert das Standardverhalten für alle Schnittstellen in einigen Bereichen, # um vor TCP/IP-Spoofing und Angriffen zu schützen. # # Wurde von Dariusz Puchalak beigesteuert # echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # Broadcast echo protection enabled. echo 0 > /proc/sys/net/ipv4/conf/all/forwarding # IP forwarding disabled. echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP syn cookies protection enabled. echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Log strange packets. # (this includes spoofed packets, source routed packets, redirect packets) # but be careful with this on heavy loaded web servers. echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses # Bad error message protection enabled. # IP spoofing protection. echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter # Disable ICMP redirect acceptance. echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects # Disable source routed packets. echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route exit 0
Beachten Sie, dass Sie auch verschiedene Netzwerkoptionen für verschiedene Schnittstellen (falls Sie mehr als eine haben) setzten können, indem Sie die pre-up-Zeile verändern:
pre-up /etc/network/interface-secure $IFACE
Zusätzlich müssen Sie ein Skript verwenden, das Änderungen nur auf eine bestimmte Schnittstelle anwendet und nicht auf alle Schnittstellen. Beachten Sie aber, dass einige Netzwerkoptionen nur global gesetzt werden können. Dies ist ein Beispielsskript:
#!/bin/sh -e # Skriptname: /etc/network/interface-secure # # Verändert das Standardverhalten für alle Schnittstellen in einigen Bereichen, # um vor TCP/IP-Spoofing und Angriffen zu schützen. # # Wurde von Dariusz Puchalak beigesteuert # IFACE=$1 if [ -z "$IFACE" ] ; then echo "$0: Must give an interface name as argument!" echo "Usage: $0 <interface>" exit 1 fi if [ ! -e /proc/sys/net/ipv4/conf/$IFACE/ ]; then echo "$0: Interface $IFACE does not exit (cannot find /proc/sys/net/ipv4/conf/)" exit 1 fi echo 0 > /proc/sys/net/ipv4/conf/$IFACE/forwarding # IP forwarding disabled. echo 1 >/proc/sys/net/ipv4/conf/$IFACE/log_martians # Log strange packets. # (this includes spoofed packets, source routed packets, redirect packets) # but be careful with this on heavy loaded web servers. # IP spoofing protection. echo 1 > /proc/sys/net/ipv4/conf/$IFACE/rp_filter # Disable ICMP redirect acceptance. echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_redirects echo 0 > /proc/sys/net/ipv4/conf/$IFACE/send_redirects # Disable source routed packets. echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_source_route exit 0
Eine andere Lösungsmöglichkeit ist es, ein init.d-Skript zu
erstellen und es beim Booten auszuführen (verwenden Sie
update-rc.d
, um die passenden rc.d-Links
herzustellen).
Um die Möglichkeiten einer Firewall zu haben, damit entweder das lokale System
oder andere dahinter beschützt werden, muss der Kernel mit
Firewall-Unterstützung kompiliert worden sein. Der Standardkernel von Debian
2.2 (Linux 2.2) stellt die Paketfilter-Firewall ipchains
zur
Verfügung. Der Standardkernel von Debian 3.0 (Linux 2.4) enthält die
stateful Paketfilter-Firewall iptables
(netfilter).
In jedem Fall ist es recht einfach, einen anderen als den mit Debian
gelieferten Kernel zu benutzen. Sie finden vorkompilierte Kernel als Pakete
vor, die Sie leicht auf Ihrem Debian-System installieren können. Mit Hilfe
des Pakets kernel-source-X
können Sie auch die
Kernelquellen herunterladen und einen maßgeschneiderten Kernel kompilieren,
indem Sie make-kpkg
aus dem Paket kernel-package
benutzen.
Auf das Aufsetzen einer Firewall unter Debian wird unter Hinzufügen von Firewall-Fähigkeiten, Abschnitt 5.14 ausführlich eingegangen.
Auf Systemen mit mehr als einer Schnittstelle zu verschiedenen Netzwerken können Dienste so eingerichtet werden, dass sie Verbindungen nur zu einer bestimmten IP-Adresse zulassen. Normalerweise verhindert das den Zugang zu diesen Diensten, wenn an sie Anfragen über andere Adressen gestellt werden. Allerdings bedeutet das nicht, dass der Dienst an eine bestimmte Hardware-Adresse (Netzwerkkarte) gebunden ist (ein verbreiteter Irrtum). [44]
Das ist kein Problem von ARP und auch keine Verletzung eines RFCs (es wird in
RFC1122
,
Abschnitt 3.3.4.2 als weak end host bezeichnet). Vergessen Sie nicht,
dass IP-Adressen nichts mit dem physischen Schnittstellen zu tun haben.
Im Kernel 2.2 (und davor) konnte dieses Problem so gelöst werden:
# echo 1 > /proc/sys/net/ipv4/conf/all/hidden # echo 1 > /proc/sys/net/ipv4/conf/eth0/hidden # echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden .....
Bei späteren Kernel kann das folgendermaßen gelöst werden:
Regeln für iptables
richtig konfiguriertes Routing [45] oder
Patchen des Kernels [46]
Along this text there will be many occasions in which it is shown how to configure some services (sshd server, apache, printer service...) in order to have them listening on any given address, the reader should take into account that, without the fixes given here, the fix would not prevent accesses from within the same (local) network. [47]
FIXME: Comments on Bugtraq indicate there is a Linux specific method to bind to a given interface.
FIXME: Submit a bug against netbase so that the routing fix is standard behavior in Debian?
Wenn Sie den anderen Kisten in Ihrem LAN nicht trauen (das sollte immer so sein, da es die sicherste Einstellung ist), sollten Sie sich vor den verschiedenen ARP-Angriffen schützen.
Wie Sie wissen, wird das ARP-Protokoll dazu verwendet, IP-Adressen mit
MAC-Adressen zu verknüpfen (für alle Details siehe RFC826
). Jedes Mal,
wenn Sie ein Paket an eine IP-Adresse schicken, wird eine ARP-Auflösung
vorgenommen (zuerst wird in den lokalen ARP-Speicher geschaut, und falls die IP
nicht im Speicher ist, wird ein Rundruf (Broadcast) mit der ARP-Anfrage
verschickt), um die Hardware-Adresse des Ziels zu finden. Alle ARP-Angriffe
zielen darauf ab, Ihrem Rechner vorzugaukeln, dass die IP-Adresse des Rechners
B mit der MAC-Adresse des Computers des Angreifers verbunden ist. Dadurch wird
jedes Paket, das Sie an den Rechner B, der mit der IP-Adresse verbunden ist,
schicken wollen, an den Computer des Eindringlings umgeleitet ...
Diese Angriffe (Verfälschung des ARP-Speichers, ARP-Spoofing, ...)
ermöglichen dem Angreifer, auf Netzwerken den Verkehr abzuhören (selbst bei
Netzwerken, die über einen Switch laufen). Er kann sich leicht in eine
Verbindung einschleusen oder einen Host vom Netzwerk nehmen oder ...
ARP-Angriffe sind leistungsfähig und einfach durchzuführen. Es gibt dafür
auch einige Werkzeuge wie arpspoof
aus dem Paket
dsniff
oder arpoison
.
Allerdings gibt es immer eine Lösung:
Verwenden Sie einen statischen ARP-Speicher. So erstellen Sie »statische« Einträge in Ihrem ARP-Speicher:
arp -s host_name hdwr_addr
Indem Sie statische Einträge für jeden wichtigen Host in Ihrem Netzwerk vergeben, stellen Sie sicher, dass niemand einen (falschen) Eintrag für diese Hosts erstellen oder verändern kann (statische Einträge verfallen nicht und können nicht verändert werden). Auch gefälschte ARP-Antworten werden ignoriert.
Entdecken Sie verdächtigen ARP-Verkehr. Sie können dazu
arpwatch
, karpski
oder allgemeinere IDS, die auch
verdächtigen ARP-Verkehr entdecken können wie snort
oder
prelude
, einsetzen.
Verwenden Sie einen IP-Filter, der die MAC-Adressen überprüft.
Bevor Sie das System in produktiven Betrieb nehmen, können Sie einen Schnappschuss des gesamten Systems erstellen. Diesen Schnappschuss können Sie im Falle einer Kompromittierung (siehe Nach einer Kompromittierung (Reaktion auf einem Vorfall), Kapitel 11) benutzen. Sie sollten den Schnappschuss immer dann erneuern, wenn Sie das System aktualisieren, insbesondere wenn Sie auf eine neue Debian-Veröffentlichung upgraden.
Hierfür können Sie beschreibbare, austauschbare Datenträger benutzen, die Sie schreibschützen können. Dies kann eine Diskette (die nach der Benutzung schreibgeschützt wird), eine CD in einem CD-ROM-Laufwerk (Sie können auch wiederbeschreibbare CD-ROMs benutzen, so können Sie sogar alte Sicherheitskopien Ihrer MD5-Summen behalten), eine USB-Platte oder eine MMC-Karte (wenn Ihr System auf diese zugreifen kann und sie schreibgeschützt werden können) sein.
Das folgende Skript erstellt einen solchen Schnappschuss:
#!/bin/bash /bin/mount /dev/fd0 /mnt/floppy trap "/bin/umount /dev/fd0" 0 1 2 3 9 13 15 if [ ! -f /usr/bin/md5sum ] ; then echo "Kann md5sum nicht finden. Breche ab." exit 1 fi /bin/cp /usr/bin/md5sum /mnt/floppy echo "Erstelle MD5-Datenbank" >/mnt/floppy/md5checksums.txt for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/ do find $dir -type f | xargs /usr/bin/md5sum >>/mnt/floppy/md5checksums-lib.txt done echo "MD5-Datenbank (nach der Installation) erstellt" if [ ! -f /usr/bin/sha1sum ] ; then echo "Kann sha1sum nicht finden" echo "WARNUNG: nur die md5-Datenbank wird gespeichert" else /bin/cp /usr/bin/sha1sum /mnt/floppy echo "Erstelle SHA-1-Datenbank" >/mnt/floppy/sha1checksums.txt for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/ do find $dir -type f | xargs /usr/bin/sha1sum >>/mnt/floppy/sha1checksums-lib.txt done echo "SHA-1-Datenbank (nach der Installation) erstellt" fi exit 0
Beachten Sie, dass das Programm md5sum (und sha1sum, falls verfügbar) auch auf der Diskette gesichert werden muss, so dass Sie es später benutzen können, um die anderen Programme Ihres Systems zu prüfen (für den Fall, dass md5sum oder sha1sum einen Trojaner enthalten). Wenn Sie aber sicher sein wollen, dass Sie eine gültige Kopie von md5sum verwenden, sollten Sie eine statische Kopie von md5sum erstellen und diese verwenden (damit wird verhindert, dass eine manipulierte libc-Bibliothek das Programm beeinträchtigt) oder md5sum nur in einer sauberen Umgebung einsetzen, die Sie etwa mit einer Rettungs-CD-ROM oder einer Live-CD erzeugen können (damit wird verhindert, dass ein manipulierter Kernel das Programm beeinflusst). Ich kann es nicht genug betonen: Wenn Sie ein System haben, in das eingebrochen wurde, können Sie den Ausgaben nicht vertrauen. Sehen Sie sich auch Nach einer Kompromittierung (Reaktion auf einem Vorfall), Kapitel 11 an.
Dieser Schnappschuss enthält nicht die Dateien unterhalb von
/var/lib/dpkg/info
, wo MD5-Summen installierter Pakete enthalten
sind (die Dateien enden mit .md5sums
). Sie können diese
Informationen zusätzlich kopieren, aber Sie sollten Folgendes beachten:
Die Dateien mit den MD5-Summen enthalten die MD5-Summen aller Dateien, die ein Debian-Paket enthält, nicht nur die der Systemprogramme. Das hat zur Folge, dass diese Datenbank viel größer ist (5 MB statt 600 KB auf einem Debian GNU/Linux System mit grafischen Subsystem und etwa 2,5 GB Software installiert) und nicht auf ein kleines, transportables Medium wie eine Diskette passt, aber wohl auf einen tragbaren USB-Speicher.
Nicht alle Debian-Pakete stellen MD5-Summen der installierten Dateien zur
Verfügung, da es (derzeit) nicht in der Richtlinie verlangt wird. Sie können
allerdings nach der Installation die MD5-Summen aller Pakete mit
debsums
erstellen:
# debsums --generate=missing,keep
Sobald der Schnappschuss erstellt wurde, sollten Sie sicherstellen, dass das
entsprechende Medium schreibgeschützt ist. Sie können es dann als
Sicherheitskopie verwenden oder in ein Laufwerk stecken, um jede Nacht mit
cron
die MD5-Summen des Systems mit Ihrem Schnappschuss zu
vergleichen.
Wenn Sie keine Überprüfung von Hand einrichten wollen, können Sie immer eines der Integritätssysteme verwenden, die diese Aufgabe und noch vieles mehr für Sie erledigen werden. Weitere Informationen finden Sie unter Regelmäßiges Überprüfung der Integrität, Abschnitt 10.2.
SVGAlib ist ganz nett für Konsolen-Liebhaber wie mich, aber in der
Vergangenheit wurde mehrfach gezeigt, dass es ziemlich unsicher ist. Exploits
durch zgv
wurden veröffentlicht und es war einfach, Root zu
werden. Versuchen Sie die Nutzung von SVGAlib-Programmen wann immer nur
möglich zu vermeiden.
[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ weiter ]
Securing Debian Manual
Version: 3.17,mailto:jfs@debian.org