SNORT as a service IPS

Introduction

Much has been said about SNORT, but in most articles we are talking about SNORT, as a means of total monitoring of the network, which collects all the data from the network interface. In this article, I will tell you how to assemble a design in which SNORT in IPS mode does not monitor all traffic on the interface, but only traffic that can be described using the rules for iptables. I will not touch on the rule settings, it will be exclusively about how to assemble SNORT to work in IPS mode on a bare system and how to approach the abstract service protection by it. The assembly and launch of SNORT will also be described.

How does it work?

Having entered SNORT, the packet sequentially passes through decoders, preprocessors, and only then it enters the detector, which begins to apply the rules. The task of decoders is to ensure that the data of the network and transport layers (IP, TCP, UDP) are “pulled out” of the data of the data link layer (Ethernet, 802.11, token ring ...).



The task of preprocessors is to prepare data from the protocols of the transport and network layers for the process of applying the rules. For our case, we will use a preprocessor to work with TCP, the list of tasks it solves in general is as follows:

• Status monitoring (protocol compliance monitoring)
• Session assembly (combining data from multiple session packets)
• Normalization of the protocol (a rather slippery feature with editing the packet header on the fly)

Proper setup of preprocessors can significantly increase system performance and reduce the amount of garbage data entering the detector. Also, due to the architectural features, it is relatively easy to connect a self-written preprocessor to SNORT.

As a result, “superpackets” are formed before sending to the detector, to which the rules begin to apply. The process of applying the rules comes down to searching in the “superpacket” of signatures defined in the rule. The rules themselves consist of a description of the traffic, the desired signature, a description of the threat, and a description of the reaction to the discovery.

Compilation of SNORT.

Download the latest Ubuntu 11.04. Installation is described for a 32-bit system. Download everything you need: Install the necessary packages: Configure and install the downloaded software from the source in the following order: For configure scripts, it is better to force installation directories to avoid unpleasant surprises If we see the line “Build NFQ DAQ module ...: yes” and everything compiled without problems, then we are on the right track. Now the key point of the whole undertaking is the SNORT assembly: --enable-ipv6 - support for IP v6 (all of a sudden captain!). --enable-gre - support for GRE encapsulation. --enable-targetbased - support for collecting fragmented packets.

daq-0.5.tar.gz
libdnet-1.11.tar.gz
libnetfilter_queue-1.0.0.tar
libnfnetlink-1.0.0.tar
libpcap-1.1.1.tar.gz
pcre-8.12.zip
snort-2.9.0.5.tar.gz
snortrules-snapshot-2903.tar.gz



apt-get install bison flex gcc g++ zlib1g-dev



pcre-8.12.zip
libpcap-1.1.1.tar.gz
libdnet-1.11.tar.gz
libnfnetlink-1.0.0.tar
libnetfilter_queue-1.0.0.tar
daq-0.5.tar.gz



./configure --libdir=/usr/lib --includedir=/usr/include



./configure --libdir=/usr/lib --includedir=/usr/include --enable-ipv6 --enable-gre --enable-targetbased --enable-decoder-preprocessor-rules --enable-active-response --enable-normalizer --enable-reload --enable-react --enable-zlib




--enable-decoder-preprocessor-rules - support for rules for responding to anomalies detected in traffic when preprocessors and decoders work.
--enable-active-response - support for introducing a package into a session when a rule is triggered.
--enable-normalizer - protocol normalizer support.
--enable-reload - the ability to load / unload rules without rebooting SNORT.
--enable-react - support for immediate session termination (RST) when a rule is triggered.
--enable-zlib - support for processing compressed traffic.

Next make; make install . SNORT is installed.

Setting up a combat launch.

A freshly downloaded snort config makes a heavy impression on an inexperienced user, but if you understand its structure, then understanding it is easy. An abbreviated version of the smallest config that solves our problem in general looks like this: For simplicity, we will have only one rule in the test.rules file: This rule says that if an abc123 substring is found in incoming tcp packets , the source will be sent immediately RST, and the session will be interrupted. A dangerous packet will not get into the system beyond IPS. We start SNORT: -Q - work in IPS mode --daq - packet source --daq-var - packet source parameters -c - path to the config -l - path to the logs

