11.05.2020, aktualisiert am 12.05.2020

10689

Eigene Suricata-Regeln auf der OPNsense

Hallo zusammen,

die letzten 3 Tage habe ich damit verbracht, auf meinen OPNsense Firewalls eigene Regeln für die Einbruchserkennung (IDS/IPS) einzurichten. Dabei sollten Regeln zentral für alle OPNsense zur Verfügung gestellt werden. Aufgrund einiger Fallstricke in den von mir per Suchmaschine gefunden Anleitungen dazu hier ein kurzes Tutorial.

Inhaltsverzeichnis

Behandeltes Setup, Voraussetzungen

ssh Root Zugriff auf die OPNSense aktivieren

Speicherort der Konfigurationsdateien

Bearbeiten der Regelsatz-XML-Datei

Dateien auf dem Webserver

Hinweis IIS

Sicherheitshinweis

Aktivieren der Regeln

Suricata-Logs auf der OPNsense

Hilfreiche Links

Behandeltes Setup, Voraussetzungen

Verwendet wurden 3 Firewalls mit OPNsense 20.1.1-amd64 . OPSense verwendet dabei Suricata 4.1.6. Auf den Firewalls ist bereits der Dienst Einbruchserkennung bereits aktiviert. Eine Anleitung hierzu findet sich unter https://docs.opnsense.org/manual/ips.html

Die Regeln sollen auf einem Webserver im LAN unter der url

http://192.168.20.21/suricata

zur Verfügung gestellt werden. Bei mir war das ein IIS auf einem Windows 2012R2. Grundsätzlich kann man aber auch jeden anderen Webserver nutzen.

Ich habe einen Regelsatz für das Zulassen von Downloads aus den ESET-Repositories erstellt. Ohne diese Zusatzregeln bricht bei uns suricata den Download von ausführbaren Binärdateien bei der Installation oder Autoupdate von ESET Programmkomponenten (nicht bei den Virenaktualisierungen) ab. Ich bleibe mal bei diesem Beispiel.

Was ich hier nicht behandle ist der Syntax der Regeln selbst. Dazu findet man aber im Suricata-User-Guide und mit der Suchmaschine seiner Wahl jede Menge Infos.

ssh Root Zugriff auf die OPNSense aktivieren

Auf der OPNsense muss als root per console bzw. ssh zugegriffen werden. Siehe auch https://docs.opnsense.org/manual/settingsmenu.html

Zunächst wir das Menü System: Einstellungen: Verwaltung aufgerufen werden. Unter "Secure Shell" finden sich die entsprechenden Parameter. Entsprechend dem allgemein üblichen Vorgehen sollte hier der Root-Zugang nicht direkt aktiviert werden. Besser ist es, den SSH Zugang auf eine Benutzergruppe zu beschränken und dann mittels sudo -i auf root zu wechseln. Quick & dirty geht aber auch. Korrekt würde quick&dirty so aussehen:

Haken bei Aktiviere Secure Shell setzen
Anmeldegruppe auf wheel, admin setzen
Haken bei Erlaube Anmeldung mit dem root-Benutzer
nochmal darüber nachdenken, ob man das wirklich so machen will, besser ist es eine separate SSH-Benutzergruppe anzulegen und den Wechsel auf root zu erlauben (weiter unter im Menü System: Einstellungen: Verwaltung: Authentifizierung: Sudo). Das ist aber nicht Thema dieser Anleitung.
Haken bei Anmeldung mit Passwort erlauben
auch nochmal nachdenken, ob das sein soll. Besser ist es, den authorisierenden Schlüssel für den SSH-Benutzer zu konfigurieren.
Port auf 22 lassen
Schnittstelle passen auswählen

Speicherort der Konfigurationsdateien

Die allgemeinen Konfigurationsdateien von Suricata befinden sich hier:

/usr/local/etc/suricata/

Allerdings muss man hier nichts anpassen. Interessant ist aber die Datei classification.config

$ cat /usr/local/etc/suricata/classification.config
# AUTO GENERATED, DO NOT EDIT.
# config classification:shortname,short description,priority
#

#Traditional classifications. These will be replaced soon

config classification: not-suspicious,Not Suspicious Traffic,3
config classification: unknown,Unknown Traffic,3
...

Hier findet man die Bezeichner für die möglichen Klassifikationen (classtype), die der Regel später eine bestimmte Priorität zuweisen.

Wichtiger ist das folgende Verzeichnis:

/usr/local/opnsense/scripts/suricata/metadata/rules/

Hier sind die Verweise auf Regelsätze in XML-Dateien gespeichert. Alle XML-Dateien werden von suricata geladen und die darin referenzierten Regelsätze werden geladen. Hier erzeugt man eine neue Datei mit der Endung .xml

Bearbeiten der Regelsatz-XML-Datei

Mittels

vi /usr/local/opnsense/scripts/suricata/metadata/rules/custom.xml

