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 ihrem Setup up, aber um physischen Zugriff zu verhindern. sollten sie Änderungen im BIOS (noch einmal), Abschnitt 4.1, Ein Passwort für LILO oder GRUB einstellen, Abschnitt 4.2, Entfernen des root Promptes aus dem Kernel, Abschnitt 4.3, Booten von Diskette verbieten, Abschnitt 4.4, einschränkender Konsolen zugang, Abschnitt 4.5, und Systemneustart auf der Konsole einschränken, Abschnitt 4.6 lesen.
Bevor sie sich mit einem Netzwerk verbinden, insbesondere wenn es sich um ein öffentliches Netzwerk handelt, sollten sie wenigstens ein securezty update (siehe Ausführen von Sicherheitsupdates, Abschnitt 4.8) durchführen. Optional können sie sie sich einen Snapshot ihres Systems machen (siehe Einen Schnappschuss des Systems erstellen, Abschnitt 4.17).
Erinnern sie sich an Setzen Sie ein Passwort im BIOS, Abschnitt 3.1? Nun, jetzt sollten sie, nachdem sie nicht mehr von austauschbaren Datenträgern booten müssen, die standard BIOS Einstellung so umändern, dass es auschliesslich von der Festplatte bootet. Gehen sie sicher, dass sie ihr BIOS Passwort nicht verlieren, oder sie werden, im Falle eines Festplattenfehlers, nicht mehr ins BIOS zurückkehren können, um die Einstellung wieder zu ändern, so dass sie ihr System wiederherstellen können, indem sie zum Beispiel eine CD-ROM benutzen.
Eine andere, weniger sicher, aber bequemere Möglichkeit ist es, das BIOS so einzustellen, dass es von von der Festplatte bootet, und nur falls dies fehlschlägt versucht von austauschbaren Datenträgern zu booten. Übrigens wird dies oft so gemacht, weil nur wenige ein BIOS Passwort benutzen, dass oft zu leicht vergessen wird.
Jeder kann sehr einfach eine roor 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 and kann alles auf ihrem System machen, das sie will. 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 zwischem einem globalen Passwort und Passwörtern für bestimmte Images wählen.
Für LILO müssen sie die Konfigurationsdatei
/etc/lilo.conf
editieren 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
Haben sie dies getan, rufen sie lilo auf. Wenn sie die "restricted"
Zeile weglassen, wird lilo immmer nach dem Passwort fragen, egal ob LILO
parameter übergeben wurden oder nicht. Die vorgabe 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, editieren sie
/boot/grub/menu.lst
und fügen die folgenden zwei Zeilen am
Anfang an (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, sollten sie ihr Passwort verschlüsselt ablegen. Das Utility grub-md5-crypt generierd ein gehashtes Passwort, das kompatibel mit grub's Verschlüsselungsalgorithmus (md5) ist. Um grub mitzuteilen, dass verschlüsselte Passwörter benutzt werden, benutzen sie die folgende Anweisung:
timeout 3 password --md5 $1$arPydhOM$bIgEKjMW5kxeEuvE1Rah4/
Der --md5 Parameter wurde hinzugefügt, um bei grub einen md5 Authentifizierungsprozess zu erzwingen. Das angegeben Passwort ist die md5 verschlüsselte Version von hackmich. Es ist vorzuziehen md5- statt Klartextpasswörter zu verwenden. Weitere Informationen über grub Passwörter können sie im grub-doc Packet finden.
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 auszuführende Shell mit Root Privilegien zu betreten, 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
editieren und den Eintrag
# DELAY Anzahl Sekunden, die das linuxrc Skript warten soll, # um den Nutzer eingriffe zu erlauben, befor das System hochgefahren # wird DELAY=0
setzen.
Generieren sie ihr ramdisk image anschliessend 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 machen sie (vorzugsweise):
# dpkg-reconfigure kernel-image-2.4.x-yz
Beachten sie, dass Debian 3.0 woody den Benutzern erlaubt 2.4er Kernel zu
installieren (indem sie flavors wählen), aber der
standard Kernel ist 2.2 (von einigen Architekturen abgesehen, auf die der Kenel
2.2 nicht portiert wurde). Wenn sie dies als Bug ansehen, beachten sie
Bug 145244
bevor sie
ihn einsenden.
Der standard MBR von Debian vor Version 2.2 verhielt sich nicht wie ein normaler Master Boot Record und lies eine Methode offen, einfach in ein System einzubrechen:
Dieses Verhalten können sie ändern, indem sie
lilo -b /dev/hda
eingeben.
Nun ist LILO in den MBR geschoben worden. Dies können sie auch erreichen, indem sie "boot=/dev/hda" zu lilo.conf hinzufügen. Es gibt noch eine Möglichkeit, die den MBR komplett abschalten wird:
install-mbr -i n /dev/hda
Auf der anderen Seite, könnte diese "Hintertür", die viele Leute nicht kennen, ihnen einmal die Haut retten, wenn sie in grosse Schwierigkeiten mit ihren Installations aus irgendwelchen Gründen geraten.
FIXME überprüfen, ob das für 2.2 wirklich stimmt, oder war es 2.1? INFO: Die Boot Disketten von Debian 2.2 installieren KEINEN mbr, sondern nur LILO
Manche Sicherheits Policies könntem Administratoren dazu zwingen, sich
erst als als User mit ihrem Passwort auf dem System einzulogen, und dann
Superuser zu werden (mit su
oder sudo
). Solche eine
Policy ist in Debian in der Datei /etc/login.defs
oder
/etc/securetty
(falls sie PAM verwenden) implementiert. In:
login.defs
, ändern sie die CONSOLE Variable, die eine Datei
oder eine Liste von Terminals definiert, an denen sich root einloggen darf
securetty
entfernen sie oder fügen sie Terminals hinzu, bei
denen Root Zugriff erhalten darf
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 konfigurieren 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) einzulogen. Diese Eigenschaft kann eingeschränkt
werden, indem sie nullok aus der Zeile
auth required pam_unix.so nullok
entfernen.
Wenn an ihr System eine Tastatur angeschlossen ist, kann jeder (ja wirklich
jeder) ihr System neu starten, ohne sich in ihr System einlogen zu
müssen. Dies könnte oder könnte nicht gegen ihre Sicherheits
Richtlinie verstoßen. Wenn sie dies einschränken wollen,
müssen sie in /etc/inittab
prüfen, ob die Zeile, die
enthält, dass ctrlaltdel shutdown
aufruft, den
-a Schalter enthält (vergessen sie nicht, init q
auszuführen, nachdem sie diese Datei irgendwie verändert haben). Der
standardmässig enthält Debian diesen Schalter:
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Jetzt müssen sie, um es manchen Benutzern zu erlauben, ihr System
neu zu starten, eine Datei /etc/shutdown.allow
erstellen, wie es
in der Manual Seite shutdown(8)
beschreibt. Dort müssen die
Namen der Benutzer, die das System neu booten dürfen, aufgeführt
sein. Wenn der drei Finger Salut (auch bekannt als
Strg+Alt+Entf) ausgeführt wird, wird geprüft, ob irgendeiner
der Benutzer, die in der Datei aufgelistet sind, eingeloggt sind. Wenn es
keiner von ihnen ist, wird shutdown
das System nicht neu
starten.
Wenn sie eine ext2 Partition einbinden, können sie verschiedene Optionen
mit dem mount-Befehl oder in /etc/fstab
verwenden. Dies zum
Beispiel, ist mein fstab Eintrag für meine /tmp
Partition:
/dev/hda7 /tmp ext2 defaults,nosuid,noexec,nodev 0 2
Sie sehen den Unterschied in der Spalte mit den Optionen. Die Option nosuid ignoriert alle setuid und setgid Bits komplett, während noexec das ausführen irgendwelcher Programme unterhalb des mount Points verbietet und nodev Geräte ignoriert. Das hört sich toll an, aber es
Die noexec option, die verhindert, dass Binaries ausgeführt werden können, lässte sich leicht umgehen:
alex@joker:/tmp# mount | grep tmp /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev) alex@joker:/tmp# ./date bash: ./date: Permission denied alex@joker:/tmp# /lib/ld-linux.so.2 ./date Sun Dec 3 17:49:23 CET 2000
Wie auch immer, viele Skriptkiddies haben Exploits, die versuchen eine
ausführbare Datei in /tmp
zu erstellen. Wenn sie keine
Ahnung haben, werden sie in dieser Grube hängenbleiben. Mit anderen
Worten: Ein Benutzer kann nicht dazu getrickts werden, einen ausführbaren
Trojaner in /tmp
auszuführen, zum Beispiel indem er
zufällig /tmp
in seine Suchpfad aufnimmt.
Seien sie auch gewarnt, dass manche Skripts darauf aufbauen, dass
/tmp
ausführbare Rechte hat. Bemerkenswerter weise hatte
(oder hat?) Debconf Probleme bei dieser Sache, weitere Informationen
enthält Bug 116448
.
Nachfolgend ist ein gründlichereres Beispiel. Dazu: /var
könnte auch noexec enthalten, aber manche Software, wie zum Beispiel
Smartlist, behält seine Programme unterhalb von /var. Das selbe gillt
für die nosuid Option.
/dev/sda6 /usr ext2 defaults,ro,nodev 0 2 /dev/sda12 /usr/share ext2 defaults,ro,nodev,nosuid 0 2 /dev/sda7 /var ext2 defaults,nodev,usrquota,grpquota 0 2 /dev/sda8 /tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda9 /var/tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda10 /var/log ext2 defaults,nodev,nosuid,noexec 0 2 /dev/sda11 /var/account ext2 defaults,nodev,nosuid,noexec 0 2 /dev/sda13 /home ext2 rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota 0 2 /dev/fd0 /mnt/fd0 ext2 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
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.
Was noexec betrifft, seien sie sich bitte bewusst, dass es ihnen nicht sehr viel Sicherheit bietet. Regarding noexec, please be aware that it might not offer you that much security. Berücksichtigen sie dies:
$ cp /bin/date /tmp $ /tmp/date (wird aufgrund des noexec nicht ausgeführt) $/lib/ld-linux.so.2 /tmp/date (funktioniert, da date nicht direkt ausgeführt wird)
Wenn sie auf /usr
nur lesenden Zugriff erlauben, werden sie nicht
in der Lage sein, neue Pakete auf ihrem Debian GNU/Linux System installieren
können. Sie werden es erst wieder mit Schreibzugriff neumounten
müssen, die Pakete installieren, und dann wieder read-only mounten. Die
neuste Version von apt (in Debian 3.0 'woody') kann konfiguriert werden Befehle
vor und nach dem installiern von Paketen auszuführen, also möchten
sie es vielleicht passend konfigurieren.
To do this modify /etc/apt/apt.conf
and add:
DPkg { Pre-Invoke { "mount /usr -o remount,rw" }; Post-Invoke { "mount /usr -o remount,ro" }; };
Beachten sie sie, dass das Post-Invoke mit einer "/usr busy" Fehlermeldung scheitern wird. Dies passiert vorwiegend, wenn sie eine Datei während des Updates benutzen. Ärgerlich, aber kein grosses Problem. Gehen sie einfach sicher, dass sie nicht länger benutzt werden, und führen sie das Post-Invoke manuell aus.
Sobald neue Sicherheitslöcher in einem Paket entdeckt wurden reparieren
sie Debian Paket-Betreuer und ursprüngliche Autoren im allgemein 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 Release installieren müssen sie berücksichtigen, dass es, seitdem der Releas gemacht wurde, Sicherheitsupdates geben könnte, nachdem entdeckt wurde, dass ein bestimmtes Paket verwundbar ist. Ebenso könnte es kleinere Releases gegeben haben (es gab acht kleinere Releases von Debian 2.2 potato), die diese Paktet-Updates enthalten.
Sie müssen sich das Erstellungsdatum ihres CD Sets (wenn sie ein solches benutzen) notieren, und auf der Sicherheitsseite prüfen, ob es Sicherheits-Updates gegeben hat. Wenn es solche gibt, und sie sie die Pakete nicht von der Sicherheits-Seite herunterladen können (Ihr System ist noch nicht mit dem Internet verbunden, oder?), könnten sie es in erwähgung ziehen (falls sie nicht, beispielsweise durch eine Firewall, geschützt sind), Firewall-Regeln zu aktivieren, so dass ihr System ausschliesslich mit securety-debian.org Verbindung aufnehmen kann und dann ein update Ausführen. Eine Beispiel-Konfiguration finden sie unter Sicherheits-Update geschützt durch eine Firewall, Anhang F.
Um ihr System upzudaten, fügen sie die folgende Zeile in ihre
/etc/apt/sources.list
, und sie werden Sicherheits-Updates
automatisch erhalten, wann immer sie ihr System updaten.
deb http://security.debian.org/debian-security stable/updates main contrib non-free
Die meisten Leute, die nicht in einem Land leben, das den import oder die Nutzung starker Kryptographie verbietet, sollte auch diese Zeile hinzufügen:
deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free
Wenn sie möchten, können sie ebenfalls eine deb-src Zeile
hinzufügen. Weitere Details finden sie unter apt(8)
.
Sie sollten regelmässig Sicherheits-Updates durchführen, die meisten
Sicherheitsprobleme resultieren aus bekannten Sicherheitslücken heraus,
die nicht rechtzeitig gestopft wurden, wie auch http://www.cs.umd.edu/~waa/vulnerability.html
name="paper by Bill Arbaugh"> (vorgetrafen auf dem 2001 IEEE
Symposium on Security and Privacy) erklärt.
FIXME: Add info on how the signature of packages is done so that this can be done automatically through a cron job (big warning: DNS spoofing).
PAM (Pluggable Authentication Modules) erlauben dem System Administrator
auszuwählen, wie eine Anwendung, Benutzer authentifiziert. 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 2.2
geliefert werden, habend diese Unterstützung eingebaut. Weiterhin hatte
Debian keine Unterstützung für PAM vor Version 2.2. Die derzeitige
Standard-Konfiguration für jedweden PAM benutzenden Service, ist es, UNIX
Authentifizierung zu emulieren (lessen sie
/usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz
um mehr
darüber zu erfahren, wie PAM Services unter Debian arbeiten
sollten).
Jede Anwendung mit PAM Unterstützung bietet eine Konfiguratiosn Datei
unter /etc/pam.d/
in welche sie ihr Verhalten einstellen
können:
Die folgende Beschreibung ist weit davon entfernt komplett zu sein, für
weitere Informationen möchten sie vielleicht The
Linux-PAM System Administrator's Guide
(auf der PAM Hauptseite
),
diese Dokumentation ist auch in dem Paket libpam-doc
enthalten.
PAM bieten ihnen die Möglichkeit durch mehrere Authentifizierungs Schritte auf einmal zu gehen, ohne das der Benutzer es weiß. Sie können gegen eine Berkeley Datenbank und gegen die normale passwd Datei authentifizieren, und der Benutzer kann sich nur einloggen, wenn er beide Male korrekt authentifiziert wurde. Sie können viel einschränken mit PAM, genauso wie sie ihr System weit öffnen können. Seien sie also vorsichtig. Eine typische Konfigurationszeile hat ein Kontrollfeld als sein zweites Element. Generell sollte es auch "requisite" gesetzt werden, so wird ein login Feger erzeugt, wenn eines der Module versagt.
Die erste Sache, die ich gerne mache, ist es, MD5 Unterstützung zu den PAM
Anwendungen hinzuzufügen, da dies gegen lexikalische Attacken hilft (da
Passwörter länger sein können, wenn sie MD5 benutzen). Die
folgenden zwei Zeilen sollten sie in allen Dateien unterhalb von
/etc/pam.d/
zufügen die Zugriff auf ihre Maschine
gewähren, wie zum Beispiel login und ssh.
# Gehen sie sicher, dass sie libpam-cracklib zuerst installiert haben, # sonst werden sie sich nicht einloggen koennen password required pam_cracklib.so retry=3 minlen=12 difok=3 password required pam_unix.so use_authtok nullok md5
Also, was macht diese Beschwörungsformel nun genau? Die erste Zeile lädt das cracklib PAM Modul, welches einen Passwort-Sicherheits-check bereitstellt; es fragt nach einem neuen Passwort mit einem Minimum von 12 Zeichen, einer Differenz von mindestens 3 Zeichen zum alten Passwort, und erlaubt 3 Versuche. Die zweite Zeile führt das standard authentifizierungs Modul mit MD5 Passwörtern ein und erlaubt Passwörter mit einer Länge von Null. Die use_authtok Direktive ist notwendig, um das Passwort von dem vorherigen Modul übergeben zu bekommen.
Um sicher zu stellen, dass sich der Benutzer root nur von lokalen Terminals
einloggen kann, sollten sie die folgende Zeile in /etc/pam.d/login
eingefügt werden:
auth requisite pam_securetty.so
Nun sollten sie alle Terminals, von denen sich der Benutzer Root einloggen
können sollte, in /etc/security/acces.conf
eintragen. Nicht
zuletzt sollten sie die folgende Zeile aktivieren, wenn sie ihrem Benutzern
Limits setzen wollen:
session required pam_limits.so
Dies schränkt die System die ein User nutzen darf ein (siehe unter in Resourcen-Nutzung limitieren: Die limits.conf Datei, Abschnitt 4.9.2). Sie können zum beispiel die Anzahl der Logins, die man haben kann, einschänken (für eine Gruppe von Nutzern oder Systemweit), die Anzahl der Prozesse, den belegten Speicher...
Editieren sie nun /etc/pam.d/passwd
und ändern sie die erste
Zeile. Si sollten die Option "md5" zufügen, um
MD5-Passwörter zu benitzen, ändern sie die minimale
Passwort-Länge von 4 auf 6 (oder mehr) und setzen sie eine
Maximallänge, wenn sie möchten. Die resultierende Zeile wird in etwa
so aussehen:
password required pam_unix.so nullok obscure min=6 max=11 md5
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. Fügen sie anschliessend die folgene Zeile zu
/etc/pam.d/su/
hinzu:
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.
Wenn sie es nur bestimmten Nutzern erlauben wollen, sich bei einem PAM Service
zu authentifizieren, ist dies sehr leicht zu erreichen, indem sie Dateien
benutzen, in denen die Nutzer, denen es erlaubt ist sich einzulogen (oder
nicht), gespeichert sind. Stellen sie sich vor, sie möchten lediglich dem
Nutzer 'ref' erlauben, sich via ssh einzuloggen. Sie schreiben in also in eine
Datei /etc/ssh-users-allowed
und schreiben das folgende in
/ect/pam.d/ssh
:
auth required pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail
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 Standard-Konfiguration dar (Zugriff wird standardmässig verweigert).
Sie sollten sich wirklich ernsthaft mit dieser Datei beschäfftigen. Hier
können sie ihren Benutzern Resourcen-Limits definieren. Wenn sie PAM
benutzen, wird die Date /etc/limits.conf
ignoriert und sie sollten
/etc/security/limits.conf
stattdessen benutzen.
Wenn sie die Resourcen Nutzung nicht einschränken, kann jeder
Nutzer mit einem einer gültigen Shell auf ihrem System (or sogar ein
Einbrecher, der das System durch einen Service kompomotierte) so viel CPU,
Speicher, Stack etc. benutzen, wie das System zur verfügung stellen kann.
Dieses Problem der Resourcen Überbeanspruchung kann nur mit der
Nutzung von PAM gelöst werden. Beachten sie, dass es einen Weg gibt,
Resourcen Limits zu manchen Shells hinzuzufügen (zum Beispiel hat bash
ulimit
, siehe bash(1)
), aber da nicht alle die
gleichen Limits zur verfügung stellen und da der Nutzer seine Shell
ändern kann (siehe chsh(1)
), ist es besser, die Limits in den
PAM Modulen zu plazieren.
Für mehr Informationen hierzu lesen sie:
Seifried's
Securing Linux Step by Step
in dem Limiting users overview
Abschnitt.
LASG
in dem
Limiting and monitoring users Abschnitt.
FIXME: Get a good limits.conf up here
Der nächste Schritt ist es, die grundlegende Konfiguration und die Actionen bei User Login zu editieren.
FAIL_DELAY 10
Diese Variable sollte auf einen höheren Wert gesetzt werden, um es schwerer zu machen, mittels Brute Force (roher Gewalt, sturres Durchprobieren, Anm. d. Übers.) auf einem Terminal einzuloggen. Wenn ein falsches Passwort eingegeben wird, muss der potentielle Angreifer (aber auch der normale Benutzer!) 10 Sekunden warten, um einen neuen login Prompt zu bekommen, was auf die Dauer viel Zeit kostet, wenn sie Passwörter durchtesten. Beachten sie jedoch die Tatsache, dass diese Einstellung nutzlost ist, wenn sie ein anderes Programm als getty benutzen, wie zum Beispiel mingetty.
FAILLOG_ENAB yes
Wenn sie diese Variable einschalten werden fehlgeschlagene Logins protokoliert. Es ist wichtig hier auf dem laufendem zu bleiben, um jemanden zu fassen, der eine Brute Force Attacke versucht.
LOG_UNKFAIL_ENAB yes
Wenn sie die Varible "FAILLOG_ENAB" auf yes gesetzt haben, dann sollten sie auch diese Variable auf yes setzen. Dies wird auch unbekannte Nutzernamen protokolieren. Wenn sie dies tun, gehen sie auch sicher, dass die Protokolle sinnvolle Zugriffsrechte haben (Zum Beispiel 640, mit einer angemessenen Gruppenzugehörigkeit, wie adm), weil Nutzer oft versehentlich ihr Passwort als Usernamen eingeben und dies anderen nicht zugänglich machen wollen.
SYSLOG_SU_ENAB yes
Dies schaltet das Mitprotokollieren von su
Versuchen im Syslog
ein. Sehr wichtig auf ernsthaften Maschinen, aber beachten sie, dass dies auch
die Privatsphähre verletzen kann.
SYSLOG_SG_ENAB yes
Dasgleiche wie bei SYSLOG_SU_ENAB, jedoch für das Programm
sg
.
MD5_CRYPT_ENAB yes
Wie bereits erklärt, reduzieren MD5-Summen-Passwörter grossartig das Problem lexikalischer Attacken, da sie längere Passwörter benutzen können. Wenn sie slink benutzen, lesen sie die Dokumentation zu MD5 bevor sie diese Option einschalten. Ansonsten wird dies in PAM gesetzt.
PASS_MAX_LEN 50
Wenn sie MD5-Passwörter in ihrer PAM Konfiguration aktiviert haben, dann sollten sie diese Variable auf denselben Wert setzen, den sie dort benutzt haben.
Die Datei /etc/ftpusers
enthält eine Liste von allen Nutzern,
denen es nicht erlaubt ist, sich auf dem host mit ftp einzuloggen. Benutzen
sie diese Datei nur, wenn sie wirklicht ftp erlauben wollen (wozu im
allgemmeinen nicht geraten wird, da es Klartext Passwörter benutzt). Wenn
ihr ftp Daemon PAM unterstützt, können sie dies ebenfalls benutzen,
um Nutzern bestimmte Services zu erlauben oder zu verbieten.
FIXME (BUG): Is it a bug that the default ftpusers in Debian does not
include all the administrative users (in base-passwd
).
Wenn es wirklich benötigt wird, dass Nutzer Super User 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 Nutzer Root vermeiden und stattdessen
ddas Programm su
benutzen. Eigentlich ist es die betste
Lösung su zu entfernen, und zu sudo
zu wechseln, da es mehr
Möglichkeiten bietet als su
. Wie auch immer, su
ist allgemeiner und wird auf vielen Unices benutzt.
Das sudo
erlaubt es dem Benutzer, ein definiertes Kommando unter
einer anderen Nutzer-Identität auszuführen, sogar als Root. Wenn der
Nutzer zu /etc/sudoers
hinzugefüft ist und sich korrekt
authentifiziert ist er in der Lage, Kommandos, die in /etc/sudoers
definiert wurde. Sicherheitsverletzungen, wie ein inkorrektes Passwort oder
der Versuch ein Programm auszuführen, für das ihre Rechte nicht
ausreichen, werden protokolliert und an root gemailt.
Sie sollten /etc/security/access.conf
ebenfalls so modifizieren,
dass ein administrativer Login aus der Ferne nicht erlaubt ist. Auf diese
Weise müssen die Nutzer das Programm su
(oder
sudo
) benutzen, so dass es immer eine prüfbare Spur gibt,
wann immer ein Nutzer administrative Möglichkeiten nutzen möchte.
Sie müssen die folgende Zeile zu ihrer
/etc/security/access.conf
hinzufügen, die Debians
Standard-Konfigurations Datei hat ein Beispiel auskommentiert:
-:wheel:ALL EXCEPT LOCAL
Manchmal werden sie vielleicht denken, dass sie einen Nutzer auf ihrem System erstellen müssen, um einen bestimmten Service (pop3 Email Server oder ftp) anzubieten. Bevor sie dies tun, erinnern sie sich zuerst darad, dass die PAM Implementierung in Debian GNU/Linux ihnen erlaubt, Nutzer mit einer breiten Auswahl von externen Verzeichnisdiensten (radius, ldap, etc.) zu bestätigen. Dies wird vom libpam Paket bewerkstelligt.
Wenn sie einen Nutzer anlegen müssen, und auf ihr System aus der Ferne
zugegeriffen werden kann, beachten sie, dass es Nutzern möglich sein wird,
sich einzuloggen. Sie können dies behebeben, indem sie diesen Nutzer eine
Null (/dev/null
) als Shell (sie müsste in
/etc/shells
gelistet sein) zuweisen. Wenn sie den Nutzern
erlauben wollen, auf das System zuzugreifen, aber ihre Bewegungen
einschränken wollen, können sie /bin/rbash
benutzen, als
ob sie die -r Option der Bash (RESTRICTED SHELL, siehe
bash(1)
) verwendet hätten. Beachten sie bitte, dass sogar
mit einer restricted Shell ein Nutzer, ein Nutzer, der auf ein interaktives
Programm zugreifen kann (dass es ihm erlauben würde, eine subshell
auszuführen), diese Limitierung der Shell umgehen kann.
Debian bietet zur Zeit in seiner unstable Release (und wird es vielleicht der
nächste stable Release hinzufügen) das pam_chroot
Modul.
Eine Alternative hierzu ist es, den Service, der einen Fern-Login anbietet
(ssh, telnet), in einer chroot-Umgebung laufen zu lassen.
Wenn sie einschränken wollen, wann ein Nutzer auf das System
zugreifen kann, müssen sie /etc/security/access.conf
an ihre
Bedürfnisse anpassen.
Debian's sshd wird ihnen nicht erlauben, die Bewegungen eines Nutzer durch den
Server einzuschränken, da er die Chroot Funktionalität, die das
kommerzielle Programm (sshd2) hat (benutzen sie 'ChrootGroups' oder
'ChrootUsers', siehe dazu sshd2_config(5)
). Wie auch immer, es
gibt einen Patch, der ihnen erlaubt dies zu tun, den Patch erhalten sie von
Bug Report 139047
oder
von http://www.cag.lcs.mit.edu/~raoul/
(und er wird wohl in der Zukunft auf das OpenSSH Paket angewendet werden).
Emanuel Lacour hat ssh Paktete mit diesen Fähigkeiten unter http://debian.home-dn.net/woody/ssh/
,
allerdings wird empfohlen durch die Compilierungs-Schritte zu gehen. Eine
Beschreibung von den notwendigen Schritten finden sie unter http://mail.incredimail.com/howto/openssh/
(so ziemlich alles trifft dort auch auf Debian zu, auch wenn von RedHat 7.2 die
rede ist). Nachdem sie den Patch angewendet haben, müssen sie die
/etc/passwd
anpassen, indem sie das Heimat-Verzeichnis des Nutzers
ändern (in den speziellen /./ Token).
joeuser:x:1099:1099:Joe Random User:/home/joe/./:/bin/bash
Dies wird beides einschränken, sowohl remote Zugriff auf die Shell als auch remote Copy über einen ssh Kanal.
Gehen sie sicher, dass sie alle benötigten Binaries in den Chroot-Pfaden für den Nutzer haben. Diese Dateien sollte Root besiutzen, um Einmischungen durch den Nutzer zu verhinern (zum Beispiel die chrooted Sandbox zu verlassen). Ein Beispiel könnte so aussehen:
./bin: total 660 drwxr-xr-x 2 root root 4096 Mar 18 13:36 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. -r-xr-xr-x 1 root root 531160 Feb 6 22:36 bash -r-xr-xr-x 1 root root 43916 Nov 29 13:19 ls -r-xr-xr-x 1 root root 16684 Nov 29 13:19 mkdir -rwxr-xr-x 1 root root 23960 Mar 18 13:36 more -r-xr-xr-x 1 root root 9916 Jul 26 2001 pwd -r-xr-xr-x 1 root root 24780 Nov 29 13:19 rm lrwxrwxrwx 1 root root 4 Mar 30 16:29 sh -> bash ./etc: total 24 drwxr-xr-x 2 root root 4096 Mar 15 16:13 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. -rw-r--r-- 1 root root 54 Mar 15 13:23 group -rw-r--r-- 1 root root 428 Mar 15 15:56 hosts -rw-r--r-- 1 root root 44 Mar 15 15:53 passwd -rw-r--r-- 1 root root 52 Mar 15 13:23 shells ./lib: total 1848 drwxr-xr-x 2 root root 4096 Mar 18 13:37 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. -rwxr-xr-x 1 root root 92511 Mar 15 12:49 ld-linux.so.2 -rwxr-xr-x 1 root root 1170812 Mar 15 12:49 libc.so.6 -rw-r--r-- 1 root root 20900 Mar 15 13:01 libcrypt.so.1 -rw-r--r-- 1 root root 9436 Mar 15 12:49 libdl.so.2 -rw-r--r-- 1 root root 248132 Mar 15 12:48 libncurses.so.5 -rw-r--r-- 1 root root 71332 Mar 15 13:00 libnsl.so.1 -rw-r--r-- 1 root root 34144 Mar 15 16:10 libnss_files.so.2 -rw-r--r-- 1 root root 29420 Mar 15 12:57 libpam.so.0 -rw-r--r-- 1 root root 105498 Mar 15 12:51 libpthread.so.0 -rw-r--r-- 1 root root 25596 Mar 15 12:51 librt.so.1 -rw-r--r-- 1 root root 7760 Mar 15 12:59 libutil.so.1 -rw-r--r-- 1 root root 24328 Mar 15 12:57 libwrap.so.0 ./usr: total 16 drwxr-xr-x 4 root root 4096 Mar 15 13:00 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. drwxr-xr-x 2 root root 4096 Mar 15 15:55 bin drwxr-xr-x 2 root root 4096 Mar 15 15:37 lib ./usr/bin: total 340 drwxr-xr-x 2 root root 4096 Mar 15 15:55 . drwxr-xr-x 4 root root 4096 Mar 15 13:00 .. -rwxr-xr-x 1 root root 10332 Mar 15 15:55 env -rwxr-xr-x 1 root root 13052 Mar 15 13:13 id -r-xr-xr-x 1 root root 25432 Mar 15 12:40 scp -rwxr-xr-x 1 root root 43768 Mar 15 15:15 sftp -r-sr-xr-x 1 root root 218456 Mar 15 12:40 ssh -rwxr-xr-x 1 root root 9692 Mar 15 13:17 tty ./usr/lib: total 852 drwxr-xr-x 2 root root 4096 Mar 15 15:37 . drwxr-xr-x 4 root root 4096 Mar 15 13:00 .. -rw-r--r-- 1 root root 771088 Mar 15 13:01 libcrypto.so.0.9.6 -rw-r--r-- 1 root root 54548 Mar 15 13:00 libz.so.1 -rwxr-xr-x 1 root root 23096 Mar 15 15:37 sftp-server
Wenn sie paranoid sind, dann möchten sie den Nutzern vielleicht eine
definierte .profile
aufzwingen, das die Environments so setzt,
dass sie die Überwachungsmöglichkeiten der Shell nicht entfernen
können (Kommandos werden auf $HISTFILE ausgegeben). Die
.profile
könnte so gesetzt werden:
HISTFILE=/home/_user_/.bash_history HISTSIZE=100000000000000000 HISTFILESIZE=10000000000000000 set -o HISTFILE set -o HISTSIZE set -o HISTFILESIZE export HISTFILE HISTSIZE HISTFILESIZE
Beachten sie: Das -o-Attribut erlaubt nur lesenden Zugriff auf die Variable.
Damit dies funktioniert darf der Nutzer .profile
oder
.bash_history
nicht modifizieren, aber er muss ersteres lesen und
letzteres schreiben können. Sie können dies leicht tun, indem sie
die Dateien und das Verzeichnis, indem sich diese Dateien befinden, so dass sie
einem anderen Benutzer gehören (root), und For this to work the user
cannot modify the .profile
, und der Gruppe des Nutzers auf die
History-Datei Schreibzugriff gewähren. Eine andere Möglichkeit ist
es, dass Programm chattr
zu benutzen.
Wenn sie wirklich paranoid sind und jedes Kommando des Nutzers protokollieren
wollen, könnten sie den Quellcode der Bash nehmen, ihn ändern und sie
alles, das der Nutzer eingibt in einer anderen Datei ausgibt. Oder sie lassen
ttysnoop
konstant jedes neue tty überwachen und die Ausgaben
in einer Datei ausgeben. Ein anderes nützliches Programm ist Snoopy
. Dies
ist ein für den Nutzer transparentes Programm, dass sich als eine
Bibliothek zwischen hängt, und eine Hülle um execve() Aufrufe bildet,
jedes ausgeführte Kommando wird im syslogd aufgezeichnet, indem die
authpriv-Möglichkeit benutzt wird (üblicherweise wird
dies unter /var/log/auth.log
gespeichert).
Beachten sie, dass sie hierfür nicht das script
Kommando
benutzen können, da sies nicht als Shell funktionert (auch nicht, wenn sie
es zu /etc/shells
hinzufügen).
Die vorherigen Beispiele sind ein einfacher Weg, um Nutzer Überwachung zu
konfigurieren, eignet sich aber nicht unbedingt für komplexe Systeme.
Sollte dies der Fall sein, schauen sie sich das Paket acct
, die
accounting Utilities, an. Diese werden alle Kommandos, die ein Nutzer oder ein
Prozess auf dem System ausführt, auf die Kosten von Plattenplatz
aufzeichnen.
Wenn sie diese 'Buchführung' aktivieren, werden alle Informationen
über Prozesse und Nutzer unter /var/account/
gehalten. Das
Accounting-Paket schließt Werkzeuge (sa
und ac
)
zur Analyse dieser Daten ein.
Wenn sie sehen wollen, was Nutzer normalerweise tun, wenn sie sich
verbinden, können sie die wtmp
Datenbank benutzen, die alle
Login-Informationen enthält. Diese Datei kann mit verschiedenen
Werkzeugen weiterverarbeitet werden, unter ihnen sac
, das ein
Profil für jeden Nutzer ausgeben kann, dass zeigt, in welchem Zeitfenster
sie sich für gewöhnlich auf dem System einloggen.
Für den Fall, dass sie accounting aktiviert haben, können sie auch die mitgelieferten Werkzeuge verwenden, um festzustellen, wann Nutzer auf das System zugreifen und was sie ausführen.
Abhängig von ihrer Richtlinien möchten sie vielleicht ändern,
wie Nutzer Informationen teilen können, was die Standardrechte von neu
erstellten Dateien sind. Dies ändern sie, indem sie eine passende
umask f¨r alle Nutzer einstellen. Sie können sie
UMASK-Einstellung in /etc/limits.conf
, /etc/profile
,
/etc/csh.cshrc
, /etc/csh.login
,
/etc/zshrc
und wahrscheinlich auch noch andere (abhängig von
den Shells, die sie auf ihrem System installiert haben). Von all diesen hat
die zuletzt geladene Vorrang: PAM's limits.conf, die standard System
Konfiguration für die Shell des Nutzers, die Shell des Nutzers (sein
~/.profile
), ~/.bash_profile
...)
Debian's default umask Einsztellung is 022, d.h., dass
Dateien (und Verzeichnisse) von Nutzer aus der Gruppe und jedem anderen Nutzer
des Systems lesbar und zugreifbar sind. Wenn dies zu grosszügig für
ihr System ist, müssen sie die umask Einstellung für alle Shells (und
für PAM) ändern. Vergessen sie nicht die Dateien unter
/etc/skel/
anzupassen, da dort die die Standards für Nutzer
werden, wenn sie mit dem adduser
Kommando erstellt werden.
Beachten sie, dass ein Nutzer immernoch seine umask Einstellung abändern kann, wenn sie es möchten, um sie grosszügiger oder einschränkender zu machen.
FIXME: Content needed. Tell of consequences of changing packages permissiones when upgrading (and admin this paranoid should chroot his users BTW).
Wenn sie einem Nutzer Zugriff auf das System mit einer Shell gewähren müssen, bedenken sie es vorsichtig. Ein Nutzer kann normalerweise, wenn er nicht in eine streng abgeschirmte Umgebung (wie chroot) gesetzt wird, ziemlich viel Informationen von ihrem System sammeln, darunter:
/etc
. Jedoch werden Debian's
Standard Rechte auf sensitive Dateien (die zum Beispiel Passwörter
enthalten könnten) den Zugriff auf kritische Informationen verhindern. Um
zu sehen, auf welche Dateien nur der root Nutzer zugreifen kann, führen
sie zum Beispiel find /etc -type f -a -perm 600 -a -uid 0 als
superuser aus.
/usr/share/doc
Verzeichnisses oder durch raten, indem man die
Binaries und Bibliotheken durchsieht, die auf ihrem System installiert sind.
/var/log
. Beachten sie, das auf einige
Protokolle nu root und die adm Gruppe zugreifen kann (versuchen
sie find /var/log -type f -a -perm 640) und manche sind sogar
ausschliesslich für root verfügbar (versuchen sie some logfiles at
/var/log
. Note also that some find /var/log -type f -a
-perm 600 -a -uid 0).
Was kann ein Nutzer 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
Was sie sehen ist eine Liste von allen Dateien, die ein Nutzer einsehen, und die Verzeichnisse, auf die er Zugriff hat.
TCP-Wrapper (Schurtzumschläge für TCP) wurden entwickelt, als es noch
keine echten Paket-Filter gab, aber Zugsngskontrollen notwendig waren. Ein
TCP-Wrapper erlaubt ihnen, einem Host oder einer Domain einen Service zu
erlauben oder zu verweigern und default-mässig Zugriff zu erlauben oder zu
verweigern. Wenn sie mehr Informationen haben möchten, sehen sie sich
hosts_access(5)
an.
Viele der unter Debian installierten Services
tcpd
) aufgerufen
Einerseits werde manche Services, einschliesslich telnet, ftp, netbios, swat
und finger in /etc/inetd.conf
konfiguriert. Sie sehen es daran,
dass die Konfigurations-Datei zuerst /usr/sbin/tcpd
aufruft.
Andererseits, selbst wenn ein Service nicht über den
inetd
-Superdaemon ausgeführt wird, kann es in jedem Fall, den
TCP-Wrapper-Regeln unterworfen werden, indem man die Unterstützung
dafür einkompiliert. Services, die unter Debian mit TCP-Wrappern
compiliert wurden, schliessen ssh, portmap, in.talk, roc.statd, rpc.mountd,
gdm, oaf (der GNOME-Aktivierungs daemon), nessus und viele andere ein.
Um herauszufinden, welche Pakete TCP-Wrapper benutzen, versuchen sie folgendes:
$ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \ sed 's/,libwrap0$//;s/^[[:space:]]\+//'
Beachten sie bitte folgendes, wenn sie tcpchk
laufen lassen: Sie
können Services, die gegen dei Wrapper-Bibliothek kompiliert wurden, der
host.deny
oder host.allow
Datei hinzufügen, aber
aber tcpchk
wird sie warnen, dass er sie nicht finden kann, da er
sie in /etc/inetd.conf
sucht (die Manual-Seite 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 [5] Kommando in /etc/hosts.deny
einzutragen, das
immer dann eine Mail an root schickt, wenn der Wrapper eines abgewiesenden
Services ausgelöst wurde:
ALL: ALL: SPAWN ( \ echo -e "\n\ TCP Wrappers\: Verbindungsaufbau abgelehnt\n\ By\: $(uname -n)\n\ Prozess\: %d (pid %p)\n\ Nutzer\: %u\n\ Host\: %c\n\ Datum\: $(date)\n\ " | /usr/bin/mail -s "Verbinung zu %d blockiert" root) &
Beachten Sie: Das obige Beispiel kann sehr leicht geDoSet (Denial of Service, Verbindungsaufbau abgelehnt) werden, indem man versucht, sehr viele Verbindungen in kurzer Zeit aufzubauen. Viele Emails bedeuten viel Datei-Aktivitöt, lediglich erreicht durch das Senden von ein paar Paketen.
Wie Logs (Protokolldateien) und Alarme in einem sicheren System behandelt werden ist eine wichtige Angelegenheit. Es ist leicht zu verstehen, dass selbst wenn ein System angeblich perfekt konfiguriert und zu 99% sicher ist, es immer noch 1% Restrisiko gibt, für die keine Sichereheitsmaßnamen greifen. Als erstes gillt es, Angriffe auf diese 1% zu erkennen und als zweites Alarm auszuölösen, oder das System ist in keinster Weise sicher.
Debian GNU/Linux stellt Tools zur Verfügung, die die Analyse von
Log-Dateien übernehmen, am beachtenswertesten logcheck
oder
loganalysis
(beide Pakete werden ein wenig Anpassung
benötigen, um unnötige Dinge aus den Reports zu entfernen). Wenn
sich das System in der Nähe befindet, könnte es nützlich sein,
das System-Log 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
kommt
mit einer kommentierten Standard-Konfiguration. Um diese Ausgabe
einzuschalten, unkommentieren Sie die 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
Es gibt da noch einiges über Log-Analyse, das hier nicht behandelt werden
kann. Eine gute Quelle für weiter Informationen ist Counterpane's Log Analysis
Resources
. In jedem Fall sind selbst automatische Tools dem besten
Tool nicht gewachsen: Ihrem Gehirn.
Das Programm logcheck
ist in Debian in zwei Pakete aufgeteilt:
logcheck
(das Haupt-Programm) und logcheck-database
(eine Datenbank regulärer Ausdrücke für das Programm). Der
Standard unter Debian (unter /etc/cron.d/logcheck
) ist, dass
logcheck
jeweils um 14:00 Uhr und nach jedem Neustart
ausgeführt wird.
Dieses Tool kann sehr nützlich sein, wenn es geeignet angepasst wurde, 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 Logs sendet, die Ihrer
Aufmerksamkeit bedürfen. Die Standard-Installation umfasst Profile zum
ignorieren von Ereignissen und Regelwidrigkeiten für drei unterschiedliche
Setups (Workstation, Server und paranoid). Das Debian-Paket umfasst eine
Konfigurations-Datei /etc/logcheck/logcheck.conf
, die vom Program
eingelesen wird, die definiert, an welchen Nutzer die Testergebnisse geschickt
werden sollen. Es stellt ausserdem einen Weg für Pakete zur
Verfügung, um neue Regeln in den Verzeichnissen zu realisieren:
/etc/logcheck/hacking.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 Nutzer nützlich sein könnte, senden Sie bitte einen
Bug-Report für das ensprechende Paket (als ein wishlist-Bug).
Mehr Informationen finden Sie unter
/usr/share/doc/logcheck/README.Debian
.
Der beste Weg logcheck
zu konfigurieren ist es, es einfach zu
installieren (Sie werden gefragt werden, an welchen Nutzer die Mail-Reports
geschickt werden soll, und ob aus den Einträgen im Syslog wird ein
/etc/logcheck/logcheck.logfiles
generiert werden soll). Wenn Sie
andere Logfiles hinzufügen möchten, ändern Sie einfach
/etc/logcheck/logcheck.logfiles
indem Sie sie hinzufügen.
Die Paket-Abhängigkeiten werden dafür sorgen, dass
logcheck-database
auch installiert wird. Während der
Installation werden Sie gefragt, welches Sicherheits-Niveau benötigt wird:
workstation, server oder paranoid. Dadurch wird
/etc/logcheck/ignore.d
(durch einen symbolischen Link) auf die
richtigen Verzeichnisse zeigen. Um dies zu ändern führen Sie
dpkg-reconfigure -plow logcheck-database aus. Erstellen Sie dann
eine Datei /etc/ignore.d/local
; diese Datei enthält alle
Regeln, Meldungen auszuschliessen, die nicht gemeldet werden sollen. Lassen
Sie es für den Anfang leer (ein einfaches cp /dev/null
/etc/ignore.d/local sollte reichen).
Wenn Sie dies einmal geschafft haben, sollten Sie die nächtsen
Tage/Wochen/Monate die verschickten Mails prüfen, ob Sie Meldungen
geschickt bekommen, die Sie nicht erhalten wollen. Fügen Sie dann einen
entsprechenden regulären Ausdruck (siehe regex(7)
) zu
/etc/ignore.d/local
. Die ist ein andauernder Tuning-Pozess. Wenn
nur noch relevante Meldungen verschickt werden, können Sie davon ausgehen,
dass dieser Prozess beendet ist. Beachten Sie, dass Logcheck Ihnen keine Mail
schickt, wenn es nichts relevantes auf Ihrem System findet, selbst wenn es
läuft (so bekommen Sie höchstens eine Mail pro Woche, wenn Sie
Glück haben).
Debian kommt mit einer Standard-Konfiguration für Syslog (in
/etc/syslog.conf), so dass Meldungen je nach System in die passenden Dateien
geschrieben werden. Das sollte Ihnen bereits bekannt sein, werfen Sie einen
Blick auf die Datei syslog.conf
und deren Dokumentation, falls
nicht. Wenn Sie ein sicheres System pflegen wollen, sollten Ihnen bekannt
sein, wohin Log-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 sehr wichtig, auch eine neue Maschine zu nehmen, die für die anderen als ein Loghost fungieren wird (d.h. sie empfängt die Logs aller anderen Systeme).
Sie sollten auch an Mails für Root denken, da viele Sicherheits-Kontrollen
(wie snort
) ihre Alarme an die mailbos von root senden. Diese
Mailbos zeigt normalerweise an den ersten Nutzer, der auf dem System erstellt
wurde (prüfen Sie dazu /etc/aliases
). Sorgen Sie dafür,
dass roots Mails irgendwo hin geschickt wird, wo sie auch gelesen werden
(entweder lokal oder ferngesteuert).
Es gibt noch andere Accounts besonderer Funktion und andere Aliase auf Ihrem System. Auf einem kleinen System ist es wohl am einfachtes, sicherzustellen, dass alle Alias auf den Root-Account zeigen, und dass Mails an root in das persönliche Postfach des System-Administrator 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:
snmptraglogd
, snmp
and snmpd
.
Ein Loghost ist ein host der die syslog-Daten über ein Netzwerk sammelt.
Wenn eine Ihrer Maschinen gecracked wird, kann der Eindringling seine Spuren
nicht verwischen, solange er den Loghost nicht ebenfalls gecracked hat.
Demzufolge muss der Loghost also besonders sicher sein. Aus einer Maschinen
einen Loghost zu machen ist relativ einfach: Starten Sie den syslogd einfach
mit 'syslogd -r', und ein neuer Loghost ist geboren. Um dies unter Debian
permanent zu machen, editieren Sie /etc/init.d/sysklogd
und
änder Sie die Zeile
SYSLOGD=""
in
SYSLOGD="-r"
Als nächstes konfigurieren Sie die anderen Machinen, 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 fern mitloggen wollen, schreiben sie einfach:
*.* @Ihr_Loghost
in Ihre syslog.conf
. Sowohl lokal als auch entfernt mitzuloggen
ist die beste Lösung (ein Angreifer könnte davon ausgehen, dass er
seine Spuren verwischt hat, nachdem er die lokale Logdatei gelöscht hat).
Sehen Sie für weitere Informationen die Handbuch-Seiten
syslog(3)
, syslogd(8)
und
syslog.conf(5)
.
Es ist nicht nur wichtig zu entscheiden, wie Warnungen genutzt werden, sondern auch, wer hierauf zugriff hat, d.h. wer Log-Dateien (fall Sie nicht einen Log-Host verwenden) lesen oder verändern kann. Sichereheits-Alarme, die ein Attacker verändern oder abschalten kann, sind im Falle eines Eindringens nicht viel wert. Ausserdem sollten Sie berücksichtigen, dass Log-Dateien einem Eindringling sehr viel Informationen über Ihr System enthüllen kann und welche normalen (und annormalen) Operationen er ausführen kann, wenn er darauf Zugriff hat.
Ein Paar Zugriffsrechte auf Log-Dateien sind nach der Installation nicht gerade
perfekt (aber das hängt natürlich von Ihrer lokalen
Sicherheits-Policy ab). Zuerst einmal müssen
/var/log/lastlog
und /var/log/faillog
nicht für
normalen Nutzer lesbar sein. In der lastlog-Datei können Sie sehen, wer
sich zuletzt eingeloggt hat, und in faillog eine Zusammenfassung
fehlgeschlagener Logins. Der Author empfiehlt beides auf 660 zu chmod'en.
Werfen Sie einen kurzen Blick auf Ihre Log-Dateien, und entscheiden Sie sehr
vorsichtig, welche Log-Dateien sie les- oder schreibbar für einen Nutzer
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 (zeigt zu welchen Nutzern /var/log gehört) # find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u (zeigt zu welchen Gruppen /var/log gehört) # find /var/log -perm +004 (zeigt, welche Dateien von jedem Nutzer gelesen werden können) # find /var/log \! -group root \! -group adm -exec ls -ld {} \; (zeigt, welche Dateien zu anderen Gruppen als root oder adm gehört)
Um anzupassen, wie neue Log-Dateien erstellt werden, müssen Sie wahrscheinlich das Programm anpassen, dass sie erstellt. Wenn die Log-Dateien rotiert werden, können Sie das Verhalten bei der Erstellung und Rotation anpassen.
chroot
chroot
ist eine der mächtigsten
Möglichkeiten einen Daemon, einen Nutzer oder einen anderen Service
einzuschränken. Stellen Sie sich einfach ein Gefängnis um Ihr Ziel
vor, aus dem Ihr Ziel nicht ausbrechen kann (Normalerweise, aber es gibt
immernoch ein paar Bedinungen, unter denen es erlaubt es, aus einem solchen
Gefängnis auszubrechen). Wenn Sie einem Nutzer nicht trauen können
Sie ihm eine Change-Root-Umgebung erstellen. Dies kann zwar einiges an
Platten-Platz verbrauchen, da Sie alles benötigte Ausführbare in das
Geföngnis kopieren müssen, ebenso wie alle Bibliotheken. Sogar wenn
der Nutzer etwas boshaftes anstellt, ist der Schadensrahmen auf das
Gefängnis beschränkt.
Ein gutes Beispiel für diesen Fall ist es, wenn Sie nicht mit
/etc/passwd
authentifizieren, sondern stattdessen LDAP oder MySQL
verwenden. So benötigt Ihr ftp-Daemon lediglich ein Binary und vielleicht
ein paar Bibliotheken. Ein ge-chroot-ete Umgebung wäre eine exzellente
Sicherheits-Umgegung; wenn ein neuer Exploit für diesen ftp-Daemon bekannt
wird kann ein Angreifer nur die Nutzer-ID (User-ID, UID) des internen
ftp-Daemon-Nutzers ausnutzen und nichts anderes.
Natürlich kann auch die Sicherheit ander Daemonen von einem solchen Arrangement profitieren.
Seien Sie jedoch vorgewarnt, dass man auch aus einem
chroot
-Gefängnis ausbrechen kann, wenn der Nutzer, der es
laufen lässt der Superuser ist. Also ist es notwendig, dass Sie den
Service als nicht privilegierter Nutzer laufen lassen. Indem Sie die Umgebung
einschränken, schränken Sie die für alle les- /
ausführbaren Dateien, auf die das System Zugriff hat, und so verkleinern
Sie die Möglichkeit einer Ausweitung der System-Privilegien indem lokale
Verwundbarkeiten der Systemsicherheit ausgenutzt werden. Aber sogar in dieser
Situation können Sie nicht wirklich sicher sein, dass es für einen
cleveren Angreifer keinen Weg gibt, irgendwie aus dem Gefängnis
auszubrechen. Es ist eine zusätzliche Sicherheitsmassnahme nur
Server-Programme zu benutzen, die einen gewisse Reputation in Sachen Sicherheit
haben. Sogar die kleinste Lücke, wie eine offene Behandlung von Dateien
kann von einem geschickten Angreifer genutzt werden, um in das System
einzubrechen. Schliesslich wurde chroot
nicht als
Sicherheits-Werkzeug designed, sondern als Test-Werkzeug.
Eine zusätzliche Anmerkung: BIND (Berkeley Internet Name Domain) ist standardmässig unter Debian nicht ge-chroot-et. Tatsächlich ist dies bei keinem Daemon der Fall.
Es gibt übrigens Software (derzeit nicht unter Debian, aber in der Zukunft
sollte sie paketiert sein), die helfen Kann, eine chroot-Umgebung einzurichten.
Zum Beispiel kann makejail
mit sehr kleinen Konfigurations-Dateien
chroot-Gefängnisse erstellen und aktualisieren. Es versucht ausserdem
alle für den Daemon benötigten Dateien zu erraten und in dem
Gefängis zu installieren. Mehr Informationen finden Sie unter http://www.floc.net/makejail/
.
Jailer
ist ein ähnliches Werkzeug, dass Sie unter http://www.balabit.hu/downloads/jailer/
erhalten.
Für das erstellen von chroots (oder Gefänsnissen) ist ausserden
deb.pl
, ein Skript das die Abhängigkeiten ein oder mehrerer
Dateien analysiert.
FIXME: Content missing
Viele Fähigkeiten des Kernels können im laufenden Betrieb
verändert werden, indem man etwas in das /proc
-Datei-System
echo-t oder indem man sysctl benutzt. Geben Sie sysctl -A ein, um
zu sehen, was Sie konfigurieren können und wie die Optionen hierfür
sind. Nur in selten Fällen müssen Sie hier etwas verstellen, aber
Sie können auf diese Art auch die Sicherheit erhöhen.
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. Anderenfalls macht es gar nichts.
net/ipv4/icmp_echo_ignore_all = 0
Wenn Sie kein ICMP auf Ihrer Firewall blockieren wollen, schalten Sie dies ein.
net/ipv4/tcp_syncookies = 1
Diese Option ist ein zweischneidiges Schwert. Auf der einen Seite schützt
es Ihr System gegen überfluten von syn-Paketen, auf der anderen Seite
verletzt es definierte Standards (RFCs). Diese Option ist recht dumm , da es
die Gegenseite ebenso flutet wie Sie, so dass die Gegenseite auch
beschäfftigt ist. Wenn Sie diese Option ändern wollen, können
Sie es auch in /etc/network/options
ändern, indem Sie
syncookies=yes setzten.
/proc/sys/net/ipv4/conf/all/log_martians = 1
Packete mit unmöglichen Adressen (erzeugt durch falsche Routen) in Ihrem Netzwerk werden protokolliert.
Hier ist ein Beispiel wie man dies und andere nützliche Sachen setzen
kann. Sie sollten diese Informationen zu einem Skript
/etc/network/interface-secure
(der Name kommt aus einem Beispiel)
hinzufügen , und es durch /etc/network/interfaces
wie
nachfolgend gezeigt aufrufen lassen:
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
# Skript-Name: /etc/network/interface-secure # Modifiziert das normale Verhalten um uns gegen manche TCP/IP Attacken # und Manipulationen zu schützen # # beigetragen von Dariusz Puchalak # echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # Rundruf-Antwort-Schutz # einscahlten echo 0 > /proc/sys/net/ipv4/ip_forward # ip-Weiterleutung abschalten echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP-Syn-Cookie Schutz einschalten echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Packete mit unmöglichen # Adressen logen, seien Sie # hiermit auf ausgelasteten # Webservern vorsichtig echo 1 > /proc/sys/net/ipv4/ip_always_defrag # Defragmentierungs-Schutz # immer einschalten echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses # Schutz vor schlechten # Fehlermeldungen einschalten # Jetzt kommt Schutz vor ip-Spoofing for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done # und schliesslich noch ein paar andere Sachen: # Akzeptieren von umgeleitetet ICMP abschalten for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do echo 0 > $f done for f in /proc/sys/net/ipv4/conf/*/send_redirects; do echo 0 > $f done # Abschalten von Source Routed Packets for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do echo 0 > $f done # Logen von gespooften Paketen, Source Routed Paketen und Redirect # Paketen for f in /proc/sys/net/ipv4/conf/*/log_martians; do echo 1 > $f done
Um die Möglichkeiten einer Firewall zu haben, um entweder das lokale
System oder andere dahinter zu beschützen, muss der Kernel mit
Firewall-Unterstützung compiliert worden sein. Der standard Debian 2.2
Kernel (also der Kernel-Version 2.2) stellt die Paket-Filter-Firewall
ipchains
zur Verfügung, der Debian 3.0 Standard Kernel
(Version 2.4) stellt die stateful Oaket-Filter iptables
(netfilter) Firewall zur Verfügung. Ältere Debian Distributionen
würden einen passenden Kernel-Patch (Debian 2.1 nutzte Kernel 2.0.34)
benötigen.
In jedem Fall ist es recht einfach einen anderen, als den von Debian
installierten Kernelzu benutzen. Sie finden vor-compilierte Kernel als Pakete,
die Sie leicht auf Ihrem Debian System installieren können. Sie
können auch die Kernel-Quellen downloaden, indem Sie das Paket
kernel-source-X
installieren, und Ihren eigens angepassten Kernel
compilieren, indem Sie make-kpkg
benutzen.
Auf das Aufsetzen einer Firewall unter Debian wird unter Hinzufügen von Firewall Fähigkeiten, Abschnitt 5.15 ausführlich eingegangen.
FIXME: More content
Debian GNU/Linux stell verschiedene Patches für den Linux-Kernel zur Vergügung, die die Sicherheit erhöhen:
lids-2.2.19
)
lcap
)
trustees
)
selinux
, auch verfügbar von
der Seite des
Paket-Betreuers
)
kernel-patch-2.2.19-harden
kernel-patch-freeswan
)
kernel-patch-int
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 auf Work Needing and
Prospective Packages
nach ihnen. Ein paar von Ihnen sind:
Speicher-Überlauf werde die Attacken über Software genannt, die unzureichende Überprüfung von Eingabegrenzen (ein häufiger Programmierfehler) ausnutzen, um durch Programm-Eingaben Befehle auf der Maschine auszuführen. Diese Attacken über Server, die auf Verbindungen warten, oder über lokal installierte Software, die einem Nutzer grössere Privilegien gewährt (setuid oder setgid) kann zu einem kompromitierten System führen.
Es gibt hauptsächlich vier Methoden, um sich gegen Speicher-Überläufe zu schützen:
hier
).
Debian GNU/Linux liefert bis einschliesslich der Release 3.0 lediglich Software
um die erste und die letzte dieser Methoden zu implementieren (Kernel-Patch und
Werkzeuge um mögliche Speicher-Überläufe zu finden). Zur
Nutzung dieser Werkzeuge zum aufsprühren von Speicher-Überläufen
benötigen Sie in jedem Fall Programmier-Erfahrung, um den Quellcode zu
reparieren (und neu zu compilieren). Debian stell beispielsweise
bfbtester
(einen Überlauf-Tester, der Programe per
brute-force (durchtesten aller Möglichkeiten) auf Kommado-Zeile und
Umgebungs-Variablen durchtestet) und njamd
zur Verfügung.
Was Kernel-Patches (beschrieben im Abschnitt Den
Kernel patchen, Abschnitt 4.13) betrifft, so stellt der Openwall-Patch
Schutz gegen Speicher-Überläufe in 2.2er Linux-Kerneln zur
verfügung, während Sie für 2.4er Kernel den Grsecureity-Patch
(im Paket kernel-patch-2.4-grsecurity
enthält neben vielen
anderen Sachen (ACLs, Zufälligkeiten im Netzwerk, und es zu erschweren das
Betriebssystem zu erraten) auch den Openwall-Patch, siehe features
) oder die
Linux-Sicherheits-Module (in den Paketen kernel-patch-2.4-lsm
und
kernel-patch-2.5-lsm
) benutzen müssen.
Seien Sie in jedem Fall gewarnt, dass selbst diese Problemumgehungen nicht vor
Speicher-Überläufen schützen lännen, da es wiederum
Möglichkeiten gibt diese zu umgehen, wie es in Ausgabe
58
des phrack-Magazins beschrieben wurde.
Während der normalen System-Administration 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 wird duch die Benutzung
des Paketes sshd
erreicht. Eine andere Möglichkeit ist die
Nutzung von ftpd-ssl
, einem ftp-Server der Secure Socket
Layer benutzt, um transmissionen 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 komplett verschlüsselt, so dass die bösen
Jungs nocht nicht einmal herausbekommen können, WAS Sie kopieren.
Wie es den Server gibt, so gibt es natürlich 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.
Es ist wichtig eine gute Quota-Regelung zu haben, da es die Nutzer daran hindert, die Festplatten zu füllen.
Sie können zwei Arten von Quota-Systemen benutzen: Nutzer-Quota und Gruppen-Quota. Wie Sie sicher denken können, limitiert User-Quota den Plattenplatz, den ein Nutzer belegen kann, und Gruppen-Quota macht dasselbe für ganze Gruppen. Beachten Sie dies, wenn Sie die Grössen der Quotas festlegen.
Es ein paar wichtige Punkte, über die Sie nachdenken sollten, wenn Sie ein Quota-System aufsetzen:
/home
ebenso wie auf /tmp
.
Auf jeder Partition/jedem Verzeichniss, auf dass Nutzer Schreibzugriff haben, sollten quotiert sein. Finden Sie diese Partitionen udn Verzeichnisse und schätzen Sie eine sinnvolle Quota-Grösse, die Nutzbarkeit und Sicherheit kombiniert.
So, nun wollen Sie Quotas benutzen. Zuerst müssen Sie prüfen, ob Ihr
Kernel Quota unterstützt. Wenn nicht müssen Sie ihn neu compilieren.
Prüfen Sie anschliessen, ob das Paket quota
isntalliert ist.
Wenn nicht, installieren Sie es.
Um Quota für die entsprechenden Dateisysteme einzuschalten müssen Sie
nur die Einstellung defaults in Ihrer Datei
/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 lere Dateien 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 ein /etc/init.d/quota stop;/etc/init.d/quota start ausführen. Nun sollte quota laufen, und die Grössen können festgelegt werden.
Bearbeiten der Quotas eines bestimmten Nutzer (sagen wir mal "ref") wir mit edquota -u ref gemacht. Gruppen-Quotas können mit edquota -g <group> geändert werden. Setzen Sie dann die weiche und die harte Grenze und/oder inode-Quotas, wenn Sie es benötigen.
Mehr Informationen über Quotas finden Sie in der Manual-Seite von quota,
und der quota Mini-Howto
(/usr/share/doc/HOWTO/en-html/mini/Quota.html
).
Sie könnten auch lshell
mögen, oder auch nicht, da es
den FHS verletzt. Beachten Sie ausserdem dass pam_limits.so diegleiche
Funktionalität zur Verfügung stellen kann und das lshell
Paket zur Zeit verwaist
ist.
Diesen beiden Befehle sind sehr nützlich, aber Sie arbeiten nur auf ext2 Dateisystemen. Mit 'lsattr' können Sie die Attributen einer Datei anzeigen lassen und mit 'chattr' können Sie sie ändern. Beachten Sie, dass Attribute nicht dasselbe sind, wie Zugriffsrechte. Es gibt viele Attribute, aber nur die wichtigsten, die die Sicherheit erhöhen, werden hier erwähnt. Es gibt zwei Kennzeichnungen (flags), die nur der Superuser setzen kann.
Zunächst gibt es das 'a' Flag. Wenn dieses bei einer Datei gesetzt ist,
dann kann an diese Datei nur angehängt werden. Dieses Attribut ist
für einige Dateien in /var/log/
nützlich, beachten Sie
aber, dass durch Log-Rotations-Skripte Dateien manchmal verschoben werden.
Das zweite Flag ist das 'i'-Flag, kurz für immutable also unveränderlich. Wenn Sie eine Datei so behandeln, kann Sie weder modifiziert, noch gelöscht, noch umbenannt werden, oder verlinkt werden. Wenn Sie nicht möchten, dass Nutzer einen Blick auf Ihre Konfigurations-Dateien werfen können, setzen Sie dieses Flag, und entfernen Sie die Lesbarkeit. Zusätzlich bietet es Ihnen etwas mehr Sicherheit gegen Eindringlinge, da ein Cracker dadurch verwirrt werden könnte, wenn er eine Datei nicht verschieben kann. Dennoch sollten Sie nicht davon ausgehen, dass ein Cracker von Blindheit geschlagen ist, immerhin ist er in Ihr System eingedrungen.
Zusätzlich können Sie die Programme chattr
und
lsattr
von Ihrem System entfernen, so dass ein Eindringling mit
root-Zugang diese Attribute nicht verändern (oder auflisten) kann. Da Sie
Teil von e2fsprogs
sind und dieses die Priorität
required hat, können Sie das Paket nicht einfach entfernen. Sie
können jedoch diese beiden Applikationen (und wahrscheinlich noch andere)
einfach läschen. Kopieren Sie sie vorher auf einen auswechselbaren
Datenträger (Diskette?) zusammen mit ihrem md5-Summen.
Ein Eindringling auf ihrem System müsste so erst eigene Kopien dieser Programme herunterladen (wahrscheinlich sogar selbst compilieren), so dass Sie etwas mehr Zeit bekommen, den Angriff zu erkennen und die Komprimitierungen rückgängig zu machen, bevor das gesamte System überrannt wird.
FIXME: This is a bug that could be reported, are any of the binaries provided
by the program useful in production systems? If not, and since the libraries
are needed by many packages a new package e2fsprogs-utils
could be
included with less than Required priority.
Vergessen Sie nicht: chattr
und lsattr
sind nur
für das Dateisystem ext verfügbar.
Sind Sie sicher, dass /bin/login
auf Ihrer Festplatte immernoch
dasselbe Programm ist, dass Sie vor ein paar Monaten installiert haben? Was
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 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 eta 1 zu 3,4e3803), so sind Sie sicher, solange niemand
den Algorithmus gehackt hat, der die md5-Summen auf Ihrer Maschine erstellt.
Dies ist, nunja, extrem schwer und sehr unwahrscheinlich. Sie sollten diese
Überprüfung Ihrer Programme als sehr wichtig ansehen. Weit
verbreitete Tools hierfür sind sXid
, AIDE
(Advanced Intrusion Detection Environment, fortgeschrittene Eindringlings
Erkennungs Umgebung), TripWire
(non-free; die neue Version wird
GPL lizensiert), 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
geändert werden können.
Weiterhin können Sie locate
durch slocate
ersetzen. slocate ist eine um Sicherheit erweiterte Version von GNU locate.
Wenn Sie slocate benutzen, sieht ein Benutzer nur Dateien, auf die er auch
zugriff hat, während Sie alle Dateien und Verzeichnisse des gesamten
Systems ausschliessen können.
FIXME: put references to the snapshot taken after installation.
FIXME: Add a note regarding packages not providing debsums for all apps installed (not mandatory).
Debian liefert einen täglich ausgeführten Cron-Job
/etc/cron.daily/standard
. Dieser Cron-Job führt das Skript
/usr/sbin/checksecurity
, das Informationen über
Änderungen sichert.
Damit dieser Check ausgeführt wird, müssen Sie in
/etc/checksecurity.conf
CHECKSECURITY_DISABLE="FALSE" setzen. Dies ist bereits
der Standardwert, so dass diese Option bereits aktiviert sein sollte, solange
Sie nichts geändert haben.
Das Standard-Verhalten sendet diese Informationen nicht an den Superuser,
stattdessen hält es eine tägliche Kopie dieser Änderungen unter
/var/log/setuid.changes
. Sie sollten CHECKSECURITY_EMAIL (in
/etc/checksecurity.conf
) auf 'root' setzen, damit diese
Informationen an ihn gemailt werden. Sehen Sie auch
checksecurity(8)
für weitere Konfigurations-Informationen.
Bevor Sie das System in eine produktive Umgebung stellen, können Sie einen Schnappschuss des gesamten Systems machen. Diesen Schnappschuss können Sie im Falle einer Kompromitierung (siehe Nach einer Komprimitierung, Kapitel 10) benutzen. Sie sollten so einen Schnappschuss immer dann erneuern, wenn Sie das System upgraden, insbesondere wenn Sie auf eine neue Debian Release upgraden.
Hierfür können Sie beschreibbare, austauschbare Datenträger benutzen, die Sie schreibschützen können. Dies kann eine Diskette sein (die nach der Benutzung schreibgeschützt wird) oder eine CD in einem CD-ROM Laufwerk (sie können auch wieder beschreibbare CD-ROMs benutzen, so können Sie sogar alte Sicherheitskopien Ihrer md5-Summen behalten).
Das folgende Skript erstellt einen solchen Schnappschuss:
#!/bin/bash /bin/mount /dev/fd0 /mnt/floppy /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 /bin/umout /dev/fd0 echo "md5 Datenbank (nach der Installation) erstellt"
Beachten Sie, dass das Programm md5sum auch auf der Diskette gesichert wird, so dass Sie es später benutzen können, um die anderen Programme Ihres Systems zu prüfen (gesetz dem Fall das md5sum einen Trojaner enthält).
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:
Sobald der Schnappschuss erstellt wurde sollten Sie sicherstellen, dass das entsprechende Medium schreibgeschützt ist. Sie können dann eine Sicherheitskopie erstellen, oder es jede Nacht benutzen, um die md5-Summen Ihres Systems gegen Ihren Schnappschuss vergleichen.
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 verhindern.
Anleitung zum Absichern von Debian
2.5 (beta) 20 septiembre 2003Sat, 17 Aug 2002 12:23:36 +0200jfs@computer.org