# Пункт 1: Глобальные переменные для конфига
#Используются в кофиге и правилах
var HOME_NET any
var RULE_PATH ../rules
# Пункт 2: настройка декодеров
config disable_decode_alerts
……
# Пункт 3: настройка детектора
# Разные тонкости применения правил
config pcre_match_limit: 3500
……
# Пункт 5: Настройка препроцессоров
# Препроцессоры нормализации пакетов
# нормализуют протоколы на лету, от чего,иногда, случаются неожиданности
preprocessor normalize_ip4
….
# Препроцессор обработки дефрагментированых пакетов
preprocessor frag3_global: max_frags 65536
…
# Препроцессоры контроля состояний и построения сеансов
preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp ….
…
# Пункт 6: подключение библиотек детализации вывода
include classification.config
…..
# Пункт 7: подключение правил
include $RULE_PATH/test.rules


reject tcp any any -> any any (msg:"Test pattern for snort abc123"; content:"abc123"; classtype:shellcode-detect; sid:310; rev:1;)


snort -Q --daq nfq --daq-var queue=2 -c /home/ubuntu/Downloads/snort/etc/snort.conf -l /var/log/snort -A full






-A full - detailed logs (description of attacks and traffic dumps)
-D - work in daemon mode (use when everything is debugged)

If the launch breaks down with errors, then do not be sad - most likely you need to correct the file paths in the config.

Create a queue.

The system’s packet filter can be configured to transfer the received packet from the kernel level to the user level, where the user program will process it and transfer it back to the kernel level, in our case, this program is SNORT. Since we started SNORT to work with a numbered queue (NFQUEUE), we need to put filtered traffic in this queue:
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j NFQUEUE --queue-num 2

Why was the PREROUTING chain chosen?

In the iptables model, the package falls into the PREROUTING base queuebefore any routing rules are applied to it. Sending a packet to SNORT at this stage is convenient because we can either process it locally or forward it further, for example, using NAT. The advantage of using numbered queues is that you can create several queues and pass the traffic of each queue through a snort running with a set of rules tailored for filtered traffic. A serious drawback of this approach is that in the event of a SNORT crash, the protected service becomes unavailable, since there is no one to transfer data from user mode back to the kernel. After starting SNORT and creating the queue, you should immediately check the operation by sending, for example via netcat, the signature from the rule, abc123, to the queue. If everything was done correctly, the connection will be disconnected immediately.

Monitoring

Running with the described parameters, SNORT will write a file for alert for each detected threat (it can also write to the database or send syslog):

[**] [1:310:1] Test pattern for snort abc123 [**]
[Classification: Executable Code was Detected] [Priority: 1]
01/19-12:03:12.155213136 172.16.249.1:56473 -> 172.16.249.130:8080
TCP TTL:64 TOS:0x0 ID:1241 IpLen:20 DgmLen:59 DF
***AP*** Seq: 0x9510F391 Ack: 0xC40C0E14 Win: 0x8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 125531844 9470333

And to write in the log file a piece of the session in which the signature was detected, this can be useful for detecting detection errors. On this, the work of SNORT ends and “SNORT log analysis systems” come into play. De facto, these are sets of scripts of varying degrees of wretchedness, to which, in some cases, the heartbreaking “web interface” (BASE, ACID ...) is attached. Their main disadvantages are the inability to conduct flexible data analysis and inefficient work with the DBMS, which results in the inability to work with large amounts of data. In my experience, the only solution that makes working with snort logs tolerable is Splunk. In general, Splunk is a log management system that saves them, indexes and secures a convenient interface for working with the resulting database. This is proprietary software, which is conditionally free (the volume of indexed data per day is not more than 500 Mb, which is more than enough for snort). The system combines the convenience of management and the ability to work with large amounts of data, and most importantly: for this system there is a plugin specially tailored for working with SNORT logs. You can download Splunkhere

Install splunk:
dpkg -i splunk-4.2.1-98164-linux-2.6-intel.deb
Run:
/opt/splunk/bin/splunk start

Go to the web-face, find and install the plugin:


Next, add the data source - file. Everything is intuitive there and the only subtle point is that the Source Type must be set manually: snort_alert_full . When everything is ready, we generate an alert (via netcat we send abc123 to the protected port). And we see in splunk:



The column on the left shows the data that the parser recognized and on which the indices for incoming data are built. Based on these data, you can analyze using the built-in query language, you can build graphs, you can display sources on a map, and much, much more.



In addition, the process of creating your own plug-ins is described on the manufacturer's website, which allows you to create your own plug-in, which will be sharpened for a specific task.

Conclusion

Before launching snort in the productive, so that it would not be excruciatingly painful, you should:

• Build a version control system for rules and store the rules on a third-party host (SVN is fine).
• Develop a plan for emergency operation (if the snort has fallen, and traffic does not go).
• Recovery plan in case the piece of hardware with snort breaks with data loss.
• Create a test rule of the type described above abc123, which should check the operation of the snort every time after making any changes.

I will be happy to answer questions.