startet man dann auch den beliebten Editor vi. Dessen Bedienung hier zu besprechen, würde etwas den Rahmen sprengen. Man tut aber gut daran, sich mit dessen Basics zu befassen, denn im Notfall muss man sich mittels serieller Console auf seine OPNsense verbinden und die Konfiguration mit diesem tollen Editor bearbeiten können. Macht man alles richtig beim Konfigurieren ist das aber nicht nötig.

Alternativ kann man aber auf der OPNsense auch ee verwenden.
Der Syntax der Regelset-Verweis-Dateien ist variabel. Entsprechend XML gibt es da verschiedene Möglichkeiten. Man kann sich die verschiedenen installierten Dateien gerne ansehen.

In meinem Fall kommt in die Datei custom.xml folgender Inhalt:

<ruleset documentation_url="http://192.168.20.21/suricata">  
    <location url="http://192.168.20.21/suricata/" prefix="custom"/>  
    <files>
        <file description="eset">eset.rules</file>  
        <file description="custom">custom.rules</file>  
    </files>
</ruleset>

In die Sektion <files></files> können beliebig viele Dateien referenziert werden. Angegeben wird der Dateiname. Dieser ist relativ zu Location.

Das Verzeichnis sieht bei mir dann so aus:

$ ls /usr/local/opnsense/scripts/suricata/metadata/rules/
custom.xml              et-open.xml             et-telemetry.xml        opnsense.xml            sslbl.xml

Das wars schon. Folgende Nacharbeiten sollten erfolgen:

Regel über die WebUI Dienste: Einbruchserkennung: Verwaltung: Herunterladen aktualisiseren (Herunterladen und aktualisieren).
root-SSH Zugang wieder deaktivieren

Die Regelsätze müssten (noch deaktiviert) in der WebUI auftauchen. Bezeichnet werden sie dort als

custom/custom
custom/eset

Das entsprich dem Location-prefix und der file-description aus dem XML-File. So bleibt alles schön übersichtlich.

Dateien auf dem Webserver

Das ist relativ simpel. Auf dem Webserver legt man die entsprechenden Dateien an und befüllt sie mit suricata Regeln. Bei mir sieht die Datei eset.rules wie folgt aus:

# 
# eset.rules 
# Regel, ESET-Antivirus zuzulassen 
# 
# see https://doc.emergingthreats.net/bin/view/Main/SidAllocation for sid allocation 
# Emerging Threats Threats SID Allocation 
# 1000000-1999999 Reserved for Local Use -- Put your custom rules in this range to avoid conflicts 
# 
# 
# -- ESET Repository pass rules 
pass ip 91.228.167.25 any -> any any (msg:"ESET Repository 91.228.167.25"; classtype:not-suspicious; sid:1001000; rev:1;)   
pass ip 91.228.166.23 any -> any any (msg:"ESET Repository 91.228.166.23"; classtype:not-suspicious; sid:1001001; rev:1;)   
pass ip 38.90.226.20 any -> any any (msg:"ESET Repository 38.90.226.20"; classtype:not-suspicious; sid:1001002; rev:1;)   

Wichtig: siehe auch https://doc.emergingthreats.net/bin/view/Main/SidAllocation Die Regeln müssen eine für die suricata-Instanz eindeutige sid haben. Werden sid mehrfach vergeben, werden alle folgenden Regeln nicht geladen und auch nicht angewendet. Viele suricata-Beispiele verwenden recht simple sids. Die sollte man ändern. Bei nicht geladenen Regeln sollte man das Log überprüfen.

Den Zugriff auf die Regeldateien überprüft man am besten über den Browser.

http://192.168.20.21/suricata/eset.rules

Hinweis IIS

Hier waren noch weitere Konfigurationsschritte notwendig, da *.rules Dateien per Default nicht als Text ausgeliefert werden. Für das Verzeichnis auf dem Webserver musste man:

Anforderungsfilterung/Dateinamenerweiterung: .rules bestehenden Eintrag löschen
und einen Neuen mit .rules = True erstellen
MIME-Typ: .rules auf text/html stellen

Nicht getestet habe ich, ob man auch andere Dateiendungen verwenden kann. Ich vermute schon, aber ich wollte beim suricata-Syntax bleiben.

Sicherheitshinweis

Wenn ein Angreifer zugriff auf referenzierten *.rules Dateien bekommt, kann man suricata sehr einfach kompromitieren, da die Regeln ja automatisch geladen werden. Also muss der Webserver genau so abgesichert werden, wie der Zugang zur OPNsense.

Aktivieren der Regeln

In der WebUI der OPNsense können die Regeln jetzt aktiviert werden (anhaken und ausgewählte aktivieren). Überprüfen kann man das unter dem Reiter Regeln. Dort sollte die Regel über die Suche auffindbar sein. Bei jeder Regelaktualisierung werden die Regeln dann vom Webserver geladen.

Suricata-Logs auf der OPNsense

Fehler beim Laden der Regelsätze findet man in der WebUI im allgemeinen Log der OPNsense unter System: Protokolldateien: Allgemein
Fehler beim Verarbeiten der Regeln findet man in der WebUI unter Dienste: Einbruchserkennung: Protokolldatei