Firewall Handbuch für LINUX 2.0 und 2.2 - zurück
Firewall Handbuch für LINUX 2.0 und 2.2 - zurück
Firewall Handbuch für LINUX 2.0 und 2.2 - zurück
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
empress:x:35:100:Empress Database Admin:/usr/empress:/bin/bash<br />
adabas:x:36:100:Adabas-D Database Admin:/usr/lib/adabas:/bin/bash<br />
amanda:x:37:6:Amanda Admin:/var/lib/amanda:/bin/bash<br />
ixess:x:38:29:IXware Admin:/usr/lib/ixware:/bin/bash<br />
irc:x:39:65534:IRC Daemon:/usr/lib/ircd:/bin/bash<br />
ftp:x:40:2:ftp account:/usr/local/ftp:/bin/bash<br />
firewall:x:41:31:firewall account:/tmp:/bin/false<br />
informix:x:43:34:Informix Database Admin:/usr/lib/informix:/bin/bash<br />
named:x:44:44:Nameserver Daemon:/var/named:/bin/bash<br />
virtuoso:x:45:100:Virtuoso Admin:/opt/virtuoso-lite:/bin/bash<br />
nobody:x:65534:65534:nobody:/tmp:/bin/bash<br />
user01:x:500:100::/platte2/home/user01:/bin/bash<br />
user02:x:501:100::/home/user02:/bin/bash<br />
user03:x:502:100::/home/user03:/bin/bash<br />
Die Paßworte stehen in der Datei /etc/shadow. Welche Paßworte sind bei welchen<br />
Accounts vergeben ? Warum ist in der Datei /etc/shadow bei vielen Accounts kein<br />
Paßwort eingetragen ? Wo<strong>für</strong> ist dann überhaupt der Account gut ? Die Antwort ist einfach<br />
- SUID Programme <strong>und</strong> chroot() Programm nutzen diese Accounts. Diese besitzen ein<br />
SUID Bit (Siehe chmod). So verlangen z.B. einige Dämonen, wie sendmail ein solches Bit.<br />
In diesem Falle sollte man auf Dämonen ausweichen, die eine sichere Architektur<br />
besitzen. Einige Hinweise finden sich in späteren Kapiteln. Eventuell vorhandene suid<br />
Programme sollte man entweder löschen, oder aber das Bit entfernen. Empfehlenswert ist<br />
es stets, allen Usern, die keine Shell benötigen, in der Datei /etc/passwd anstelle der<br />
Shell /bin/bash den Dummy /bin/false einzutragen. Login Versuche scheitern somit alle.<br />
10.7 Logging von Ereignissen<br />
Für das Loggen von Ereignissen ist der SYSLOGD zuständig. Fast alle Programme <strong>und</strong><br />
Dämonen haben in ihrem Quellcode den SYSLOGD als Ziel der Fehlermeldungen<br />
angegeben. Dieser ist, sofern er mit der Option -r gestartet wird, auch von außerhalb<br />
(hoffentlich nur aus dem Intranet) zu erreichen. So kann man auf der <strong>Firewall</strong> oder einem<br />
Loghost im Intranet alle Meldungen von Servern, Clients <strong>und</strong> <strong>Firewall</strong> sammeln <strong>und</strong><br />
gemeinsam auswerten, beispielsweise mit argus oder logsurfer, zwei sehr<br />
leistungsfähigen <strong>und</strong> zudem noch kostenlosen Werkzeugen. Damit die Kernel <strong>Firewall</strong> bei<br />
Verstößen gegen die Regeln auch eine Eintrag in das Logfile schreibt, muß man an jede<br />
<strong>Firewall</strong>regel die Option -o anhängen. Man stets auch immer berücksichtigen, daß auch<br />
der SYSLOGD <strong>für</strong> Angriffe, insbesondere <strong>für</strong> buffer overflows anfällig sein kann. Daher<br />
sollte man stets zwei Loghosts betreiben - die <strong>Firewall</strong> <strong>und</strong> einen Logserver im Intranet.<br />
Deren Logfiles sollten regelmäßig abgeglichen werden, um einen Angreifer mit hoher<br />
Sicherheit auch entdecken zu können. Jeder Angreifer ist nämlich bestrebt,<br />
schnellstmöglich die Logeinträge zu bereinigen. Der SYSLOG - Dämon besitzt zwar einen<br />
Schutz gegen das Fluten mit tausendfach identischen Einträgen, gegen einen geschickten<br />
Angriff mit wechselnden Angriffsweisen gibt es aber keinen Schutz. Damit die Festplatte<br />
nicht volläuft, sollte ein logwrapper installiert bzw. aktiviert werden. Dieser liegt bei jeder<br />
neueren Linux Distribution bei, <strong>und</strong> sorgt da<strong>für</strong>, daß die LOG - Datei nicht zu groß wird.<br />
Die Datei /etc/syslog.conf enthält einige Einträge, die festlegen, in welche Dateien<br />
welche Fehlermeldungen einsortiert werden sollen. Diese sollte so eingerichtet werden,<br />
daß<br />
/var/log/auth Login Versuche aufzeichnet, /var/log/secure Verbindungs Versuche<br />
aufzeichnet (spoofing), /var/log/messages weitere Fehlermeldungen aufzeichnet.<br />
Dann ist es wichtig, daß die wichtigen Dämonen so eingestellt wurden, daß diese auch<br />
tatsächlich Fehler an den SYSLOGD liefern. Einige Dämonen können nämlich auch in<br />
Erstellt von Doc Gonzo - http://kickme.to/plugins