Snort

topic - Kurzbeschreibung

Wikipedia

Snort ist ein freies Network Intrusion Detection System (NIDS) und ein Network Intrusion Prevention System (NIPS).

Es kann zum Protokollieren von IP-Paketen genauso wie zur Analyse von Datenverkehr in IP-Netzwerken in Echtzeit eingesetzt werden.

• Die Software wird überwiegend als Intrusion-Prevention-Lösung eingesetzt, um Angriffe unmittelbar ereignisgesteuert automatisch zu blockieren.
• Snort wurde ursprünglich von Martin Roesch entwickelt.
• Anschließend erfolgte die Weiterentwicklung bei seiner Firma Sourcefire, welche im Oktober 2013 von Cisco übernommen wurde.
• Im Jahr 2009 wurde Snort in die „Open Source Hall of Fame“ von InfoWorld als eine der besten Vertreter freier Open-Source-Software („Vorlage:Lang“) aufgenommen.
• Das Maskottchen von Snort ist ein Ferkel mit großer, schnaubender (englisch Vorlage:Lang) Nase.

|Hersteller            = Sourcefire
|Betriebssystem        = plattformunabhängig
|Kategorie             = Intrusion Detection System
|Programmiersprache    = C
|Lizenz                = GPL
|Website               = snort.org

Funktionsweise

Snort IDS console

Snort „liest“ direkt an der Netzwerkhardware den gesamten vorbeikommenden Netzwerk-Datenverkehr mit.

• Der Inhalt des Stroms an Datenpaketen wird mit charakteristischen Mustern von bekannten Angriffen verglichen.
• Diese Muster werden allgemein Signaturen genannt, die bei Snort in „Rules“ (Regeln) festgehalten werden.
• Zur Mustererkennung wird bei Snort der Aho-Corasick-Algorithmus verwendet.

Inzwischen gibt es für Snort einige tausend Signaturen.

• Da international sehr häufig neue Angriffsmethoden auf Computer und Netzwerke bekannt werden, sollte die Sammlung der Signaturen (ähnlich wie bei Virenscannern) regelmäßig aktualisiert werden.

Snort wird allgemein genutzt, um aktiv Netzwerkverkehr zu blockieren oder passiv verschiedene Formen eines Angriffs zu erkennen.

• Snort lässt sich auch mit anderer Software kombinieren, wie zum Beispiel BASE („Vorlage:Lang“), Sguil, OSSIM, SnortSnarf und Snorby zur bequemen Steuerung der Software und übersichtlichen grafischen Darstellung von möglichen Einbruchsdaten.

Netzwerk-Basierte IDS (NIDS)

Snort kann eingesetzt werden, um bekannte Angriffe auf die Schwachstellen von Netzwerksoftware zu entdecken.

• Snort führt Protokollanalysen durch, sucht und vergleicht Inhalte, um passiv verschiedene Formen eines Angriffs wie zum Beispiel einen Pufferüberlauf, Portscans, Angriffe auf Web-Anwendungen oder SMB-Probes zu erkennen.

Möglichkeiten für Angriffe sind gegeben durch so genannte Exploits, oder eigens dafür bestimmte Programme, wie etwa Internet-Würmer (z. B. Sasser oder W32.Blaster) die ihrerseits wiederum ein Backdoor-Programm (ursprünglich des Administrators Hintertüre bzw.

• der Wartungszugang) beinhalten können (bzw.
• selber eines sind) durch das der eigentliche Angriff schlussendlich erfolgt.
• Bei einem erkannten Angriff kann zum Beispiel ein Alarm ausgelöst und die Netzwerkpakete zur späteren Analyse oder Beweissicherung mitgeschrieben werden.

Network Intrusion Prevention System (NIPS)

Snort führt Protokollanalysen durch, sucht und vergleicht Inhalte, um aktiv Netzwerkverkehr zu blockieren. Mit Patches für den Snort-Quellcode von “Bleeding Edge Threats” ist die Nutzung von ClamAV zum Virenscan im Datenstrom möglich.

