Session based Rules: Writing flowbit based rules for Suricata IDS/IPS

Majority of Suricata/Snort rules are packet based, some times we need to write session based rules spanning across multiple packets of same session. We have to use flowbits keyword to write session based Rules.

As per Suricata documentation

flowbits: set, name                Will set the condition/'name', if present, in the flow.
flowbits: isset, name              Can be used in the rule to make sure it generates an alert                          
                                   when the rule matches and the condition is set in the flow.
flowbits: toggle, name             Reverses the present setting. So for example if a condition is set, 
                                   it will be unset and vice-versa.
flowbits: unset, name              Can be used to unset the condition in the flow.
flowbits: isnotset, name           Can be used in the rule to make sure it generates an alert
                                   when it matches and the condition is not set in the flow.
flowbits: noalert                  Does not generate an alert for this rule.

If packet 1 contains content "DARSHANAM" set condition/name fb1 and don't trigger an alert. If packet 2 contains content "DARSHANAM" set condition/name fb2 and don't trigger an alert also check if condition/name fb1 is set.

alert tcp any 5900 -> any any (msg:"Flowbit based Rule 1"; flow:established,to_client; content:"DARSHANAM"; offset:0; flowbits:set,fb1; flowbits:noalert; reference:cve,CVE-2014-nnnn; sid:11223341; )

alert tcp any any -> any 5900 (msg:"Flowbit based Rule 2"; flow:established,to_server; content:"DARSHANAM"; offset:0; flowbits:isset,fb1; flowbits:set,fb2; flowbits:noalert; reference:cve,CVE-2014-nnnn; sid:11223342; )

alert tcp any 5900 -> any any (msg:"Flowbit based Rule 3"; flow:established,to_client; content:"|00 00 00 00|"; offset:0; depth:4; flowbits:isset,fb2; flowbits:set,fb3; flowbits:noalert; reference:cve,CVE-2014-nnnn; sid:11223343; )

alert tcp any any -> any 5900 (msg:"Flowbit based Rule 4"; flow:established,to_server; byte_test:1,=,0,7; flowbits:isset,fb3; flowbits:set,fb4; flowbits:noalert; reference:cve,CVE-2014-nnnn; sid:11223344; )

alert tcp any any -> any 5900 (msg:"Alert Rule: Flowbit based Rule"; flow:established,to_server; byte_test:1,=,2,0; content:"|00 00 00 07|"; flowbits:isset,fb4; flowbits:unset,fb4; reference:cve,CVE-2014-nnnn; sid:44448888; )

Alerts are logged to /var/log/suricata/alert-debug.log

+================
TIME:              01/27/2014-15:37:28.625783
PKT SRC:           wire/pcap
SRC IP:            192.16.1.2
DST IP:            192.16.8.158
PROTO:             6
SRC PORT:          38603
DST PORT:          5900
TCP SEQ:           3520133923
TCP ACK:           3147758094
FLOW:              to_server: TRUE, to_client: FALSE
FLOW Start TS:     01/27/2014-15:36:42.465932
FLOW IPONLY SET:   TOSERVER: TRUE, TOCLIENT: TRUE
FLOW ACTION:       DROP: FALSE
FLOW NOINSPECTION: PACKET: FALSE, PAYLOAD: FALSE, APP_LAYER: TRUE
FLOW APP_LAYER:    DETECTED: FALSE, PROTO 0
FLOWBIT:           fb1
FLOWBIT:           fb2
FLOWBIT:           fb3
FLOWBIT:           fb4
PACKET LEN:        82
PACKET:
 0000  00 50 88 XX YY ZZ A0 DD  C1 XX YY ZZ 08 00 45 00   .P..b... ..J}..E.
 0010  00 44 31 E1  40   00  40  06   A7 12   C0 A8 01 02 C0 A8   .D1.@.@. ........
 0020  08 9E 96 CB 17 0C D1 D0  FB 23 BB 9E FA 0E 80 18       ........ .#......
 0030  00 73 E7 C9 00 00 01 01  08 0A 57 AB CE CC 25 92         .s...... ..W...%.
 0040  AF 17 02 00 00 03 00 00  00 07 FF FF FF E0 FF FF           ........ ........
 0050  FF 20                                              .
