[Oisf-devel] http application layer traffic identification question
Anoop Saldanha
poonaatsoc at gmail.com
Sat Oct 22 08:31:45 UTC 2011
On Sat, Oct 22, 2011 at 1:58 AM, rmkml <rmkml at yahoo.fr> wrote:
> 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 our currrent master, I get the alert with the original unmodified
rule(alert http itself) rule(as long as my home_net matches the ip).
So no issues with master.
On v105, it seems that on some runs I get the alert and a couple of
other run I don't see it. So looks like a v105 specific thing. Will
need to inspect it more.
> 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
>
--
Anoop Saldanha
More information about the Oisf-devel
mailing list