1. Was ist OSSEC?

Wird mein System gerade angegriffen?

oder

Wann ist eigentlich die Festplatte voll?

Das sind typische Fragestellungen eines Server-Verantwortlichen. Dabei ist es gar nicht so schwer die Kontrolle über das System zu behalten und gleichzeitig die Informationsflut zu bändigen. Dafür gibt es Tools. Eines dieser Tools nennt sich OSSEC und ist kurz zusammengefasst genau das:

OSSEC is an Open Source Host-based Intrusion Detection System. It performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.

Mit OSSEC ist es also möglich eine Server-Überwachung zu betreiben. Angriffe auf das System oder unnatürliche Aktivitäten werden erkannt und mittels E-Mail, SMS oder Agent an den Administrator gemeldet.

Die Highlights von OSSEC auf einen Blick:

Rootkit Erkennung
Integritätschecks
Log Analysen
Active Response
zeit-basierte Alarmmeldungen

2. Installation

Aktuell liegt das HIDS (Host Instrusion Detection System) in der Version 2.8 (Stand August 2014) vor. Unterstützt wird Linux, Solaris, *BSD, Mac, AIX und weitere Varianten. Im Artikel wird die lokale Installation beschrieben. Agents werden ebenfalls unterstützt, um mehrere Systeme gleichzeitig zu überwachen.

Für die lokale Installation schlage ich folgende Schritte als Root-User vor:

Wechsel ins Temp Verzeichnis:

cd /tmp

Herunterladen – Entpacken – Installieren:

wget https://github.com/ossec/ossec-hids/releases/latest
tar xvf ossec-hids-2.9.2.tar.gz
cd ossec-hids-2.9.2
sudo ./install.sh

2.1 Installationsassistent

Der Assistent begleitet durch die Installation und stellt folgende Fragen:

What kind of installation do you want: local
Choose where to install the OSSEC HIDS return (Standardpfad)
Do you want e-mail notification? yes
What’s your e-mail address? <E-Mail>
We found your SMTP server as: <SMTP>
Do you want to run the integrity check daemon? yes
Do you want to run the rootkit detection engine? yes
Do you want to enable active response? yes
Do you want to enable the firewall-drop response? yes
Do you want to add more IPs to the white list? no

Anschließend wird OSSEC kompiliert. Ein C/C++ Compiler ist daher erforderlich.

Es besteht die Möglichkeit automatisch Firewall-Drop Regeln generieren zu lassen. Beispielweise wenn eine IP-Adresse auffällig wurde. Dazu muss auf dem System iptables installiert sein.

Nach der Installation kann das HIDS direkt gestartet werden:

/var/ossec/bin/ossec-control start

2.2 Konfiguration

Die Konfigurationsdatei von OSSEC befindet sich unter:

/var/ossec/etc/ossec.conf

Alle Einträge in dieser Datei müssen sich innerhalb des <ossec_config>…</ossec_config> Blocks befinden. Eine ausführliche Beschreibung über Regeln, Decoder und Active Responses befindet sich in der offiziellen OSSEC Dokumentation. Eine gute Anleitung zur Erstellung eigener Decoder und Regelsätze findet ihr hier.

2.3 OSSEC default Konfiguration

Die wichtigsten Logs und Dateien werden von OSSEC bereits in der Standard-Konfiguration überwacht. Des Weiteren werden bereits Decoder und Regelsätze für die gängisten Programme und Angriffsvektoren bereitgestellt. Auf einem Debian Linux System werden default folgende Log-Dateien überwacht:

/var/log/messages
/var/log/auth.lo
/var/log/syslog
/var/log/mail.info
/var/log/dpkg.log

3. Beispiel Active Response

Mit Hilfe von Active Responses (AR) kann OSSEC selbständig auf bestimmte Ereignisse reagieren. Die Verwendung von AR muss explizit aktiviert werden. Dies ist bei der Installation bereits erfolgt, kann aber auch nachgeholt werden. Dazu ist lediglich eine Anpassung der Konfigurationsdatei notwendig.

/var/ossec/etc/ossec.conf

<active-response>
   <disabled>no</disabled>
</active-response>

Du kannst den Blog aktiv unterstützen!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

3.1 Automatische Sperrung von IP-Adressen bei fehlgeschlagenen Login-Versuchen

Ich beschreibe hier die Implementierung eines AR, der automatisch SSH-Login Versuche unterbindet. Dazu wird die betroffene IP-Adresse temporär in die hosts.deny eingetragen und dadurch für mehrere Minuten gesperrt.

Vorraussetzung ist das TCP-Wrapper Modul libwrap. Mit dem Befehl

ldd /usr/sbin/sshd | grep libwrap.so

kann geprüft werden, ob das Modul verfügbar ist. Erfolgt eine Ausgabe ist es verfügbar, ansonsten nicht. Bei Debian ist das Modul bereits im Package openssh-server enthalten.

Um die AR zu aktivieren, sind folgende Einträge in der Datei

/var/ossec/etc/ossec.conf

erforderlich.

<active-response>
   <command>host-deny</command>
   <location>local</location>
   <level>6</level>
   <timeout>600</timeout>
</active-response>

Die Einträge bewirken, dass bei allen Alarmen ab einer Warnstufe von 6 die IP-Adresse des Verursachers der Meldung für 600 Sekunden (10 Minuten) in die Datei /etc/hosts.deny eingetragen wird. Folglich wird die IP-Adresse für 10 Minuten gesperrt.

4. Reaktion auf False-Positive Meldungen