• Zusätzlich kann der Datenstrom mittels SPADE in den Netzwerklayern drei und vier auf Netzwerk-Anomalien (einschließlich historischer Daten) gescannt werden.
• Derzeit (2010/2011) hat es jedoch den Anschein, dass diese Patches nicht länger gepflegt werden.

Netzwerkanalysewerkzeug

Snort kann auch sehr gut bei der Netzwerkanalyse durch den Netzwerkadministrator helfen.

• Man kann es als Sniffer, ähnlich wie tcpdump, den Netzwerkverkehr gefiltert ausgeben lassen.
• Snort verfügt aber über mehr Optionen und kann tcpdump komplett ersetzen.
• Snort kann auch zur späteren Analyse einen Netzwerkdialog zwischen Server und Client mitschneiden und die reinen Nutzdaten (Payload) als eine Art Kommunikationsprotokoll zusammenführen.

Bedeutung im Security Incident Information Sharing (SIIS)

Bei IT-Spionage verwenden Täter zwar häufig Standard-Werkzeuge, wandeln diese aber vor dem Einsatz gegen ein Opfer leicht ab, um nicht von bereits veröffentlichten Signaturen von IPS- und Antiviren-Anbietern erkannt zu werden.

• Erkennt das Opfer den Angriff dennoch, und lässt von seinem Anbieter eine Signatur erstellen, so veröffentlicht dieser die Signatur.
• Die Täter werden so gewarnt und können anhand der Signatur unter bestimmten Umständen sogar erkennen, welches Opfer ihr Werkzeug entdeckt hat.

In vielen Ländern tauschen daher Behörden, bestimmte Industriebereiche aber auch NGOs und karitative Einrichtungen, die typische Ziele von IT-Spionage sind, im Rahmen von SIIS-Projekten Informationen über Sicherheitsvorfälle untereinander aus.

• Da SNORT-kompatible Regeln zum De-facto-Standard geworden sind, ist dies ebenfalls zum Standardformat beim Austausch von IPS-Signaturen geworden.

Kommerzielle Anbieter und Behörden, die Aufgaben innerhalb der Spionageabwehr wahrnehmen, haben sich ebenfalls auf SNORT-kompatible Signaturen spezialisiert.

SNORT selbst hat den Vorteil, dass Ziele, die aggressiv ausgespäht werden, es zum Einsatz bringen können, ohne einen Beschaffungsprozess anzustoßen.

• Letzteren können Täter leicht überwachen und so feststellen, welche Werkzeuge ihr Opfer zur Abwehr einsetzt um sich anzupassen.
• Typischerweise wird in solchen Fällen SNORT passiv eingesetzt.
• Die Täter wissen daher nicht, ob und woran ihre Bewegungen im Opfernetz erkannt werden.
• Ihr Verhalten kann so detailliert beobachtet werden und das Opfer kann die von ihnen aufgebaute Infrastruktur identifizieren und so eine konzentrierte Aktion vorbereiten, um sie, ihre Werkzeuge und bevorzugten Verbreitungsmethoden auszuhebeln und zu entfernen.

Geschichte

Snort wurde zuerst 1998 in einer Unix-Version veröffentlicht.

• Sein Programmierer Martin Roesch gründete später die Firma Sourcefire.
• Neben der unter der GNU GPL stehenden Version von Snort bietet Sourcefire auch eine kommerzielle Variante, die zusätzliche Entdeckungs- und Analysemethoden bietet.
• Sourcefire vertreibt Enterprise-Lösungen für das Network Security Monitoring (NSM) mit speziell entwickelter Hardware und kommerziellem Support.
• Anfang Oktober 2005 versuchte Check Point mit internationalem Hauptsitz in Tel Aviv, Israel, Sourcefire zu übernehmen.
• Der Kaufpreis wurde mit etwa 225 Millionen Dollar angegeben.
• Der Kauf scheiterte Anfang 2006 wegen des Widerstands der Bundesregierung der USA.
• Im Oktober 2013 gab das amerikanische Unternehmen Cisco Systems bekannt, dass es die Übernahme von Sourcefire abgeschlossen hat.

