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 ( steffen@dett.de)
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"
|
|