False-Positives sind Meldungen auf Ereignisse, die in Wirklichkeit keine Gefahr darstellen. Sie werden von OSSEC generiert und lösen einen Alarm aus. Die Ursache ist allerdings harmlos bzw. man möchte False-Postive Meldungen eigentlich vermeiden.

Hier ein Beispiel einer solchen Meldung. OSSEC schickt dem Administrator eine Mail mit folgendem Inhalt:

OSSEC HIDS Notification.
2012 Jun 25 5:25:36

Received From: mail->/var/log/syslog
Rule: 510 fired (level 2) -> "Kernel-level rootkit or trojaned 
version of netstat."

--END OF NOTIFICATION

OSSEC weist den Administrator auf eine potenziell verseuchte Version von netstat hin. Diese Meldung kann allerdings ignoriert werden. Sie wird ausgelöst, da es sich beim System um einen virtuellen Host handelt und sich das Wirtsystem mit weiteren Systemen teilt. Die Meldung stellt also keine Gefahr dar, sondern steht im Zusammenhang mit der Server-Virtualisierung. Folglich können wir die Meldung in Zukunft ignorieren.

Dies geschieht durch einen Eintrag in der Datei:

/var/ossec/rules/local_rules.xml

In den <group> Block werden folgende Einträge hinzugefügt:

<rule id="100101" level="0"> 
   <if_sid>510</if_sid>
   <match>Kernel-level rootkit or trojaned version of netstat</match>
   <description>Ignore event 510</description> 
</rule>

Taucht die Meldung 510 wieder auf und enthält als Warnung »Kernel-level rootkit or trojaned version of netstat«, wird sie in Zukunft ignoriert.

Hinweis

False-Positive Meldungen sind keinesfalls zu vernachlässigen. Sie deuten auf potenzielle Angriffe oder Systemprobleme hin.

5. Fazit

OSSEC stellt ein mächtiges Tool zur Systemüberwachung dar. In meinem Artikel habe ich lediglich einen kurzen Einblick über die Möglichkeiten gegeben. Wer sich ernsthaft mit HIDS befassen möchte, dem sei das Tool ans Herz gelegt. Es bietet eine ausgezeichnete Dokumentation und ist mittlerweile ausgereift.

Des Weiteren bietet es weitere Funktionen, auf die ich im Artikel nicht näher eingegangen bin. Diese Funktionen sind hier nochmal auf einen Blick zusammengefasst. Unter anderem wird ein Web-Interface angeboten.

Bildquellen:

OSSEC: https://ossec.github.io/

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

Unterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡

Diskussion

5 Ergänzungen zu “OSSEC • Schutz von Linux Servern”

Marcus Gartner sagt:

24. Juli 2012 um 12:56 Uhr

Bin über Google auf den Artikel gekommen. Bisher das Beste was ich auf deutsch dazu finden konnte. *daumenhoch*

Hab meinen Server jetzt mal damit ausgestattet. Funktioniert super.
Holger sagt:

17. September 2012 um 13:49 Uhr

Hi,

mir ist unklar, wieso OSSEC eine Fehlermeldung wg. netstat wirft bzw. wie es dazu kommen kann. Ist meine Vermutung korrekt, dass OSSEC erst per netstat offene ports listet und dann mit bind() prüft, ob nur diese offen sind? Falls man eine genattete VM hat, wird OSSEC natürlich nicht jeden der lt. netstat noch offenen Ports öffnen können, da diese ggf. von einer anderen VM geöffnet sind…?

Grüße
Holger
Mike Kuketz sagt:

17. September 2012 um 14:26 Uhr

Hallo Holger,

poste mal die Fehlermeldung. Ist es so eine?

„Kernel-level rootkit or trojaned version of netstat.“
Holger sagt:

17. September 2012 um 14:35 Uhr

Hi Mike

ich habe noch kein OSSEC deployed. Ich beschäftige mich gerade nur mit dem System in Theorie und bin auf den Artikel hier gestoßen.

Ich kann mir ja vorstellen, dass Virtualisierung gewisse Auswirkungen auf HIDSe hat, in dem Fall sind mir die Gründe, die zu diesem False Positive führen, allerdings absolut unklar. Verstehst du, an was das liegt? Gibt es noch weitere Wechselwirklungen zw. HIDS und Virtualisierung?

Beste Grüße
Holger
- Mike Kuketz sagt:
  
  17. September 2012 um 16:00 Uhr
  
  Bisher bin ich bei der Virtualisierung nur auf die von mir dargestellte Fehlermeldung gestoßen.
  
  Abhängig auf welche Virtualisierungslösung man setzt, können (vermutlich) weitere Effekte bzw. False-Positive Meldungen auftreten.
  Auswahl gibt es reichlich: Von XEN, über VirtualBox, VMware, KVM und weiteren.
  
  Im Idealfall sorgt eine Virtualisierungs-Lösung für die komplette Trennung der Maschinen. Bei KVM zum Beispiel könnte das Problem durch einen Bug des Shared Kernels hervorgerufen werden. Beim Systemcheck „sieht“ OSSEC plötzlich Ports von fremden Maschinen, da die Trennung nicht sauber funktioniert.
  
  Eine andere Theorie sind Deamons. Diese öffnen High Ports und schließen diese dann wieder. Beispielsweise für den FTP-Transport. Findet zu diesem Zeitpunkt eine Prüfung statt, schlägt OSSEC Alarm.

Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.

Artikel (399)

OSSEC • Schutz von Linux Servern