ALERT CNT:           1
ALERT MSG [00]:      Alert Rule: Flowbit based Rule
ALERT GID [00]:      1
ALERT SID [00]:      44448888
ALERT REV [00]:      0
ALERT CLASS [00]:    
ALERT PRIO [00]:     3
ALERT FOUND IN [00]: PACKET
ALERT IN TX [00]:    N/A
PAYLOAD LEN:         16
PAYLOAD:
 0000  02 00 00 03 00 00 00 07  FF FF FF E0 FF FF FF 20   ........ .......
+================

From the above log we can see all the flowbits conditions/names are hit and inturn triggers an alert "Alert Rule: Flowbit based Rule", sid 44448888.

https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Flow-keywords

Bittorrent: Detection Mechanisms

Bittorrent is a Peer to Peer(P2P) protocol used to share files and data in internet. In this article we are going to see what are the different mechanisms which can be used to detect and block Bittorrent communication across network.

Below snapshot shows HTTP request which Bittorrent Client uses to communicate with Bittorrent Servers. In the request we can see different parameters like client id, port number.

We can observe that Bittorrent client uses different User Agent request headers like BTWebClient, Bittorrent etc.

UDP is using Source port as 24615, which is being communicated to Bittorrent Server as HTTP Request.

So we can detect or block Bittorrent based on HTTP Request URI or User-Agent header strings or UDP protocol communication.

Below are few Signatures which we can use to detect Bittorrent.

alert udp any any -> any any ( msg: "Bit Torrent UDP"; content:"41 02"; offset:0; depth:2; content:"38"; offset:13;depth:1; content:"08"; offset:21;depth:1; sid:8888881; rev: 1; )
alert udp any any -> any any ( msg: "Bit Torrent Protocol"; content:"|13|bittorrent|20|protocol";  offset:0; sid:8888882; rev: 1; )
alert udp any any -> any any ( msg: "Bit Torrent UDP Communication"; content:"d1|3a|ad2|3a|id20|3a|"; sid:8888883; rev: 1; )  
 

Below Signature triggers and alerts when the content is seen in HTTP Request URI
alert tcp any any -> any 80 ( msg: "Bit Torrent: HTTP Request"; content:"info_hash=";  pcre:"/announce\?info_hash=/Ui"; sid:8888884; rev: 1; )


Observed following User-Agent strings as part of HTTP Requests
        User-Agent: BitTorrent/7610(27328)
        User-Agent: BTWebClient/7610(27328)
which can be detected using following Signatures
alert tcp any any -> any 80 ( msg: "Bit Torrent: HTTP User Agent 1"; content:"User-Agent: BitTorrent";  sid:8888885; rev: 1; ) 
alert tcp any any -> any 80 ( msg: "Bit Torrent: HTTP User Agent 2"; content:"User-Agent: BTWebClient";  sid:8888886; rev: 1; ) 

Posts related to Snort IDS/IPS which might be of interest to you.
http://darshanams.blogspot.in/2011/05/snort-logging-alerts-to-syslog-server.html
http://darshanams.blogspot.in/2010/06/snort-preprocessors-and-alerts.html
http://darshanams.blogspot.in/2012/05/installing-snort-from-source-as-ips.html

To know about Google Talk Jabber protocol communication
http://darshanams.blogspot.in/2008/11/deciphering-google-talk-jabber.html

For Zebra/Bittorrent protocol communication
http://darshanams.blogspot.in/2009/03/i-was-just-checking-my-mails.html

P.S Signatures given above are neither tested nor fine tuned. Just an 
idea how to detect Bit Torrent communication.

Installing SNORT as IPS, building from Source

Install below libraries from source in given order by running commands "configure", "make" and "make install".
    pcre-8.30.zip
    libdnet-1.12.tgz
    libnetfilter_queue-1.0.1.tar
    libnfnetlink-1.0.0.tar
    libpcap-1.2.1.tar.gz
    daq-0.6.2.tar.gz
    snort-2.9.2.2.tar.gz
    snortrules-snapshot-2922.tar.gz
