OSSEC 2.8.1 auf FreeBSD 9.3

Installationsnotizen

• statt pkg aus den Ports installieren und mysql mit einkompilieren (make config install clean)
• am Server (ossec-hids-server-2.8.1_1) wird das Serverpaket installiert, in z.b. den Jails und anderen zu überwachenden Maschinen jeweils ein Agent
• Kommunikation über UDP 1514 muss möglich sein (Firewall anpassen)
• Mysql Schema muss auf Freebsd „von Hand“ angelegt werden… – einfach Tarball runterladen
• Konfigurieren
• Frontend installieren
  • Webui von Ossec müsste auf dem Server laufen, da Direktzugriff auf das /var Verzeichnis!
  • Alternative AnaLogi kann auch extern installiert werden und braucht nur Zugriff auf mysql
  • 3. Möglichkeit: Splunk
• Agents werden mit /pfad/bin/manage-agents angelegt -> Signatur kopieren -> am Agent eintragen
• Bugs Freebsd
  • chown ossec:ossec und chmod 750 auf den queue/rootcheck Ordner machen!
  • Pfad stimt nicht: /var/ossec/etc/shared/rootkit_files.txt -> symlink zum richtigen Ordner in /usr/local/ossec…. setzen!
  • „ERROR: Unable to open file ‚/etc/shared/merged.mg“ -> Ebenfalls einen Symlink anlegen und leeres File anlegen, Rechte und Besitzer wie oben

Regeln und Dekoder

Regelerstellung: Zuerst muss der decoder funktionieren und seinen Job machen – und je nach Regel auch die SRC IP richtig dekodieren (wichtig!). Danach greifen die Regeln – wobei diese gruppiert werden können und unterschiedlichste Kombinationen möglich sind. Es gibt ein Testtool (bin/ossec-logtest) zum Regeln testen der Dekoder und Regeln, hilfreich sind in dieser Hinsicht auch die Logs der alerts (logs/alerts/alerts.log) und der active-responses (logs/active-responses.log).

Beispiel (etc/local_decoder.xml)

<decoder name="iplog">
  <program_name>^TCP|^UDP|^ICMP</program_name>
</decoder>
<decoder name="iplog-ssh">
 <parent>iplog</parent>
 <prematch>ssh connection attempt</prematch>
 <regex offset="after_prematch">from (\S+)</regex>
 <order>srcip</order>
</decoder>
...

Hier wird als erstes ein Decoder „iplog“ erzeugt. Der schlägt zu, wenn die Logzeile mit TCP, UDP oder ICMP beginnt. Als nächstes haben wir einen Decoder „iplog-ssh“, der auf dem Decoder „iplog“ aufbaut – erkennbar am Befehl „parent“. Die Befehle „prematch“, „regex“ und „order“ dienen der richtigen Bearbeitung und Erkennung der Logzeile… ein Beispiel, um das zu verdeutlichen.

Die folgenden Ausdrücke der regular expressions sind anwendbar:

\w  ->  A-Z, a-z, 0-9, '-', '@' characters
\d  ->  0-9 characters
\s  ->  For spaces " "
\t  ->  For tabs.
\p  ->  ()*+,-.:;<=>?[]!"'#$%&|{} (punctuation characters)
\W  ->  For anything not \w
\D  ->  For anything not \d
\S  ->  For anything not \s
\.  ->  For anything

+  ->  To match one or more times (eg \w+ or \d+)
*  ->  To match zero or more times (eg \w* or \p*)

^ -> To specify the beginning of the text.
$ -> To specify the end of the text.
| -> To create an "OR" between multiple patterns.

Escaping:
$ -> \$
( -> \(
) -> \)
\ -> \\
| -> \|

Der Input stammt dabei aus dem Programm „iplog“, mit dem man gewisse Events wie beispielsweise Portscans, SSH Connects auf bestimmte Ports etc. sehr einfach loggen kann.

INPUT:  Mar 26 05:09:32 TCP: ssh connection attempt from 66.85.155.34:43353

**Phase 1: Completed pre-decoding.
 full event: 'Mar 26 05:09:32 TCP: ssh connection attempt from 66.85.155.34'
 hostname: 'main'
 program_name: 'TCP'
 log: 'ssh connection attempt from 66.85.155.34'

**Phase 2: Completed decoding.
 decoder: 'iplog'
 srcip: '66.85.155.34'

**Phase 3: Completed filtering (rules).
 Rule id: '180002'
 Level: '6'
 Description: 'SSH Connect falscher Port'
**Alert to be generated.

