Firewall Handbuch für LINUX 2.0 und 2.2 - zurück

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.
10.7 Logging von Ereignissen
Für das Loggen von Ereignissen ist der SYSLOGD zuständig. Fast alle Programme und
Dämonen haben in ihrem Quellcode den SYSLOGD als Ziel der Fehlermeldungen
angegeben. Dieser ist, sofern er mit der Option -r gestartet wird, auch von außerhalb
(hoffentlich nur aus dem Intranet) zu erreichen. So kann man auf der Firewall oder einem
Loghost im Intranet alle Meldungen von Servern, Clients und Firewall sammeln und
gemeinsam auswerten, beispielsweise mit argus oder logsurfer, zwei sehr
leistungsfähigen und zudem noch kostenlosen Werkzeugen. Damit die Kernel Firewall bei
Verstößen gegen die Regeln auch eine Eintrag in das Logfile schreibt, muß man an jede
Firewallregel die Option -o anhängen. Man stets auch immer berücksichtigen, daß auch
der SYSLOGD für Angriffe, insbesondere für buffer overflows anfällig sein kann. Daher
sollte man stets zwei Loghosts betreiben - die Firewall und einen Logserver im Intranet.
Deren Logfiles sollten regelmäßig abgeglichen werden, um einen Angreifer mit hoher
Sicherheit auch entdecken zu können. Jeder Angreifer ist nämlich bestrebt,
schnellstmöglich die Logeinträge zu bereinigen. Der SYSLOG - Dämon besitzt zwar einen
Schutz gegen das Fluten mit tausendfach identischen Einträgen, gegen einen geschickten
Angriff mit wechselnden Angriffsweisen gibt es aber keinen Schutz. Damit die Festplatte
nicht volläuft, sollte ein logwrapper installiert bzw. aktiviert werden. Dieser liegt bei jeder
neueren Linux Distribution bei, und sorgt dafür, daß die LOG - Datei nicht zu groß wird.
Die Datei /etc/syslog.conf enthält einige Einträge, die festlegen, in welche Dateien
welche Fehlermeldungen einsortiert werden sollen. Diese sollte so eingerichtet werden,
daß
/var/log/auth Login Versuche aufzeichnet, /var/log/secure Verbindungs Versuche
aufzeichnet (spoofing), /var/log/messages weitere Fehlermeldungen aufzeichnet.
Dann ist es wichtig, daß die wichtigen Dämonen so eingestellt wurden, daß diese auch
tatsächlich Fehler an den SYSLOGD liefern. Einige Dämonen können nämlich auch in
Erstellt von Doc Gonzo - http://kickme.to/plugins