At the point of writing this article above tar/zip files were the latest available.

By default most of the packages install at /usr/local so forcing them to install in /usr. For example if you install libpcap-1.2.1 by just running ./configure and check the running version, it may show u as libpcap-0.9.4. To overcome the issue we are building with below argument
./configure –enable-ipv6 –prefix=/usr

--enable-ipv6              will enable sniffing IPv6 packets

When DAQ (Data Aquisition) module is successfully configured we get below output
DAQ Output after ./configure –enable-ipv6 --prefix=/etc

Build AFPacket DAQ module.. : yes
Build Dump DAQ module........ : yes
Build IPFW DAQ module......... : yes
Build IPQ DAQ module............ : no
Build NFQ DAQ module........... : yes
Build PCAP DAQ module......... : yes

IPQ is obsoleted so didn't install it


Snort Configuration Command
./configure --libdir=/usr/lib --includedir=/usr/include --enable-ipv6 --enable-gre --enable-targetbased –enable-ipfw –enable-dynamicplugin --enable-decoder-preprocessor-rules --enable-active-response --enable-normalizer --enable-reload --enable-react --enable-zlib

Fore developing preprocessor plugins you can add
--enable-debug
--enable-debug-msgs

Aditionally you might need dpx-1.4.tar.gz.

Errors seen while starting Snort:
For snort_dynamicrules not found error, create /usr/local/lib/snort_dynamicrules and copy .so files there,
For white_listing.rules, black_listing.rules files missing errors create those files and comment out reputation preprocessor from snort.conf.

