[Oisf-devel] http application layer traffic identification question

[Peter Manev]

On Sat, Oct 22, 2011 at 10:31 AM, Anoop Saldanha <poonaatsoc at gmail.com>wrote:

> 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
> _______________________________________________
> Oisf-devel mailing list
> Oisf-devel at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
>
Hi ,

When I simply read a pcap crafted for that rule - it does fire with git
master. Same results as Anoops basically.
However a private pcap with suri yaml (mask out the nets if you have to )
would be more helpful I believe.

Thanks


-- 
Peter Manev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-devel/attachments/20111022/03d4d32f/attachment-0002.html>