Firewall Handbuch für LINUX 2.0 und 2.2: Überprüfung der Firewallregeln: Die Überprüfung der UNIX Sicherheit

10.6 Die Überprüfung der UNIX Sicherheit

Nicht nur unter UNIX ist es völlig unmöglich, absolute Sicherheit zu fordern. Das trifft um so mehr zu, je mehr Dienste oder Dämonen auf dem Server aktiviert wurden.

Beim Einsatz eines UNIX Servers in der DMZ sollte dieser als BASTION HOST , siehe hierzu Kapitel Architektur von Firewalls besonders abgesichert werden. Hierzu kann man natürlich die LINUX Kernelfirewall mit IPFWADM, IPCHAINS oder auch SF Firewall einsetzen. Auf der Firewall laufen dann jedoch viele Anwendungen. Diese Konstruktion nennt sich BASTION HOST.

Selbstverständlich muß unbedingt ein BASTION HOST durch zwei Firewalls abgesichert werden, eine auf der Seite des Internets, die andere auf der Seite des Intranets. Diese Firewalls dürfen natürlich keine weiteren Dienste aktiviert haben. Sie dienen auf der Seite des Internets der Überwachung und auf der Seite des Intranets der Sicherheit.

Zuerst möchte ich jedoch auf ein paar Quellen im Internet verweisen, die sich als recht nützlich erwiesen haben:

http://viper.dmrt.com/tools/=Linux/Misc/unix-sec-checklist.htm

Die Datei unix-sec-checklist.htm findet man auch auf unzähligen anderen Servern, oft jedoch in einer älteren Version. Wer in Suchmaschinen nach "UNIX" und "checklist" sucht, der wird bald fündig. In dieser Checkliste ist alles Wichtige und Grundlegende für die Absicherung von UNIX allgemein enthalten. Für unsere LINUX Firewall treffen diese Info´s leider nicht zu. Es gilt hier eine besondere Regel.

Die eiserne Regel bei Firewalls: Eine Firewall hat nur eine Aufgabe, nämlich Firewalling. Jede weitere Funktion, muß unbedingt ausgeschaltet werden. Das bedeutet im einzelnen:

Entfernen aller Dienste aus der Datei /etc/inetd.conf. Danach ist eine Administration nur noch von der Console aus möglich.
Entfernen aller unnötigen Software nach der Installation der Firewall, dazu gehören im Prinzip alle Pakete, die nicht direkt zur Administration notwendig sind, darunter auch alle Compiler, Quellcodes..... Wer sich einmal die LINUX Distributionen angeschaut hat, die auf eine FLOPPY passen, der wird einsehen, daß auf der Firewall noch weniger Programme notwendig sind, als dort. Ein TIP: TOM´S RESCUE DISK - Ein komplettes LINUX mit allen wichtigen Programmen und allen Treibern auf einer Diskette ! Siehe http://www.toms.net
Entfernen Sie alle unnötigen User und Gruppen aus den Dateien /etc/passwd und /etc/group
Entfernen Sie alle SUID und GID - Programme auf der Firewall. Sie finden Sie mit dem Befehl: find / -perm -04000 , optional -print -exec rm {} ";"
Alle verbleibenden Dienste, z.B. der SYSLOGD sollten in einer CHROOT() Umgebung installiert sein, was bedeutet, daß ein Angreifer, wenn er ein buffer overflow Problem des Dämon ausnutzt, höchstens auf ein Unterverzeichnis der Festplatte zugreifen kann. Wer sich intensiver damit beschäftigen muß, der findet im Kapitel chroot() weitere Tips.
Alle verbleibenden Dienste sollten unter minimalen Userrechten laufen, z.B. nobody und nogroup
Die Einträge aller User außer root und userxyz in der Datei /etc/passwd sollten statt /bin/bash den Dummy- Eintrag /bin/false erhalten.
Entfernen alle überflüssigen Protokolle aus dem Kernel durch Neukonfiguration und Neukompilation des Kernels.
Entfernung aller überflüssigen Dämonen aus den Startup - Skripten /etc/inittab, /sbin/init.d/rc.?d oder /etc/rc.d/rc.?d sowie der Datei /etc/rc.local. Nachten sollte man stets auch auf die Dateien .profile, /etc/profile und .bashrc oder .cshrc
Enfernung des KERNELD, damit keine Treiber dynamisch nachgeladen werden können.
Überprüfen Sie die Authentizität aller noch verbleibenden Programme, Libraries oder Dämonen auf Quellcode-Ebene. Falls Sie nicht sicher sind, überprüfen Sie die MD5 Prüfsummen. Es könnte hierzu notwendig sein, daß viele Teile neu kompiliert werden müssen. Kompilieren Sie stets mit der Option -static in dem Makefile.
Damit Sie sicher sein können, daß die verbleibenden Dämonen buffer overflow sicher sind, benutzen Sie die Kompiler der o.a. SecureLINUX Distributionen.

