Bug #230
closed"uricontent" parameter in rules doesn't work
Added by Roberto Amado over 14 years ago. Updated almost 14 years ago.
Description
Hi,
first of all i want to say that you are doing a excellent job. I running suricata in inline mode with only 1 rule:
drop tcp any any -> any 80 (msg:"WEB-MISC /etc/passwd"; uricontent:"/etc/passwd"; sid:1122; rev:7;)
The problem is that when i try to connect to the protected webserver the packet is not blocket, the rule doesn't match. But instead of this i write
drop tcp any any -> any 80 (msg:"WEB-MISC /etc/passwd"; content:"/etc/passwd"; sid:1122; rev:7;)
the rule match the packet when i make a GET request. But this is a problem because drops all packet sent to the server (obviously raw) that match /etc/passwd not only in the URI.
So... Is there some way to drop packets that only matches paterns in the URI?
Thanks a lot.
Updated by Roberto Amado over 14 years ago
PD: I tried this configuration with snort inline and it works :S
Updated by Victor Julien over 14 years ago
Are you seeing an alert in /var/log/suricata/fast.log?
Does the signature match if you change drop to alert?
Updated by Roberto Amado over 14 years ago
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
Updated by Victor Julien over 14 years ago
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?
Updated by Gurvinder Singh over 14 years ago
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.
Updated by Roberto Amado over 14 years ago
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?
Updated by Victor Julien over 14 years ago
Can you show the iptables rules you are using?
Does it detect properly if the engine runs in passive/ids mode?
Updated by Roberto Amado over 14 years ago
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
Updated by Roberto Amado over 14 years ago
One thing more, that i said before. In ips mode when i switch to content instead uricontent the packet is droped. :S
Updated by Victor Julien over 14 years ago
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.
Updated by Roberto Amado over 14 years ago
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
Updated by Roberto Amado over 14 years ago
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.
Updated by Roberto Amado over 14 years ago
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
Updated by Roberto Amado over 14 years ago
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?
Updated by Victor Julien over 14 years ago
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.
Updated by Roberto Amado over 14 years ago
Same configuration snort_inline works fine filtering using uricontent.
Updated by Bartosz Ponury about 14 years ago
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?
Updated by Victor Julien almost 14 years ago
- Status changed from New to Assigned
- Assignee set to Victor Julien
- Target version set to 1.1beta2
I'm working on this currently. Should have code up for testing shortly.
Updated by Victor Julien almost 14 years ago
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.
Updated by Victor Julien almost 14 years ago
- Status changed from Assigned to Closed