[Snort-sigs] RE: Trying to capture web traffic

Jason security at ...704...
Tue Feb 17 11:44:10 EST 2004


It sounds to me like you need to use a new ruletype and then config
order to make sure you banner grabber logtype is evaluated before your
general log type. Or use 2 snorts.

ruletype bannerlog {
     type log
     output log_tcpdump: response_banners.log
}

config order: pass alert bannerlog log activation dynamic

log ip any any <> 10.1.1.50 any
bannerlog tcp rooted_host 80 -> any any (content: "HTTP/1.1"; nocase; 
flags:PA; msg: "blah, blah";

bannerlog tcp any any -> 10.1.1.50 80 (flags: PA;)
bannerlog tcp any any -> 10.1.1.50 80 (flags: SP;)
# This should capture any data sent, odd but allowed per rfc
bannerlog tcp any any -> 10.1.1.50 80 (flags: S; dsize: >1;)
bannerlog tcp any any -> 10.1.1.50 90 (flags: A: dsize: >1;)


I might consider revising the rules above by adding flow and possibly an 
HTTP/ content match since all valid HTTP GET/HEAD/POST/OPTIONS... should 
have some form of HTTP/* version at the end to be serviced, of course 
"should" is often at the heard of the issue. YMMV

bannerlog tcp any any -> 10.1.1.50 80 
(flow:established,to_server;content:"HTTP/";flags: PA;)
bannerlog tcp any any -> 10.1.1.50 80 
(flow:established,to_server;content:"HTTP/";flags: SP;)
# This should capture any data sent, odd but allowed per rfc
bannerlog tcp any any -> 10.1.1.50 80 (flow:stateless;flags:S;dsize:>1;)
bannerlog tcp any any -> 10.1.1.50 90 
(flow:established,to_server;flags:A:dsize:>1;)




whipsmack wrote:

> Well, I'd like to just add a log rule like the one you mentioned, but
> it's in the wrong direction:
> 
> # This rule would catch all inbound HTTP status codes, I already log
> ALL data sent to the server to port 80
> 
> log tcp any any -> rooted_host 80 (content: "HTTP/1.1"; nocase;
> flags:PA; msg: "blah, blah"; etc.)
> 
> 
> #The rule should be: log tcp rooted_host 80 -> any any (content:
> "HTTP/1.1"; nocase; flags:PA; msg: "blah, blah"; etc.)
> 
> However, this will not work though either, since I HAVE to have a
> catch-all log statement at the end since we just don't know what the
> trigger for the backdoor shell is, I only suspect it's over web:
> 
> log tcp any any <> 10.1.1.50 any log udp any any <> 10.1.1.50 any log
> icmp any any <> 10.1.1.50 any
> 
> So, because of my catch-all's I end up logging everything.  What I
> want first is to log all data sent to the server to port 80 (which
> I've already got that down)
> 
> # This should capture almost all GETs, POSTs and HEADs, etc log tcp
> any any -> 10.1.1.50 80 (flags: PA;) log tcp any any -> 10.1.1.50 80
> (flags: SP;) # This should capture any data sent, odd but allowed per
> RFC log tcp any any -> 10.1.1.50 80 (flags: S; dsize: >1;) log tcp
> any any -> 10.1.1.50 90 (flags: A: dsize: >1;)
> 
> 
> Second, I want to log *only* the PA's from the server with HTTP
> status codes, nothing else... no other PA's with just continuation
> packets, not other flags like RESET, or FINs, or FA, or FAP, or etc,
> etc, etc.....I have everything working except the dang PA thing.  I
> just want some way to log PA from the server with HTTP status codes
> but somehow pass all other PA's from the server.
> 
> Thanks
> 
> Paul Schmehl <pauls at ...1311...> wrote: --On Tuesday, February 17,
> 2004 9:28 AM -0800 whipsmack wrote:
> 
>> Um... no..... I'm not the snort expert by any means..... So, with
>> the -o option, do the rules then have to be in any particular order
>> (i.e. do the pass rules have to be above the logs rules, or
>> vise-versa?)
> 
> 
> No. Physical order of the rules is unimportant. When you start snort
> with the -o switch, it will parse all pass rules before it parses any
> of the other rules. To test this, write a temp rule that passes all
> traffic originating at or destined to the box in question. That
> should shut off *all* the alerts to and from that box.
> 
> 
>> I added the -o but I'm still getting all the PUSH/ACKs...just don't
>> get it, it should be passing all PA without content HTTP/1.1...
>> grrrrrr....
> 
> 
> If all you want to see is traffic on port 80, then use a rule that
> passes everything that is *not* to 80. For example: pass tcp any any
> -> rooted_host !80 (msg: "blah, blah, blah, etc.)
> 
> This should eliminate all traffic that isn't destined to port 80.
> 
> But you say all you want to capture is PAs to port 80 with HTTP/1.1
> in the content, right?
> 
> So run snort with one rule. You don't even need a pass rule. Just
> start a new instance of snort with the following rule:
> 
> log tcp any any -> rooted_host 80 (content: "HTTP/1.1"; nocase;
> flags:PA; msg: "blah, blah"; etc.)
> 
> I think you're approaching the problem in the wrong direction.
> Instead of trying to write rules that ignore everything but what you
> want to see, write one rule that only looks for what you want to look
> for and nothing else. Turn off all the preprocessors by commenting
> them out in the snort.conf file.
> 
> 
>>> -----Original Message----- From: JMMel
>>> [mailto:jmelvin1 at ...480...] Sent: Monday, February 16, 2004
>>> 12:00 PM To: 'snort-sigs at lists.sourceforge.net' Subject: Trying
>>> to capture web traffic
>>> 
>>> All,
>>> 
>>> Brief synopsis: A rootkit is installed that initiates a reverse
>>> shell back to attacker when triggered by a crafted packet aimed
>>> at any port the victim has open. The reverse shell is TCP with a
>>> full handshake (although it' s encrypted) so, I know the IP that
>>> is triggering the reverse shell. However, the IP changes daily
>>> (either dynamically, or RAS, or multiple owned systems, etc) so I
>>> can't set rules up to log by IP. Also, the victim is a public web
>>> server and they don't log every connection. When looking at the
>>> logs I have from FW's and victim I can't see what the trigger
>>> packet is that wakes up the reverse shell. The big issue is their
>>> IDS and FW only log web traffic that fits a particular signature
>>> string, otherwise port 80 inbound is dropped cause there is just
>>> so much of it.
>>> 
>>> Problem: I figure the trigger packet is coming inbound to port 80
>>> and hiding among tons of legit traffic, probably an HTTP
>>> continuation packet to try and spoof proxies and such.... it
>>> could be a GET or POST or HEAD or anything like that too, just
>>> don't know since the logs are not capturing this. Right now, I j
>>> ust don't see the precursor for when the victim imitates the
>>> reverse shell....
>>> 
>>> So...I want to be able to log all data sent to the server to port
>>> 80, try to capture some server replies, but pass everything else
>>> on port 80. For this purpose 10.1.1.50 will be the server
>>> (victim):
>>> 
>>> # This should capture almost all GETs, POSTs and HEADs, etc I
>>> would think log tcp any any -> 10.1.1.50 80 (flags: PA;) log tcp
>>> any any -> 10.1.1.50 80 (flags: SP;) # This should capture any
>>> data sent, odd but allowed per RFC log tcp any any -> 10.1.1.50
>>> 80 (flags: S; dsize: >1;) log tcp any any -> 10.1.1.50 90 (flags:
>>> A: dsize: >1;) # .... My BIG issue is this: How can I log some
>>> server replies but pass everything else. For instance, if I want
>>> to capture PUSH/ACKs with HTTP status code, BUT pass all other
>>> PA's how can I do it????
>>> 
>>> # This doesn' t seem to work, I would think ANY PUSH/ACK without
>>> the # content of HTTP/1.1 within the first 20 bytes of data would
>>> be passed. pass tcp 10.1.1.50 80 -> any any (flags: AP; content:
>>> !"HTTP/1.1 "; depth: 20;) # The below rules I added to discard
>>> all other replies: pass tcp 10.1.1.50 80 -> any any (flags: A;) 
>>> pass tcp 10.1.1.50 80 -> any any (flags: RA;) pass tcp 10.1.1.50
>>> 80 -> any any (flags: FA;) ....etc.... all other flag combos.....
>>>  # # the final rules are to capture everything log tcp any any <>
>>> 10.1.1.50 any log udp any any <> 10.1.1.50 any log icmp any any
>>> <> 10.1.1.50 any
>>> 
>>> So, the problem is I not only capture all the server HTTP status
>>> code replies but all PUSH/ACKs from the server. I tried making
>>> the pass tcp 10.1.1.50 80 -> any any (flags: AP; content:
>>> !"HTTP/1.1 "; depth: 20;) into a log stateme nt instead and
>>> getting rid of the "!" identifier, then adding a pass statement: 
>>> pass tcp 10.1.1.50 80 > any any (flags: AP;) below it, but then I
>>> don't get any packets with a PUSH/ACK.
>>> 
>>> Does this have something to do with the order of the rules. I'm
>>> assuming if you put a pass statement in that would override a log
>>> statement above that the pass statement would apply? If so, why
>>> doesn't my pass statement saying all PUSH/ACKs without content
>>> HTTP/1.1 work, why am I still seeing ALL PUSH/ACKs? This is
>>> beyond me, can't figure it out.... help
>>> 
> 
> 
> Paul Schmehl (pauls at ...1311...) Adjunct Information Security
> Officer The University of Texas at Dallas AVIEN Founding Member 
> http://www.utdallas.edu
> 
> 
> ------------------------------------------------------- SF.Net is
> sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps
> & Web services for Linux with a free DVD software kit from IBM. Click
> Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click 
> _______________________________________________ Snort-sigs mailing
> list Snort-sigs at lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> 
> 
> --------------------------------- Do you Yahoo!? Yahoo! Finance: Get
> your refund fast by filing online





More information about the Snort-sigs mailing list