#/home/praveen/snort-2.9.2.2#snort -V
,,_ -*> Snort! <*-
o" )~ Version 2.9.2.2 IPv6 GRE (Build 121)
'''' By Martin Roesch & The Snort Team: http://www.snort.org/snort/snort-team
Copyright (C) 1998-2012 Sourcefire, Inc., et al.
Using libpcap version 1.2.1
Using PCRE version: 8.30 2012-02-04
Using ZLIB version: 1.2.3
#/home/praveen/snort-2.9.2.2#

Starting snort with -Q option will make it run as IPS.


You can refer similar article from
http://techminded.net/blog/using-snort-as-service-ips.html

For Snort Preprocessors you can refer below link
http://darshanams.blogspot.in/2010/06/snort-preprocessors-and-alerts.html

For sending Snort alerts to Syslog server
http://darshanams.blogspot.in/2011/05/snort-logging-alerts-to-syslog-server.html

For detailed description of various concepts refer SnortTM Users Manual.
http://www.snort.org/assets/140/snort_manual_2_8_6.pdf

Snort: Logging Alerts to Syslog Server

Life is so busy. It's been pretty long since my last post. Well coming to the post :) ...

We will get into configuration details of Syslog and Snort to log our alerts into Kiwi Syslog Server.

Add the following line to Snort configuration file
 output alert_syslog: host=172.16.232.161:514, LOG_AUTH LOG_ALERT
Snort configuration file can be found at
                 /etc/snort/snort.conf

In my case Snort is running on 3.3.3.9 on eth1 and eth0 is assigned with 172.16.232.171 IP which talks with Syslog Server.

Following command is used to run Snort
 snort -c /etc/snort/snort.conf -i eth1
-c    provide snort configuration file path
-i     interface on which Snort is sniffing the traffic

Output shown in above figure is seen when the Snort command is successful.

Modify syslog configuration file
                 /etc/rsyslog.conf
by adding line
*.*                                                     @172.16.232.161:514

where 172.16.232.161 is the Syslog Server IP Address and UDP/514 is the port on which it is listening.

*.* says log all types of alerts.

To make sure that Syslog Server is running on UDP/514 port uncomment below lines in the configuration file

$ModLoad imudp.so

$UDPServerRun 514

Above lines are commented by default.

Once the modified configuration is saved restart the Syslog daemon

 /etc/rc.d/init.d/rsyslog restart

Make sure to stop firewall or add rule to allow traffic on UDP/514 port.

When we send malicious payload or replay PCAP with malicious traffic on the interface where snort is running, we can see alerts in our Kiwi Syslog Server which is installed on Windows XP machine (172.16.232.161).

Below is the Packet Capture format when Snort sends alerts to Syslog Server.

Refer Snort Manual and/or Snort FAQ for further details.

For Snort Preprocessors you can refer below link
http://darshanams.blogspot.in/2010/06/snort-preprocessors-and-alerts.html

Hope this will help someone somewhere.

Following articles might be of your interest
http://darshanams.blogspot.in/2012/05/cain-and-abel-password-cracking.html
http://darshanams.blogspot.in/2011/09/portable-document-files.html
http://darshanams.blogspot.in/2010/09/forensics-1-extracting-image.html

Enjoy :) !!!

Snort Preprocessors and Alerts

Snort Preprocessors

Preprocessors were introduced in Snort v1.5. Preprocessor code is run before the detection engine is called, but after the packet has been decoded. The packet can be modified or analyzed in an out-of-band manner using this mechanism. Preprocessors help in identifying possible attack packets before rules are applied, after the preprocessing stage various rules are applied on the packets (raw data) for detecting attacks based on the pattern matches. Preprocessors need to be configured from snort.conf file which can be found at /etc/ or /etc/snort/. frag2 should be commented if frag3 is used and stream4 is commented if stream5 is used.

preprocessor frag2

preprocessor frag3 // IP packet reassembly or defragmentation

preprocessor stream4: detect_scans

preprocessor stream4_reassemble

preprocessor stream5 // TCP Segmentation reassembly, stateful protocol analysis

preprocessor http_decode // http normalization of url-encoded data

preprocessor rpc_decode

preprocessor bo // back orifice backdoor traffic detection

preprocessor telnet_decode

preprocessor sf_portscan // detects various portscans

preprocessor sf_ssh

preprocessor sf_smtp

preprocessor sf_ftptelnet

preprocessor sf_dns

preprocessor sf_dcerpc

preprocessor sf_ssl

Snort also has Postprocessors or output plug-ins. These are the snort processors/plug-ins that determine what to do after traffic is identified as malicious based on pre-processors or rules. Popular post-processors are those that send snort alerts and log data to databases; those which allow SNMP event messaging etc.

Snort Alerts

Snort alerts logged onto a logfile look like (there may be different alerts in your environment)

[**] [1:2050:14] SQL version overflow attempt [**]

[**] [1:8428:9] WEB-MISC SSLv2 openssl get shared ciphers overflow attempt [**]

[**] [122:3:0] (portscan) TCP Portsweep [**]

[**] [119:4:1] (http_inspect) BARE BYTE UNICODE ENCODING [**]

The first number (1, 122, 119 here) is the Generator ID, this tells the user what component of Snort generated this alert. List of GIDs can be found at etc/generators in the Snort source.

Generators file has the format shown below

generatorid || alertid || MSG

Below diagram shows the generator id, alert id or snort id and alert name.

<!--[if !vml]-->

<!--[if !vml]--><!--[endif]-->

Any alert under ARP Spoofing and spp_fnord will have a Generator ID's of 112 and 114 respectively.

<!--[endif]-->

The second number (2050, 8428, 3, 4 here) is the Snort ID (or Signature ID). For a list of preprocessor SIDs, please see etc/gen-msg.map. Rule-based SIDs are written directly into the rules with the “sid” option.

The third number (14, 9, 0, 1 from above alerts) is the revision ID. This number is primarily used when writing signatures, as each re-edition or fine tuning of the rule should increment this number with the “rev” option. e.g. " SQL version overflow attempt" signature is modified 14 times !!!

For sending Snort alerts to Syslog server
http://darshanams.blogspot.in/2011/05/snort-logging-alerts-to-syslog-server.html

For detailed description of various concepts refer Snort^TM Users Manual.

http://www.snort.org/assets/140/snort_manual_2_8_6.pdf