Sicherheitsgeschichte

Auch Snort selbst ist nicht von Sicherheitslücken verschont geblieben.

• Beispielsweise wurden im Frühjahr 2003 zwei Möglichkeiten zur Erzeugung eines Pufferüberlaufs in Snort gefunden.

Airsnort-Logo

Kein direkter Zusammenhang besteht mit dem Programm Airsnort – trotz des ähnlichen Namens und der Tatsache, dass Airsnort das Snort-Logo abgewandelt übernahm: das gleiche Schweinchen, jedoch mit Flügeln versehen.

Siehe auch

• Stateful Packet Inspection
• Contentfilter
• pfSense
• OPNsense

Literatur

• Ralf Spenneberg: Intrusion Detection und Prevention mit Snort 2 & Co. (mit CD-ROM). Addison-Wesley, November 2005 & 20. Dezember 2007, ISBN 3-8273-2134-4.
• Brian Caswell, Jay Beale, Andrew Baker: Snort Intrusion Detection and Prevention Toolkit. (Jay Beale’s Open Source Security mit CD-ROM), Elsevier Science & Technology; 17. Dezember 2006, ISBN 978-1-59749-099-3.
• Kerry J. Cox, Christopher Gerg: Managing Security with Snort & IDS Tools. 1st Edition, O’Reilly Verlag August 2004, ISBN 0-596-00661-6 Leseprobe
• Peer Heinlein, Thomas Bechtold: Snort, Acid & Co. Open Source Press, Juni 2004, ISBN 3-937514-03-1.

Weblinks

• Homepage
• sourcefire.com – Hersteller von Snort
• emergingthreats.net – Community für Snort-Regeln
• Kostenloses IDS/IPS-Tool Snort im Test

Schnittstellen

• Snorby – a new and modern Snort IDS front-end – Ruby on Rails Web-Frontend
• sguil.sf.net – Tcl/Tk-Schnittstelle
• IDS Policy Manager – Verwalter für Regeln
• dragos.com/cerebus – ncurses-Browser für Snort-Logs
• Basic Analysis and Security Engine – Web-Frontend

Intrusion Prevention System

The Intrusion Prevention System (IPS) system of OPNsense is based on Suricata and utilizes Netmap to enhance performance and minimize CPU utilization. This deep packet inspection system is very powerful and can be used to detect and mitigate security threats at wire speed.

IDS and IPS

It is important to define the terms used in this document. An Intrustion Detection System (IDS) watches network traffic for suspicious patterns and can alert operators when a pattern matches a database of known behaviors. An Intrusion Prevention System (IPS) goes a step further by inspecting each packet as it traverses a network interface to determine if the packet is suspicious in some way. If it matches a known pattern the system can drop the packet in an attempt to mitigate a threat.

The Suricata software can operate as both an IDS and IPS system.

Choosing an interface

You can configure the system on different interfaces. One of the most commonly asked questions is which interface to choose. Considering the continued use IPv4, usually combined with Network Address Translation, it is quite important to use the correct interface. If you are capturing traffic on a WAN interface you will see only traffic after address translation. This means all the traffic is originating from your firewall and not from the actual machine behind it that is likely triggering the alert.

Rules for an IDS/IPS system usually need to have a clear understanding about the internal network; this information is lost when capturing packets behind NAT.

Without trying to explain all the details of an IDS rule (the people at Suricata are way better in doing that), a small example of one of the ET-Open rules usually helps understanding the importance of your home network.

alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Observed Glupteba CnC Domain in TLS SNI"; flow:established,to_server; tls_sni; content:"myinfoart.xyz"; depth:13; isdataat:!1,relative; metadata: former_category MALWARE; reference:md5,4cc43c345aa4d6e8fd2d0b6747c3d996; classtype:trojan-activity; sid:2029751; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, signature_severity Major, created_at 2020_03_30, updated_at 2020_03_30;)

