[prev in list] [next in list] [prev in thread] [next in thread]
List: oisf-users
Subject: Re: [Oisf-users] Issue with having Suricata alert successfully on successive creation of alert condi
From: bakul khanna <bakulkhanna () gmail ! com>
Date: 2014-09-17 20:49:46
Message-ID: CA+fzBArJ5vYW_mJH6iA5chDHNPHg+QQLiE_06OEgyhru-OcSbQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thanks for your suggestions.
The problem I was seeing with "successive alerts on tcpreplay of a pcap
file" turned out to be a networking issue that caused all packets in the
pcap file to not be delivered to the Suricata machine on successive
tcpreplays, although on the first tcpreplay all packets in the pcap file
were delivered successfully. Waiting 300s (5 min) after the first tcpreplay
cleared this networking condition and allowed all packets in the pcap file
to be delivered successfully again.
I confirmed this by replaying the pcap files from the same machine that
Suricata was running on and observed successive alerts (earlier when I had
tried this test and reported that it didn't work, I believe I had not yet
lowered the tcp-timeouts).
Thanks,
-Bakul
On Mon, Sep 15, 2014 at 1:01 PM, Peter Manev <petermanev@gmail.com> wrote:
> On Mon, Sep 15, 2014 at 6:20 PM, bakul khanna <bakulkhanna@gmail.com>
> wrote:
> > I tried both (feeding the pcap file from a different machine as well as
> > feeding it from the same machine running Suricata).
> >
> > Some more answers/observations:
> > 1. I am not using unix-socket
> > 2. Regardless of the tcp timeout configurations, I cannot get the
> > sid=2016808 to occur closer than 5 min in time.
> >
>
> Two suggestions to consider:
> 1 - is all NIC offloading disabled? (when you try it on the same machine)
> 2 - decrease the "chunk size" config parameter in suricata.yaml.
>
> thanks
>
> > Thanks.
> >
> > On Mon, Sep 15, 2014 at 9:41 AM, Peter Manev <petermanev@gmail.com>
> wrote:
> >>
> >> On Sun, Sep 14, 2014 at 5:22 PM, bakul khanna <bakulkhanna@gmail.com>
> >> wrote:
> >> > Thanks Peter.
> >> >
> >> > Here are the timeouts from my suricata.yaml file:
> >> >
> >> > default:
> >> > new: 30
> >> > established: 300
> >> > closed: 0
> >> > emergency-new: 10
> >> > emergency-established: 100
> >> > emergency-closed: 0
> >> > tcp:
> >> > new: 10
> >> > established: 10
> >> > closed: 10
> >> > emergency-new: 10
> >> > emergency-established: 10
> >> > emergency-closed: 10
> >> >
> >> > I invoke suricata using the following command:
> >> > suricata -D -c /etc/suricata/suricata.yaml -i eth0 --pidfile
> >> > /var/run/suricata.pid
> >> >
> >> > Following the successful alert for sid=2016808, I also immediately see
> >> > the
> >> > following alerts:
> >> > 2210032 - ..Suricata Stream FIN1 F1with wrong seq... (sometimes)
> >> > 2210045 - ..Suricata stream packet with invalid ack..
> >> > 2210046 - ..Suricata stream shutdown RST invalid ack...
> >> >
> >> > Also, I noticed that I don't have to wait an hour to generate
> successful
> >> > 2016808 alerts, I can now generate successive alerts if I wait to
> 10-15
> >> > min.
> >> >
> >> > Thanks,
> >> >
> >> > -Bakul
> >> >
> >> >
> >> >
> >>
> >> How do you feed the pcaps for reading - tcpreplay?
> >> Is it from another machine or from the same one that has Suricata
> running?
> >>
> >> thanks
> >>
> >> >
> >> >
> >> >
> >> > On Sun, Sep 14, 2014 at 5:37 AM, Peter Manev <petermanev@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Sun, Sep 14, 2014 at 2:35 AM, bakul khanna <bakulkhanna@gmail.com
> >
> >> >> wrote:
> >> >> > I am experimenting with having Suricata generate an alert, for an
> ET
> >> >> > rule
> >> >> > (sid=2016808), when I perform a tcpreplay of a pcap file for this
> >> >> > rule.
> >> >> >
> >> >> > The first time after a Suricata bringup, it does generate the
> alert.
> >> >> > On
> >> >> > subsequent replays of the same pcap file it does not generate the
> >> >> > alert.
> >> >> > However if I wait a long time (I tried an hour) and then replay the
> >> >> > pcap
> >> >> > file, Suricata successfully alerts then. There is no threshold
> limits
> >> >> > applied to this rule.
> >> >> >
> >> >> > I tried reducing the flow and TCP timeouts in suricata.yaml, but
> that
> >> >> > didn't
> >> >> > seem to help.
> >> >> >
> >> >> > Any suggestion on how I can get Suricata to alert successfully on
> >> >> > successive
> >> >> > tcpreplays of this pcap file?
> >> >> >
> >> >> > Thanks,
> >> >> >
> >> >> > -Bakul
> >> >> >
> >> >> > _______________________________________________
> >> >>
> >> >>
> >> >>
> >> >> Hi,
> >> >>
> >> >> The way you describe the problem it seems TCP timeouts is the
> problem.
> >> >> I can't be sure though.
> >> >>
> >> >> Can you please provide your timeout values as set up in yaml and the
> >> >> set up you use - how do you start Suricata, do you use unix
> >> >> socket(most likely the case)...so on?
> >> >>
> >> >>
> >> >>
> >> >> thanks
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Regards,
> >> >> Peter Manev
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Peter Manev
> >
> >
>
>
>
> --
> Regards,
> Peter Manev
>
[Attachment #5 (text/html)]
<div dir="ltr">Thanks for your suggestions.<div><br></div><div>The problem I was \
seeing with "successive alerts on tcpreplay of a pcap file" turned out to \
be a networking issue that caused all packets in the pcap file to not be delivered to \
the Suricata machine on successive tcpreplays, although on the first tcpreplay all \
packets in the pcap file were delivered successfully. Waiting 300s (5 min) after the \
first tcpreplay cleared this networking condition and allowed all packets in the pcap \
file to be delivered successfully again. </div><div><br></div><div>I confirmed this \
by replaying the pcap files from the same machine that Suricata was running on and \
observed successive alerts (earlier when I had tried this test and reported that it \
didn't work, I believe I had not yet lowered the tcp-timeouts). \
</div><div><br></div><div>Thanks,</div><div><br></div><div>-Bakul<br><div><br></div><div><br></div></div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 15, 2014 at 1:01 PM, \
Peter Manev <span dir="ltr"><<a href="mailto:petermanev@gmail.com" \
target="_blank">petermanev@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">On Mon, Sep 15, 2014 at 6:20 PM, bakul khanna <<a \
href="mailto:bakulkhanna@gmail.com">bakulkhanna@gmail.com</a>> wrote:<br> > I \
tried both (feeding the pcap file from a different machine as well as<br> > \
feeding it from the same machine running Suricata).<br> ><br>
> Some more answers/observations:<br>
> 1. I am not using unix-socket<br>
> 2. Regardless of the tcp timeout configurations, I cannot get the<br>
> sid=2016808 to occur closer than 5 min in time.<br>
><br>
<br>
Two suggestions to consider:<br>
1 - is all NIC offloading disabled? (when you try it on the same machine)<br>
2 - decrease the "chunk size" config parameter in suricata.yaml.<br>
<br>
thanks<br>
<br>
> Thanks.<br>
><br>
> On Mon, Sep 15, 2014 at 9:41 AM, Peter Manev <<a \
href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>> wrote:<br> \
>><br> >> On Sun, Sep 14, 2014 at 5:22 PM, bakul khanna <<a \
href="mailto:bakulkhanna@gmail.com">bakulkhanna@gmail.com</a>><br> >> \
wrote:<br> >> > Thanks Peter.<br>
>> ><br>
>> > Here are the timeouts from my suricata.yaml file:<br>
>> ><br>
>> > default:<br>
>> > new: 30<br>
>> > established: 300<br>
>> > closed: 0<br>
>> > emergency-new: 10<br>
>> > emergency-established: 100<br>
>> > emergency-closed: 0<br>
>> > tcp:<br>
>> > new: 10<br>
>> > established: 10<br>
>> > closed: 10<br>
>> > emergency-new: 10<br>
>> > emergency-established: 10<br>
>> > emergency-closed: 10<br>
>> ><br>
>> > I invoke suricata using the following command:<br>
>> > suricata -D -c /etc/suricata/suricata.yaml -i eth0 --pidfile<br>
>> > /var/run/suricata.pid<br>
>> ><br>
>> > Following the successful alert for sid=2016808, I also immediately \
see<br> >> > the<br>
>> > following alerts:<br>
>> > 2210032 - ..Suricata Stream FIN1 F1with wrong seq... (sometimes)<br>
>> > 2210045 - ..Suricata stream packet with invalid ack..<br>
>> > 2210046 - ..Suricata stream shutdown RST invalid ack...<br>
>> ><br>
>> > Also, I noticed that I don't have to wait an hour to generate \
successful<br> >> > 2016808 alerts, I can now generate successive alerts if \
I wait to 10-15<br> >> > min.<br>
>> ><br>
>> > Thanks,<br>
>> ><br>
>> > -Bakul<br>
>> ><br>
>> ><br>
>> ><br>
>><br>
>> How do you feed the pcaps for reading - tcpreplay?<br>
>> Is it from another machine or from the same one that has Suricata \
running?<br> >><br>
>> thanks<br>
>><br>
>> ><br>
>> ><br>
>> ><br>
>> > On Sun, Sep 14, 2014 at 5:37 AM, Peter Manev <<a \
href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br> >> > \
wrote:<br> >> >><br>
>> >> On Sun, Sep 14, 2014 at 2:35 AM, bakul khanna <<a \
href="mailto:bakulkhanna@gmail.com">bakulkhanna@gmail.com</a>><br> >> \
>> wrote:<br> >> >> > I am experimenting with having Suricata \
generate an alert, for an ET<br> >> >> > rule<br>
>> >> > (sid=2016808), when I perform a tcpreplay of a pcap file for \
this<br> >> >> > rule.<br>
>> >> ><br>
>> >> > The first time after a Suricata bringup, it does generate the \
alert.<br> >> >> > On<br>
>> >> > subsequent replays of the same pcap file it does not generate \
the<br> >> >> > alert.<br>
>> >> > However if I wait a long time (I tried an hour) and then \
replay the<br> >> >> > pcap<br>
>> >> > file, Suricata successfully alerts then. There is no threshold \
limits<br> >> >> > applied to this rule.<br>
>> >> ><br>
>> >> > I tried reducing the flow and TCP timeouts in suricata.yaml, \
but that<br> >> >> > didn't<br>
>> >> > seem to help.<br>
>> >> ><br>
>> >> > Any suggestion on how I can get Suricata to alert successfully \
on<br> >> >> > successive<br>
>> >> > tcpreplays of this pcap file?<br>
>> >> ><br>
>> >> > Thanks,<br>
>> >> ><br>
>> >> > -Bakul<br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >><br>
>> >><br>
>> >><br>
>> >> Hi,<br>
>> >><br>
>> >> The way you describe the problem it seems TCP timeouts is the \
problem.<br> >> >> I can't be sure though.<br>
>> >><br>
>> >> Can you please provide your timeout values as set up in yaml and \
the<br> >> >> set up you use - how do you start Suricata, do you use \
unix<br> >> >> socket(most likely the case)...so on?<br>
>> >><br>
>> >><br>
>> >><br>
>> >> thanks<br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Regards,<br>
>> >> Peter Manev<br>
>> ><br>
>> ><br>
>><br>
>><br>
<span class="HOEnZb"><font color="#888888">>><br>
>> --<br>
>> Regards,<br>
>> Peter Manev<br>
><br>
><br>
<br>
<br>
<br>
--<br>
Regards,<br>
Peter Manev<br>
</font></span></blockquote></div><br></div>
_______________________________________________
Suricata IDS Users mailing list: oisf-users@openinfosecfoundation.org
Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
OISF: http://www.openinfosecfoundation.org/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic