Suricata

PD: I tried this configuration with snort inline and it works :S

Are you seeing an alert in /var/log/suricata/fast.log?

Does the signature match if you change drop to alert?

Doesn't match if i change to alert :_(

also the logs are all 0

0 rw-r--r- 1 root root 0 ago 27 14:39 http.log
0 rw-r--r- 1 root root 0 ago 27 14:39 fast.log
0 rw-r--r- 1 root root 0 ago 27 14:39 alert-debug.log

This is the rule :

alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC /etc/passwd"; flow:to_server,established; uricontent:"/etc/passwd"; nocase; metadata:service http; classtype:attempted-recon; sid:1122; rev:6;)

OR

drop tcp any any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC /etc/passwd"; flow:to_server,established; uricontent:"/etc/passwd"; nocase; metadata:service http; classtype:attempted-recon; sid:1122; rev:6;)

could you try it only with 1 rule, this rule and configure options -> ./configure --enable-debug --enable-nfqueue

This seems to be some problem with http detection because http.log is empty

Couple of things to check:

1. when suricata exits, does it report seeing packets? Example:
[25413] 27/8/2010 -- 14:52:39 - (source-nfq.c:525) <Info> (ReceiveNFQThreadExitStats) -- (ReceiveNFQ) Pkts 100, Bytes 100000, Errors 0

2. What is the ip address of the server you are testing against and what is your $HTTP_SERVERS set to?

just to add one more thing to check. Does the server ACK the sent packet where uricontent is "/etc/passwd". As if the server does not ACK the sent packet, it will not be reassembled and sent to app layer processing. If this is the case, then it make sense to have no entry in the http.log file.

Hi, thx both for answer so soon. here are the things you are comment:

Victor:

1.- The output of suricata when exits:

[28167] 30/8/2010 -- 10:14:10 - (suricata.c:1138) <Info> (main) -- time elapsed 187s
[28168] 30/8/2010 -- 10:14:11 - (source-nfq.c:525) <Info> (ReceiveNFQThreadExitStats) -- (ReceiveNFQ) Pkts 685, Bytes 87226, Errors 0
[28170] 30/8/2010 -- 10:14:11 - (stream-tcp.c:2679) <Info> (StreamTcpExitPrintStats) -- (Stream1) Packets 379
[28174] 30/8/2010 -- 10:14:11 - (source-nfq.c:536) <Info> (VerdictNFQThreadExitStats) -- (Verdict) Pkts accepted 685, dropped 0
[28176] 30/8/2010 -- 10:14:11 - (alert-fastlog.c:301) <Info> (AlertFastLogExitPrintStats) -- (Outputs) Alerts 0
[28176] 30/8/2010 -- 10:14:11 - (alert-unified2-alert.c:603) <Info> (Unified2AlertThreadDeinit) -- Alert unified2 module wrote 0 alerts
[28176] 30/8/2010 -- 10:14:11 - (log-httplog.c:396) <Info> (LogHttpLogExitPrintStats) -- (Outputs) HTTP requests 0
[28177] 30/8/2010 -- 10:14:11 - (flow.c:1107) <Info> (FlowManagerThread) -- 36 new flows, 0 established flows were timed out, 0 flows in closed state
[28167] 30/8/2010 -- 10:14:11 - (stream-tcp.c:448) <Info> (StreamTcpFreeConfig) -- Max memuse of stream engine 16797568 (in use 0)

as you can see suricata process this packets.

2.- My $HTTP_SERVERS is set to "172.17.0.18" but it dosen't matter because i tested with "any any" also.

Gurvinder Singh

Here is the output of tcpdump, the client is 192.168.1.26 and the server is 172.17.0.18, the servers is running suricata.

#tcpdump -A -n -i eth1 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
10:11:09.586338 IP 192.168.1.26.4437 > 172.17.0.18.80: S 3399806122:3399806122(0) win 64240 <mss 1260,nop,nop,sackOK>
E..0g.@...&..........U.P........p...R...........

10:11:09.586463 IP 172.17.0.18.80 > 192.168.1.26.4437: S 3309094397:3309094397(0) ack 3399806123 win 5840 <mss 1460,nop,nop,sackOK>
E..0...............P.U.<......p....)..........

10:11:09.588319 IP 192.168.1.26.4437 > 172.17.0.18.80: . ack 1 win 64240
E..(g.@...&..........U.P.....<..P.............

10:11:09.589079 IP 192.168.1.26.4437 > 172.17.0.18.80: P 1:478(477) ack 1 win 64240
E...g.@...$..........U.P.....<..P....!..GET /test/etc/passwd HTTP/1.1
Host: 172.1

10:11:09.589164 IP 172.17.0.18.80 > 192.168.1.26.4437: . ack 478 win 6432
E..(2B@.@............P.U.<......P.. ....

10:11:09.600729 IP 172.17.0.18.80 > 192.168.1.26.4437: P 1:583(582) ack 478 win 6432
E..n2C@.@..a.........P.U.<......P.. pF..HTTP/1.1 404 Not Found
Date: Mon, 30 Aug

10:11:09.798094 IP 192.168.1.26.4437 > 172.17.0.18.80: . ack 583 win 63658
E..(g'@...&..........U.P.....<.DP.............

10:11:14.505865 IP 192.168.1.26.4437 > 172.17.0.18.80: P 478:955(477) ack 583 win 63658
E...g.@...$1.........U.P.....<.DP....D..GET /test/etc/passwd HTTP/1.1
Host: 172.1

10:11:14.506321 IP 172.17.0.18.80 > 192.168.1.26.4437: P 583:1164(581) ack 955 win 7504
E..m2D@.@..a.........P.U.<.D...eP..PpE..HTTP/1.1 404 Not Found
Date: Mon, 30 Aug

10:11:14.721522 IP 192.168.1.26.4437 > 172.17.0.18.80: . ack 1164 win 63077
E..(g.@...&..........U.P...e.<..P..e..........

Some idea what's going on?

Can you show the iptables rules you are using?

Does it detect properly if the engine runs in passive/ids mode?

1.- iptables -A INPUT -j NFQUEUE --queue-num 0

2.-When i turn off IPS mode the rule works

Using alert instead drop and disabling nfqeue (suricata -c /etc/suricata/suricata.yaml -i eth1)

#/var/log/suricata# tail -f fast.log

08/30/10-08:44:44.241023 [**] [1:1122:6] WEB-MISC /etc/passwd [**] [Classification: Attempted Information Leak] [Priority: 3] {6} 192.168.1.26:4453 -> 172.17.0.18:80
08/30/10-08:44:47.729653 [**] [1:1122:6] WEB-MISC /etc/passwd [**] [Classification: Attempted Information Leak] [Priority: 3] {6} 192.168.1.26:4453 -> 172.17.0.18:80

One thing more, that i said before. In ips mode when i switch to content instead uricontent the packet is droped. :S

Ahh you need "iptables -A OUTPUT -j NFQUEUE --queue-num 0" as well for Suricata to see the full tcp session. It needs that to properly parse the HTTP transaction.

Ok i tested two configurations:

1.- Only with "iptables -A OUTPUT -j NFQUEUE --queue-num 0"

iptables -L -v
Chain INPUT (policy ACCEPT 104K packets, 25M bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 38 packets, 3685 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 110K packets, 19M bytes)
pkts bytes target prot opt in out source destination
4 809 NFQUEUE all -- any any anywhere anywhere NFQUEUE num 0

not working :(

2.- Both input and output chains

iptables -A INPUT -j NFQUEUE --queue-num 0
iptables -A OUTPUT -j NFQUEUE --queue-num 0

iptables -L -v

Chain INPUT (policy ACCEPT 104K packets, 25M bytes)
pkts bytes target prot opt in out source destination
2321 564K NFQUEUE all -- any any anywhere anywhere NFQUEUE num 0

Chain FORWARD (policy ACCEPT 38 packets, 3685 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 110K packets, 19M bytes)
pkts bytes target prot opt in out source destination
2079 276K NFQUEUE all -- any any anywhere anywhere NFQUEUE num 0

The http processor detects traffic but still not block the packets:

tail -f http.log
08/30/10-09:59:08.669732 172.17.0.18 [**] /123123123123/etc/passwd [**] Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.2.8) Gecko/20100723 Ubuntu/10.04 (lucid) Firefox/3.6.8 [**] 172.17.0.53:80 -> 172.17.0.18:39895

tail -f fast.log
08/30/10-09:58:53.665682 [**] [1:1122:6] WEB-MISC /etc/passwd [**] [Classification: Attempted Information Leak] [Priority: 3] {6} 172.17.0.53:39895 -> 172.17.0.18:80

In other deployment i have, with the suricata runnig in other host in front of the server with 2 interfaces in bridge mode, obviously i use FORWARD chain instead INPUT and OUTPUT, and the result is the same.

Some info from alert_debug.log for the rule ""drop tcp any any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC /etc/passwd 2"; uricontent:"/etc/passwd"; sid:1125; rev:7;)

ALERT CNT: 1
ALERT MSG [00]: WEB-MISC /etc/passwd 2
ALERT GID [00]: 1
ALERT SID [00]: 1125
ALERT REV [00]: 7
ALERT CLASS [00]: (null)
ALERT PRIO [00]: 3
SRC IP: 172.17.0.53
DST IP: 172.17.0.18
PROTO: 6
SRC PORT: 39910
DST PORT: 80
TCP SEQ: 1338574977
TCP ACK: 799627948
FLOW: to_server: TRUE, to_client: FALSE
FLOW Start TS: 01/04/00-20:55:55.402721
FLOW PKTS TODST: 4
FLOW PKTS TOSRC: 3
FLOW Total Bytes: 1456
FLOW IPONLY SET: TOSERVER: TRUE, TOCLIENT: TRUE
FLOW ACTION: DROP: FALSE, PASS FALSE
FLOW NOINSPECTION: PACKET: FALSE, PAYLOAD: FALSE, APP_LAYER: FALSE
FLOW APP_LAYER: DETECTED: TRUE, PROTO 1
PACKET LEN: 52
PACKET:
0000 45 00 00 34 CA B3 40 00 40 06 17 A7 AC 11 00 35 E..4... ......5
0010 AC 11 00 12 9B E6 00 50 4F C9 08 81 2F A9 5A AC .......P O.../.Z.
0020 80 10 00 6E 92 05 00 00 01 01 08 0A 00 2D CC 30 ...n.... .....-.0
0030 09 32 37 7A .27z

I was wondering about you tell me before Gurvinder...

"just to add one more thing to check. Does the server ACK the sent packet where uricontent is "/etc/passwd". As if the server does not ACK the sent packet, it will not be reassembled and sent to app layer processing. If this is the case, then it make sense to have no entry in the http.log file."

That means that the http processor needs the ack from the server? that means that the servers would process the attack?

The stream engine reassembled only ack'd data. We experimented with reassembling unack'd data in Snort_inline but that creates a whole range of new problems. As our http module (and all "app layer" modules) work on top of the stream engine it will operate on ack'd data.

Same configuration snort_inline works fine filtering using uricontent.

Victor Julien wrote:

The stream engine reassembled only ack'd data. We experimented with reassembling unack'd data in Snort_inline but that creates a whole range of new problems. As our http module (and all "app layer" modules) work on top of the stream engine it will operate on ack'd data.

Hi, if I understand this correctly Suricata is not an IPS right now? Since all malicious packets are delivered to protected server. I think this is crucial for suricata to be able to drop incoming attacks. Let's assume that a new DoS attack is discovered and sending 'GET /KILL_APACHE HTTP/31.337\r\n\r\n' to Apache server would destroy the world. Suricata will not prevent this right? It will just let me know that the world no longer exists... Well what's the benefit of using it inline with NFQUEUE anyway? Is it going to be implemented soon?

OK Thanks a lot for your work.

I just pushed a large stream engine update that addresses this issue. It's in the current git master. To use it, enable the stream.inline mode. To see how, open up the example suricata.yaml after updating your git tree.