The $HOME_NET can be configured, but usually it is a static net defined in RFC 1918. Using advanced mode you can choose an external address, but bear in mind you will not know which machine was really involved in the attack and it should really be a static address or network.

$EXTERNAL_NET is defined as being not the home net, which explains why you should not select all traffic as home since likely none of the rules will match.

Since the firewall is dropping inbound packets by default it usually does not improve security to use the WAN interface when in IPS mode because it would drop the packet that would have also been dropped by the firewall.

Note

IDS mode is available on almost all (virtual) network types. IPS mode is only available with supported physical adapters.

General setup

The settings page contains the standard options to get your IDS/IPS system up and running.

---

Enabled	Enable Suricata
IPS mode	When enabled, the system can drop suspicious packets. In order for this to work, your network card needs to support netmap. The action for a rule needs to be “drop” in order to discard the packet, this can be configured per rule or ruleset (using an input filter)
Promiscuous mode	Listen to traffic in promiscuous mode. (all packets in stead of only the ones addressed to this network interface)
Enable syslog alerts	Send alerts to syslog, using fast log format
Enable eve syslog output	Send alerts in EVE format to syslog, using log level info. This will not change the alert logging used by the product itself. Drop logs will only be send to the internal logger, due to restrictions in suricata.
Pattern matcher	Controls the pattern matcher algorithm. Aho–Corasick is the default. On supported platforms, Hyperscan is the best option. On commodity hardware if Hyperscan is not available the suggested setting is “Aho–Corasick Ken Steele variant” as it performs better than “Aho–Corasick”.
Interfaces	Interfaces to protect. When in IPS mode, this need to be real interfaces supporting netmap. (when using VLAN’s, enable IPS on the parent)
Rotate log	Log rotating frequency, also used for the internal event logging (see Alert tab)
Save logs	Number of logs to keep

Tip

When using an external reporting tool, you can use syslog to ship your EVE log easily. Just enable “Enable EVE syslog output” and create a target in System ‣ Settings ‣ Logging / Targets. (filter application “suricata” and level “info”)

Note

When using IPS mode make sure all hardware offloading features are disabled in the interface settings (Interfaces ‣ Settings). Prior to version 20.7, “VLAN Hardware Filtering” was not disabled which may cause issues for some network cards.

Advanced options

Some less frequently used options are hidden under the “advanced” toggle.

---

Home networks	Define custom home networks, when different than an RFC1918 network. In some cases, people tend to enable IDPS on a wan interface behind NAT (Network Address Translation), in which case Suricata would only see translated addresses in stead of internal ones. Using this option, you can define which addresses Suricata should consider local.
default packet size	With this option, you can set the size of the packets on your network. It is possible that bigger packets have to be processed sometimes. The engine can still process these bigger packets, but processing it will lower the performance.

Download rulesets

When enabling IDS/IPS for the first time the system is active without any rules to detect or block malicious traffic. The download tab contains all rulesets available on the system (which can be expanded using plugins).

In this section you will find a list of rulesets provided by different parties and when (if installed) they where last downloaded on the system. In previous versions (prior to 21.1) you could select a “filter” here to alter the default behavior of installed rules from alert to block. As of 21.1 this functionality will be covered by Policies, a separate function within the IDS/IPS module, which offers more fine grained control over the rulesets.

Note

When migrating from a version before 21.1 the filters from the download rulesets page will automatically be migrated to policies.

Policies

The policy menu item contains a grid where you can define policies to apply to installed rules. Here you can add, update or remove policies as well as disabling them. Policies help control which rules you want to use in which manner and are the prefered method to change behaviour. Although you can still update separate rules in the rules tab, adding a lot of custom overwrites there is more sensitive to change and has the risk of slowing down the user-interface.

A policy entry contains 3 different sections. First some general information, such as the description and if the rule is enabled as well as a priority. Overlapping policies are taken care of in sequence, the first match with the lowest priority number is the one to use.

Secondly there are the matching criterias, these contain the rulesets a policy applies on as well as the action configured on a rule (disabled by default, alert or drop), finally there is the rules section containing the metadata collected from the installed rules, these contain options as affected product (Android, Adobe flash, …) and deployment (datacenter, perimeter).

