An dieser Stelle sollen nun ganz grundsätzliche Sicherungsmöglichkeiten aufgezeigt werden, die ohne komplexe Systemeingriffe nachvollzogen werden können. Sicherlich ist der Einsatzzweck des Rechners (Desktop-System, Mail-Server, Firewall, ...) relevant für die Auswahl geeigneter Methoden, deshalb können die hier vorgestellten Maßnahmen weder ausreichend noch vollständig sein!
Zuerst sollten die physischen Zugänge (Disketten, CD-ROM, USB/Netzwerk-Boot) gesichert werden. Das kann man ganz einfach im BIOS erledigen. (Passwortschutz für das BIOS ist ebenfalls zu aktivieren!) Einziges physisches Restrisiko bleibt der Ausbau der festplatte. Damit ist man allerdings noch längst nicht am Ende...
Linux Systeme lassen sich im Single User Modus starten, indem man z.B. beim LILO-Bootmanager die Option single angibt:
lilo: linux single
Im ungünstigsten Fall benötigt man nicht einmal ein Passwort und erlangt Superuser-Rechte. Diese Schwachstelle ist folgendermaßen zu beseitigen:
- Editieren der Datei /etc/inittab
/etc/inittab |
....
id:3:initdefault:
~~:S:wait:/sbin/sulogin
....
|
- Editieren der Datei /etc/lilo.conf
/etc/lilo.conf |
....
prompt
timeout=00
default=linux
restricted
passwort=GEHEIM
image=/boot/vmlinuz-2.4.20
label=linux
....
|
- bei Auswahlmöglichkeit aus mehreren Betriebssystemen z.B. Windows, Linux den Parameter timeout auf 50 setzen
- Zugriffsrechte setzen (chmod 600 /etc/lilo.conf)
- Die neue Boot-Konfiguration aktivieren (lilo -v)
- Die /etc/lilo.conf vor Manipulation schützen (siehe Abschnitt "
Erweiterte ext2-Dateiattribute")
Jetzt sollte ein Einbruch durch Ausnutzen der Schwachstellen im Boot-Prozess wesentlich schwieriger zu realisieren sein.
|
Die großen Distributionen SuSE und RedHat installieren standardmäßig dutzende Pakete, die zum nicht unbedingt notwendig sind und nur zusätzliche Funktionen bieten. Da sichere Systeme immer nach dem Prinzip des Minimalismus zu entwerfen sind, sollten diese Pakte deinstalliert werden. Solche Pakete sind bei RedHat z.B.
apmd, anacron, at, bc, eject, getty_ps, gd, gpm, isapnptools, kernel-pcmcia-cs, kudzu, linuxconf, mailcap, mouseconfig, mt-st, pump, pciutils, raidtools, redhat-logos, redhat-release, setserial, XFree86-SVGA
Hinweis: Natürlich beinhaltet jedes dieser Pakete sinnvolle Programme, und möglicherweise benötigen Sie sogar eines von den oben angegebenen.
|
Die meisten Distributionen legen nicht benötigte Nutzer und Gruppen an bzw. vergessen beim Deinstallieren von Softwarepaketen (z.B. apache-http-server) das Entfernen der Einträge in den Passwortdateien.
Solche Kennungen sind zum Beispiel: adm, lp, sync, mail (bei sendmail benötigt!), ftp (bei anonymous ftp benötigt),... Folgende Gruppen sind unter Umständen obsolet: adm, lp, news, pppusers, popusers.
Man sieht, dass solche Benutzer manchmal doch benötigt werden.
|
Die Sicherheit des root-Kennworts ist unbedingt an den Regeln im Kapitel sichere Passwörter auszurichten.
Viele Programme benötigen nicht unbedingt root-Rechte. Oftmals reicht es aus, eine privilegierte Gruppe anzulegen und mittels der Gruppenrechte den Zugriff zu ermöglichen.
Wenn zum Beispiel das Wechseln der Benutzerkennung nur für bestimmte Benutzer erlaubt werden soll, legt man eine neue Gruppe "security" an und ändert die Zugriffsrechte des Programms su.
root@linux # groupadd security
root@linux # chgrp security /bin/su
root@linux # chmod 4750 /bin/su
|
Feiner abgestimmte Restriktionen bieten Capability-Mechanismen des Kernels, die den root-Zugriff weiter einschränken.
|
Der Entzug von Capabilities (Systemfähigkeiten) erlaubt bei Systemstart bestimmte Restriktionen durchzusetzen und ermöglicht damit unter anderem eine Beschränkung der Superuser-Rechte. Nach dem Boot-Vorgang sind standardmäßig alle Capabilities gesetzt.
Der Capability Mechanismus wurde in POSIX 1003.1e und IEEE 1003.2c beschrieben und festgelegt.
Folgende Übersicht beschreibt ganz kurz einige Capabilities (Systemfähigkeiten):
CAP_LINUX_IMMUTABLE |
Ändern von Dateiberechtigungen (siehe Abschnitt Erweiterte ext2-Dateiattribute) |
CAP_SYS_RAWIO |
direkten Zugriff auf Speichermedien (Festplatten) |
CAP_SETGID |
setgid setzen |
CAP_SETUID |
suid setzen |
CAP_SYS_MODULE |
Kernelmodule laden |
CAP_SYS_ADMIN |
mounten/unmounten und andere administrative Tätigkeiten |
CAP_NET_ADMIN |
Netzwerkkarten konfigurieren, Firewall administrieren, Routing administrieren |
Mittels des Programmes lcap können dem System einzelne Fähigkeiten entzogen werden:
lcap CAP_LINUX_IMMUTABLE
lcap CAP_SYS_RAWIO
Nun ist es auch für root nicht mehr möglich, durch +i oder +a geschütze Dateien im ext2 Dateisystem zu löschen. (siehe Abschnitt Erweiterte ext2-Dateiattribute)
An dieser Stelle sei darauf hingeweisen, dass CAP_SYS_RAWIO unbedingt sehr frühzeitig entfernt werden sollte, da ansonsten mittels direktem Zugriff auf das /dev/kmem device der Capability Schutz umgangen werden kann.
|
Die Shell-Variable PATH beinhaltet eine Liste an Verzeichnissen, die beim Aufruf eines Programmes durchsucht werden.
user@linux $ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/bin/X11 |
Die Verzeichnisse werden mit einem Doppelpunkt getrennt. Aus Bequemlichkeit beinhaltet die Pfadvariable oftmals das aktuelle Verzeichnis. Es ist darauf zu achten, dass dieses immer am Ende steht (Bedrohung: Hackerprogramme in allgemein zugänglichen Verzeichnissen wie z.B. /tmp oder /usr/share/firmaXYZ tarnen sich als su oder passwd)
user@linux $ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:. |
|
In der Datei /etc/hosts.conf wird festgelegt, WIE die Zuordnung der Namen zu IP-Adressen erfolgen soll. Das Beispiel zeigt eine relativ sichere Variante.
/etc/hosts.conf |
# Reihenfolge der Domain Namens Auflösung
# (vorausgesetzt DNS/BIND verfügbar)
order hosts, bind
# Multiple IP Adressen werden nur bei Routern benötigt
multi off
#Anti IP-Spoofing
nospoof on
|
|
Aus Sicherheitsgründen ist von einer Benutzung der r-Dienste (z.B. rsh, rcp, rexec) unbedingt abzuraten. Demzufolge sollten auch keine .rhosts Dateien auf dem Rechner zu finden sein, dies kann man folgendermaßen überprüfen:
user@linux $ find /home -name .rhosts
|
Unbedingt sollte man sich mit allen Möglichkeiten von ssh vertraut machen, insbesondere mit dem Umgang von Schlüsselpaaren. Ein guter Einstieg in dieses Thema ist auf den Web Seiten des Linux-Magazins zu finden.
|
In der Datei /etc/services werden alle Dienste ihren Ports zugewiesen. Eine Manipulation kann einem Angreifer Hintertürchen öffnen und sollte deshalb unbedingt unterbunden werden (siehe Abschnitt Erweiterte ext2-Dateiattribute).
|
Dateien, die von jedermann beschrieben werden können, stellen ein sehr großes Sicherheitsrisiko dar. Deshalb sollten so wenig wie möglich solcher Dateien existieren (Gruppenrechte einsetzen!). Mit find lassen sich solche Dateien aufspüren und nach sorgfältiger Kontrolle kontrolliert löschen:
root@linux # find / -perm -o+w -a ! -type l -ls >/tmp/rechtlose-files
|
Verwaiste Dateien gehören keinem Nutzer oder keiner Benutzergruppe an. Dies deutet auf einen erfolgreichen Einbruch hin und sollte kontinuierlich untersucht werden:
root@linux # find / -nouser -o -nogroup >/tmp/verwaiste_files
|
|
Bei Verwendung der Shadow Suite werden Passwörter verschlüsselt in der Datei /etc/shadow abgelegt. Diese kann nur vom Superuser root und von der Gruppe shadow gelesen werden. Kein realer Benutzer hat also Zugang und kann die Passwörter lesen und versuchen, diese mit Hilfe eines Crack-Programmes (z.B. John the Ripper) zu entschlüsseln. Empfehlenswert ist das Abspeichern der Passwörter als MD5-Hash, da dadurch ein potentieller Angriff schwerer durchzuführen ist und längere Passwörter verwendet werden können. Weiterführende Informationen sind im Abschnitt Authentisierung, Autorisierung und Zugriffssteuerung mit PAM zu finden.
|
Eine einfache Absicherung bieten die erweiterten Dateiattribute wie beispielsweise das append-only Attribut bei ext2-Filesystemen (siehe Abschnitt Erweiterte ext2-Dateiattribute). Eine Alternative dazu besteht darin, die Logfiles auf einem dafür bestimmten Rechner zu sammeln. In diesem Zusammenhang sei auf den ssyslogd und den syslog-ng verwiesen, die zusätzlich Integrität und Verschlüsselung bieten.
|
Diese Sammlung von Perl-Skripten erhöht die Sicherheit durch eine automatische Änderung der Konfigurationseinstellungen. Vor jeder Modifikation wird man sehr ausführlich über die Konsequenzen informiert und kann nach dem Abschätzen des Für und Wider die Änderungen akzeptieren oder auch nicht. Das System ist kostenlos und kann unter http://bastille-linux.org heruntergeladen werden. Das Ausführen sollte im Single-User Modus erfolgen:
root@linux # mv Bastille-XXX.tar.gz /root
root@linux # cd /root
root@linux # tar zxvpf Bastille-XXX.tar.gz
root@linux # init 1
root@linux # cd /root/run-Bastille
root@linux # ./Bastille1.pl
|
Zum Schluss noch ein Zitat, auf das mich Steffen Dettmer ( ) hingewiesen hat:
"The only secure computer system in the world is unplugged, locked in a vault at the bottom of the ocean and only one person knows the location and combination of that vault. And he is dead."
--Bruce Schneier in "Applied Cryptography"
|
|