http://www.net-tex.de
Intrusion Detection System
Da eine 100% Sicherheit nicht erreicht werden kann, installiert man
Einbruchserkennungen.
Nun haben wir also ein "sicheres" System gebaut und trotzdem wurde es penetriert
Oder wir haben den Verdacht daß unser Rechner schon seit geraumer
Zeit als Gateway
benutzt wird um in militärische Rechner einzudringen oder NASA-Systeme
zu zerbomben.
Oder viel schlimmer – man spioniert unsere Daten aus .. Briefe, Onlinebanking,
Passwörter ... der reinste Horror.
Was kann man also tun? Richtig! IDS – Intrusion Detection System.
Zu deutsch Einbruchserkennung. Damit kann man zwar z.B. einen DoS nicht
verhindern,
aber evtl. Backdoors auffinden, erfolgte Angriffe identifizieren, den
Schaden
begrenzen oder stattfindende Attacken aufklären und vielleicht
den Angreifer identifizieren.
Und wie immer läuft das unter Open Source mit kostenlosen Tools
ab.
Nun mal etwas zur Methodik und Technik.
1.) Simple Auditing
Nun um uns im "Information Warfare" verteidigen zu können sollten
wir unser
System kennen. Und zwar wichtige Attribute wie Rechte, Änderungszeiten,
Dienste
oder Ports. Wenn wir unseren Grundzustand protokollieren erhalten wir
eine Backline
zum Vergleich mit späteren Audits um evtl. bösartige Veränderungen
zu erkennen.
Diese Backline sollte gut gesichert sein – am besten auf einem anderen
Rechner,
Disketten, CD oder Ausdruck damit eine Manipulation ausgeschlossen
werden kann.
SetUID/SetGID Dateien |
Die Dateien erhalten die Besitzerrechte wenn
sie ausgeführt werden. Der Befehl find / -type –perm +6000 findet
die UID/GID-Files |
Änderungsdatum |
ls /etc -alR --full-time - ganz praktisch vor
allem bei /etc-files um neue Dateien und Änderungen zu finden. |
nicht referenzierte Datei |
lsof +L1 - Datei die noch existiert aber
deren INode-Verweis fehlt. |
Datei-Hash/CRC |
Ein Abbild/Prüfsummenbild des Dateisystems um Veränderungen
zu erkennen z.B. per Tripwall oder einfachem Dateiabbild mittels ls
-al
|
Dienste/Verbindungen |
lsof –i zeigt alle Internetports mit
zugehörigem Dienst/User an |
Nun der Komfortabilität wegen sollte man diesen Audit per Crontab
und Skript
automatisieren um ihn regelmäßig durchlaufen zu lassen.
2.) Protokollierung
Hier verfolgt man einen anderen Ansatz. Ein (guter) Einbrecher wird versuchen
seine Spuren zu verwischen um seinen Angriff zu verdunkeln. Häufig
erlaubt die
Analyse der Protokolldateien einen Rückschluß auf die Methode,
die für den Einbruch
genutzt wurde.
Standardmäßig nutzt man in der Linuxwelt den syslogd
bzw klogd syslogd
sichert die Log-Ausgaben normaler Programme und ermöglicht auch
den Einsatz im
Netzwerk um die Protokolle auf einem fremden Rechner vor dem Einbrecher
zu schützen.
Dies geschieht mit dem Eintrag: *.* @hostname in der syslogd.conf.
Allerdings
kann sich damit ein Problem entwickeln wenn der syslogd mit Meldungen
überschwemmt
wird und eine Protokollierung nicht mehr möglich ist. Allerdings
kann so der
Einbrecher die Protokolle auf dem Localhost frei Manipulieren, deshalb
müssen
sie geschützt werden. Dazu bietet sich ssyslogd an, eine Implementierung
des
syslog welcher die Daten mittels PEO-1 verschlüsselt. Somit ist
ein Editieren
der Daten nicht mehr möglich, lediglich das Löschen der Dateien
kann noch
geschehen – aber damit verrät sich der Angreifer!
Der ssyslogd verwendet wie syslogd die syslogd.conf für seine
Konfiguration.
Um nun die Meldungen verschlüsselt eintragen zu lassen wird folgender
Eintrag
vorgenommen: *.info [peo] /var/log/messages
Der klogd hingegen sichert die Logs des Kernels.
Ebenfalls wichtig ist eine Rotation/Sicherung der Protkolle z.B. per
logrotate
oder per eMail, die ja auch aufs Handy geleitet werden können
;-).
Ebenfalls als Protokolliermechanismus kann der xinetd fungieren. Er
ist ein Ersatz
für den inetd, der unter anderem folgende Vorteile bietet:
-
Erweiterte Zugriffskontrolle in Abhängigkeit von IP-Adresse, Uhrzeit,
Namen und Domäne des Clients
-
Neukonfiguration des Servers beendet offene Dienste, die nicht mehr den
Zugriffsregeln entsprechen
-
Kann einige Denial of Service-Angriffe durch Beschränkung der Dienstanzahl
und
der Protokolldateigröße verhindern, da eine Überschwemmung
des Systems schnell mal zu einem DoS führen kann.
-
Bindung einzelner Dienste an spezifische IP-Adressen
lastlog:
- verfolgt User-Login in /usr/log/lastlog
- löscht logs täglich - daher sichern!
last
- logt die Login-Zeiten der User in /var/log/wtmp
xferlog
- logt FTP-action in /usr/adm
httpd
- logt HTTP-action in /var/log/httpd/apache/...
-- access.log : genereller HTTP-Zugriff
-- error.log : HTTP-Fehlermeldungen
lpl
- logt eingehende IP-Pakete - kann u. U. zu DoS führen!
3.) Automatische Audits
Ein automatischer Audit ist nichts weiter als eine automatisierte Richtlinie
zur
Durchführung der ersten beiden erwähnten Methoden. Für
diese doch teilweise recht
stupide Arbeit kann man natürlich ein prima Skript entwerfen welches
per crontab
ausgeführt wird.
Es gibt einige Programme die alle ähnlich wie das bekannte Tripwire
arbeiten.
Hierbei wird ein Hash als Abbild eines Verzeichnisses oder des gesamten
Dateisystems
angelegt. Da dies verschlüsselt geschieht kann diese Momentaufnahme
nicht editiert
werden. Einige ähnliche Programme:
AIDE Tripwall,,
Toby,
ViperDB und Sentinel
Ebenso lohnt es natürlich nicht Protokolle anlegen zulassen
wenn diese nicht geprüft werden. Meistens geht einem erfolgreichen
Einbruch eine
Reihe von auffälligen und erfolglosen Einbruchsversuchen voraus.
Aber auch diese
Sisyphusarbeit läßt sich z.B. per LogCheck
automatisieren.
Weiterhin gibt es schon fertige Lösungen wie SATAN/SAINT oder
Cops die meist aus
Perlskripten bestehen und das System auf bestehende Sicherheitslücken
hin untersuchen.
Diese Programme finden zwar nur bekannte Fehler – aber dies minimiert
dennoch die
Chance einer erfolgreichen Komprimittierung, außerdem kann Dank
des modularbekannte Fehler – aber dies minimiert dennoch die
Chance einer erfolgreichen Komprimittierung, außerdem kann Dank
des modularen Aufbaus
schnell auf neue Lücken hin upgedatet werden.
4.) Netzwerküberwachung
Meistens befindet sich der zu schützende
Rechner mittels Netzwerk in Verbindung
mit anderen Rechnern. Deshalb sollte natürlich auch diese Verbindung
besonders
geschützt werden. Dazu sollte man überflüssige Dienste
deaktivieren da diese meist
nicht gepflegt (gepatcht) werden und somit ein großes Angriffspotential
bieten.
Es gibt natürlich wieder einige Hilfsmittel für den gestressten
Admin. z.B.
Arpwatch |
überwacht ein Netzsegment auf neue MACs. Das ist eine eindeutig
verlötete Adresse
auf jeder Netzkarte und somit einen neuen Rechner identifiziert |
neped |
kann Karten im Promiscous Mode aufspüren, dies bedeutet meist
das diese sniffen. |
Portsentry |
warnt bei Portscans mit denen versucht wird laufende Dienste und Betriebsystem
zu
identifizieren und kann einige Ports sperren |
Ebenso kann man den Nettraffic z.B. er Amavis protokollieren und scannen
lassen um
z.B. gefährliche *.vbx-Dateien zu sperren.
Sollte man einen wichtigen Proxy oder ähnliches administrieren
und über etwas Kleingeld
verfügen kann man auch Warnmeldungen per eMail an Handy oder Pager
senden (was meist aber Geld kostet!)
Man sollte IDS nur als eine Maßnahme von mehreren (Firewalls,
Social Engineering,
Passwörter ...) betrachten und nicht als Allheilmittel ansehen,
dennoch ist der
Einsatz zu empfehlen. Man kann wie schon erwähnt unbekannte Angriffsmethoden
aufdecken
und sich vor bekannten Skript-Kiddy-Methoden schützen.
Trotzdem sollte man eine gesamte Securitypolicy aufstellen und eingesetzte
Programme/Skripte auch regelmäßig patchen/aktualisieren.
mtime : Aug 29 2000
ctime : Apr 03 2002
owner : Stefan Schumacher
sources : de.comp.security.*, de.comp.os.linux.*/bsd