The last option to select is the new action to use, either disable selected rules, only alert on them or drop traffic when matched.

Note

The options in the rules section depend on the vendor, when no metadata is provided in the source rule, none can be used at our end.

Installed rules

The rules tab offers an easy to use grid to find the installed rules and their purpose, using the selector on top one can filter rules using the same metadata properties available in the policies view.

Tip

After applying rule changes, the rule action and status (enabled/disabled) are set, to easily find the policy which was used on the rule, check the matched_policy option in the filter. Manual (single rule) changes are being marked as policy “__manual__”

Fingerprinting

OPNsense includes a very polished solution to block protected sites based on their SSL fingerprint. You can manually add rules in the “User defined” tab.

Alerts

In the “Alerts” tab you can view the alerts triggered by the IDS/IPS system. Use the info button here to collect details about the detected event or threat.

Advanced configuration

OPNsense supports custom Suricata configurations in suricata.yaml format. In order to add custom options, create a template file named custom.yaml in the /usr/local/opnsense/service/templates/OPNsense/IDS/ directory.

Since this file is parsed by our template system, you are able to use template tags using the Jinja2 language.

Available rulesets

Emerging Threats

Emerging Threats (ET) has a variety of IDS/IPS rulesets. There is a free, BSD-licensed version and a paid version available.

ET Open

The ETOpen Ruleset is not a full coverage ruleset and may not be sufficient for many regulated environments and thus should not be used as a standalone ruleset.

OPNsense has integrated support for ETOpen rules.

• For details and Guidelines see: http://doc.emergingthreats.net/bin/view/Main/EmergingFAQ
• For rules documentation: http://doc.emergingthreats.net/

ETPro Telemetry

Proofpoint offers a free alternative for the well known ET Pro Telemetry edition ruleset.

Abuse.ch

Abuse.ch offers several blacklists for protecting against fraudulent networks.

SSL Blacklist

SSL Blacklist (SSLBL) is a project maintained by abuse.ch. The goal is to provide a list of “bad” SSL certificates identified by abuse.ch to be associated with malware or botnet activities. SSLBL relies on SHA1 fingerprints of malicious SSL certificates and offers various blacklists.

See for details: https://sslbl.abuse.ch/

Feodo Tracker

Feodo (also known as Cridex or Bugat) is a Trojan used to commit ebanking fraud and steal sensitive information from the victim’s computer, such as credit card details or credentials. At the moment, Feodo Tracker is tracking four versions of Feodo, and they are labeled by Feodo Tracker as version A, version B, version C and version D:

• Version A Hosted on compromised webservers running an nginx proxy on port 8080 TCP forwarding all botnet traffic to a tier 2 proxy node. Botnet traffic usually directly hits these hosts on port 8080 TCP without using a domain name.
• Version B Hosted on servers rented and operated by cybercriminals for the exclusive purpose of hosting a Feodo botnet controller. Usually taking advantage of a domain name within ccTLD .ru. Botnet traffic usually hits these domain names using port 80 TCP.
• Version C Successor of Feodo, completely different code. Hosted on the same botnet infrastructure as Version A (compromised webservers, nginx on port 8080 TCP or port 7779 TCP, no domain names) but using a different URL structure. This Version is also known as Geodo and Emotet.
• Version D Successor of Cridex. This version is also known as Dridex

See for details: https://feodotracker.abuse.ch/

URLHaus List

OPNsense version 18.1.7 introduced the URLHaus List from abuse.ch which collects compromised sites distributing malware.

See for details: https://urlhaus.abuse.ch/

App detection rules

OPNsense 18.1.11 introduced the app detection ruleset. Since about 80 percent of traffic are web applications these rules are focused on blocking web services and the URLs behind them.

If you want to contribute to the ruleset see: https://github.com/opnsense/rules

How-tos

• IPS SSLBlacklists & Feodo Tracker
• IPS Block SSL certificates