Wie Sie sehen, gibt es gute Gründe, eine Firewall nicht mit einer fertigen LINUX Distribution, wie z.B. RedHat oder S.u.S.E. Linux aufzubauen. Es gibt viel zu viel Software und aktive Dämonen, die man alle unbedingt ausschalten muß. Eine Firewall ist und bleibt ein äußerst sensibles Stück Software, wo ein einziger Fehler schon zuviel ist. Als Systemadministrator der Firewall sollte man alle noch vorhandenen User auf der Firewall gnadenlos eliminieren. Es sollte nur noch ein Useraccount und root auf der Firewall existieren. Übrigens sollte man sich einmal Gedanken darüber machen, welche Accounts bei einer Standard-Distribution, wie z.B. S.u.S.E. LINUX standardmäßig existieren:




root:x:0:0:root:/root:/bin/bash

bin:x:1:1:bin:/bin:/bin/bash

daemon:x:2:2:daemon:/sbin:/bin/bash

lp:x:4:7:lp daemon:/var/spool/lpd:/bin/bash

news:x:9:13:News system:/etc/news:/bin/bash

uucp:x:10:14::/var/lib/uucp/taylor_config:/bin/bash

games:x:12:100::/tmp:/bin/bash

man:x:13:2::/var/catman:/bin/bash

at:x:25:25::/var/spool/atjobs:/bin/bash

postgres:x:26:2:Postgres Database Admin:/var/lib/pgsql:/bin/bash

lnx:x:27:27:LNX Database Admin:/usr/lib/lnx:/bin/bash

mdom:x:28:28:Mailing list agent:/usr/lib/majordomo:/bin/bash

yard:x:29:29:YARD Database Admin:/usr/lib/YARD:/bin/bash

wwwrun:x:30:65534:Daemon user for apache:/tmp:/bin/bash

squid:x:31:65534:WWW proxy squid:/var/squid:/bin/bash

fax:x:33:14:Facsimile Agent:/var/spool/fax:/bin/bash

gnats:x:34:65534:Gnats Gnu Backtracking System:/usr/lib/gnats:/bin/bash

empress:x:35:100:Empress Database Admin:/usr/empress:/bin/bash

adabas:x:36:100:Adabas-D Database Admin:/usr/lib/adabas:/bin/bash

amanda:x:37:6:Amanda Admin:/var/lib/amanda:/bin/bash

ixess:x:38:29:IXware Admin:/usr/lib/ixware:/bin/bash

irc:x:39:65534:IRC Daemon:/usr/lib/ircd:/bin/bash

ftp:x:40:2:ftp account:/usr/local/ftp:/bin/bash

firewall:x:41:31:firewall account:/tmp:/bin/false

informix:x:43:34:Informix Database Admin:/usr/lib/informix:/bin/bash

named:x:44:44:Nameserver Daemon:/var/named:/bin/bash

virtuoso:x:45:100:Virtuoso Admin:/opt/virtuoso-lite:/bin/bash

nobody:x:65534:65534:nobody:/tmp:/bin/bash

user01:x:500:100::/platte2/home/user01:/bin/bash

user02:x:501:100::/home/user02:/bin/bash

user03:x:502:100::/home/user03:/bin/bash

Die Paßworte stehen in der Datei /etc/shadow. Welche Paßworte sind bei welchen Accounts vergeben ? Warum ist in der Datei /etc/shadow bei vielen Accounts kein Paßwort eingetragen ? Wofür ist dann überhaupt der Account gut ? Die Antwort ist einfach - SUID Programme und chroot() Programm nutzen diese Accounts. Diese besitzen ein SUID Bit (Siehe chmod). So verlangen z.B. einige Dämonen, wie sendmail ein solches Bit. In diesem Falle sollte man auf Dämonen ausweichen, die eine sichere Architektur besitzen. Einige Hinweise finden sich in späteren Kapiteln. Eventuell vorhandene suid Programme sollte man entweder löschen, oder aber das Bit entfernen. Empfehlenswert ist es stets, allen Usern, die keine Shell benötigen, in der Datei /etc/passwd anstelle der Shell /bin/bash den Dummy /bin/false einzutragen. Login Versuche scheitern somit alle.

Online Suche im Handbuch

LITTLE-IDIOT NETWORKING