[Oisf-devel] http application layer traffic identification question

rmkml rmkml at yahoo.fr
Fri Oct 21 20:28:13 UTC 2011


Hi David and Anoop,
I have same pb and I search why...
Simply record network trafic and go to google for example (wget without compression)...
I have removed threshold option: same pb.
changed to "alert tcp..." and suricata fire.
Im use suricata v105.
Regards
Rmkml


On Sat, 22 Oct 2011, Anoop Saldanha wrote:

> On Sat, Oct 22, 2011 at 12:06 AM,  <David.R.Wharton at regions.com> wrote:
>> I have a question about application layer traffic identification and rule
>> matches based on it, specifically http.  I have this rule from
>> emerging-policy.rules:
>>
>> alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET POLICY Incoming Basic
>> Auth Base64 HTTP Password detected unencrypted"; flow:established,to_server;
>> content:"|0d 0a|Authorization|3a 20|Basic"; nocase;
>> content:!"YW5vbnltb3VzOg=="; within:32; threshold: type both, count 1,
>> seconds 300, track by_src;
>> reference:url,doc.emergingthreats.net/bin/view/Main/2006402;
>> classtype:policy-violation; sid:2006402; rev:10;)
>>
>> And I have this traffic:
>>
>> 13:42:09.149477 IP e.x.t.n.51978 > h.o.m.e.80: S 3741764774:3741764774(0)
>> win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
>> E .4.3 at .1..Xb..9...^M.
>> .P.......... .................
>> 13:42:09.149796 IP h.o.m.e.80 > e.x.t.n.51978: S 2299323222:2299323222(0)
>> ack 3741764775 win 32768 <mss 1460>
>> E .,...........^Mb..9.P.
>> ...V....`.............
>> 13:42:09.211776 IP e.x.t.n.51978 > h.o.m.e.80: . ack 1 win 17520
>> E .(.;@.1..\b..9...^M.
>> .P.......WP.DpL.........
>> 13:42:09.216761 IP e.x.t.n.51978 > h.o.m.e.80: P 1:196(195) ack 1 win 17520
>> E ...<@.1.
>> .b..9...^M.
>> .P.......WP.Dp....GET / HTTP/1.1
>> Accept:
>> Cache-Control: no-cache
>> Authorization: Basic Og==
>> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101
>> Firefox/7.0.1
>> Host: www.mydomain.com
>> Connection: Close
>> Pragma: no-cache
>>
>>
>> Yet the rule does not alert as it should.  The packet that should set off
>> the alert is the first one after the TCP three way handshake.  At this point
>> does the engine not have enough data to classify this stream as http and
>> thus the rule is not firing?  I sincerely hope that is not the case....
>>
>> I have double checked my variables and this should fire; the snort version
>> (alert tcp) does fire as expected in snort.
>>
>> Thank you.
>>
>> -David
>> _______________________________________________
>> Oisf-devel mailing list
>> Oisf-devel at openinfosecfoundation.org
>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
>>
>>
>
> Can you share the pcap for this?  You can send it privately if you want to.
>
> -- 
> Anoop Saldanha
> _______________________________________________
> Oisf-devel mailing list
> Oisf-devel at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
>


More information about the Oisf-devel mailing list