Man sieht, dass in Phase 1 der erste Dekoder anhand des „Programms“ TCP erkannt wird – in Phase 2 der richtige finale Dekoder „iplog“. An dieser Stelle ist ganz wichtig, dass auch die src-IP korrekt erkannt wird, denn sonst kann später nicht mit active-response reagiert werden!

In Phase 3 wird dann das Regelset angewendet und die Regel #180002 erkannt, auf deren Basis dann gewisse Reaktionen von Email bis hin zu active-response gesetzt werden können.

Der Vollständigkeit halber – so sieht die Regel aus (rules/local_rules):

<group name="iplog">
 <rule id="180000" level="0">
    <decoded_as>iplog</decoded_as>
    <description>Grouping for iplog rules</description>
 </rule>
 <rule id="180002"  level="6">
   <if_sid>180000</if_sid>
   <match>ssh connection attempt from</match>
   <description>SSH Connect falscher Port</description>
 </rule>
 <rule id="180003"  level="10" frequency="2" timeframe="30">
   <if_matched_sid>180002</if_matched_sid>
   <same_source_ip />
   <description>SSH Bruteforce am Fakeport</description>
 </rule>
...
</group>

Die erste Regel (ids müssen eindeutig sein!) #180000 wird benutzt, um alle Regeln die vom iplog – Dekoder dekodiert wurden zu gruppieren. Dabei wird der level auf 0 gesetzt, um kein Alert zu erzeugen. Die Gruppierungen sind auch für Performanceoptimierungen nützlich.

Regel #180002 prüft auf den String „ssh connection attempt from“ sofern die Gruppenregel ausgelöst wurde. Falls ja, wird ein Alert mit Level 6, der RegelID und deren Beschreibung ausgelöst.

Regel #180003 wird schlagend, wenn die Regel #180002 mehrfach von derselben SRC-IP ausgelöst wurde – und zwar öfter als 4x innerhalb von 30 Sekunden ( Systembedingt muss der Frequencywert um 2 reduziert notiert werden.). In dem Fall wird ein Alert mit Level 10 ausgelöst.

Nun können wir aktive Gegenmaßnahmen setzen:

Beispiel (etc/ossec.conf)

<!-- Falscher SSH Port -->
 <active-response>
    <command>firewall-drop</command>
    <location>server</location>
    <rules_id>180002</rules_id>
    <timeout>30</timeout>
  </active-response>

<!-- Mehrere Versuche  Falscher SSH Port -->
 <active-response>
    <command>firewall-drop</command>
    <location>server</location>
    <rules_id>180003</rules_id>
    <timeout>3600</timeout>
  </active-response>

Die Sache ist recht übersichtlich: Trifft Regel #180002 zu (siehe oben), dann wird mit dem Script firewall-drop die SRC-IP des Angreifers in eine Table des Packetfilters / Firewall eingetragen und somit geblockt. Nach dem Timeout von 30 Sekunden wird das wieder rückgängig gemacht. Mittels der location kann angegeben werden , WO das passieren soll: Server= ossec Server, local = der Client, auf der der auslösende Agent läuft, ALL=überall usw.

Auf diese Art und Weise lässt sich zentral recht viel konfigurieren und abfangen: diverse Bruteforceangriffe auf SSH, FTP, HTTP, Spammails etc. Der Phantasie sind wenig Grenzen gesetzt 🙂

sonstiges

Wem die Emails zu sehr nerven – folgendes kann diesbezüglich man in der etc/ossec.conf einstellen:

<ossec_config>
  <global>
    <email_notification>yes</email_notification>
    <email_to>admin@HOST.COM</email_to>
    <smtp_server>mail.HOST.COM</smtp_server>
    <email_from>admin@HOST.COM</email_from>
    <email_maxperhour>1</email_maxperhour>
  </global>

  <email_alerts>
    <email_to>admin@HOST.COM</email_to>
    <level>11</level>
    <do_not_delay />
    <do_not_group />
  </email_alerts>
...
  <localfile>
    <log_format>apache</log_format>
    <location>/usr/home/www/*/log/*access.log</location>
  </localfile>
...

So wird festgelegt, dass maximal 1 Email pro Stunde gesendet wird… standardmässig ist zudem festgelegt, dass erst ab Loglevel 6 gemailt wird. In diesem Fall werden die Alerts in 1 Email alle volle Stunde zusammengefasst.

Wichtige Alerts ab Level 1 werden jedoch sofort geschickt und nicht gruppiert.

Erwähnenswert ist auch, dass man auf Server wie Agent die zu überwachenden Logfiles auch mit Wildcards angeben kann… sehr fein beim Hosting mit verteilten Logfiles in den jeweiligen Ordnern.

Hier noch ein, zwei Screenshots des Webinterfaces: