[Oisf-users] Oisf-users Digest, Vol 86, Issue 27

Thu Jan 26 18:18:54 UTC 2017

Use:

flowbits:noalert;

More details:

http://suricata.readthedocs.io/en/latest/rules/flow-keywords.html?highlight=noalert

On Thu, Jan 26, 2017 at 10:09 AM, erik clark <philosnef at gmail.com> wrote:
> Is there a way to get it so the alert that sets the flowbit does not alert,
> only the one that follows where it checks to see if it was set?
>
> On Thu, Jan 26, 2017 at 12:00 PM,
> <oisf-users-request at lists.openinfosecfoundation.org> wrote:
>>
>> Send Oisf-users mailing list submissions to
>>         oisf-users at lists.openinfosecfoundation.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>
>> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>> or, via email, send a message with subject or body 'help' to
>>         oisf-users-request at lists.openinfosecfoundation.org
>>
>> You can reach the person managing the list at
>>         oisf-users-owner at lists.openinfosecfoundation.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Oisf-users digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: suricata 3.2.0 for 10Gb performance (erik clark)
>>    2. Re: suricata 3.2.0 for 10Gb performance (Michał Purzyński)
>>    3. Re: af_packet and rss queue count (Michał Purzyński)
>>    4. question about http_uri and file_data (erik clark)
>>    5. Re: question about http_uri and file_data (Victor Julien)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 26 Jan 2017 10:35:16 -0500
>> From: erik clark <philosnef at gmail.com>
>> To: "Cooper F. Nelson" <cnelson at ucsd.edu>
>> Cc: oisf-users at lists.openinfosecfoundation.org
>> Subject: Re: [Oisf-users] suricata 3.2.0 for 10Gb performance
>> Message-ID:
>>
>> <CAK6atxpQE4gsepRKS_TE3Hquo8D55wZ25T+HioR=zPyWYbSYAA at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Cooper, just to followup. RedHat has confirmed that tpacket_v3 commits are
>> in the 3.10 branch of RHEL7. They report it as being better supported in
>> the 4 kernel line, but it is indeed supported though. If you are aware of
>> specific commits for tpacket that you would like to see, pass them on and
>> we can get them into 7.4 probably.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170126/e8b27732/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 26 Jan 2017 08:31:50 -0800
>> From: Michał Purzyński <michalpurzynski1 at gmail.com>
>> To: erik clark <philosnef at gmail.com>
>> Cc: oisf-users at lists.openinfosecfoundation.org
>> Subject: Re: [Oisf-users] suricata 3.2.0 for 10Gb performance
>> Message-ID: <57394CC6-A016-46B8-A4C4-942D74ECE0D1 at gmail.com>
>> Content-Type: text/plain;       charset=us-ascii
>>
>> How about fixing the hash calculations, a patch that went upstream in the
>> late 4.4
>>
>> > On Jan 26, 2017, at 7:35 AM, erik clark <philosnef at gmail.com> wrote:
>> >
>> > Cooper, just to followup. RedHat has confirmed that tpacket_v3 commits
>> > are in the 3.10 branch of RHEL7. They report it as being better supported in
>> > the 4 kernel line, but it is indeed supported though. If you are aware of
>> > specific commits for tpacket that you would like to see, pass them on and we
>> > can get them into 7.4 probably.
>> > _______________________________________________
>> > Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>> > Site: http://suricata-ids.org | Support:
>> > http://suricata-ids.org/support/
>> > List:
>> > https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 26 Jan 2017 08:34:50 -0800
>> From: Michał Purzyński <michalpurzynski1 at gmail.com>
>> To: erik clark <philosnef at gmail.com>
>> Cc: "oisf-users at lists.openinfosecfoundation.org"
>>         <oisf-users at lists.openinfosecfoundation.org>
>> Subject: Re: [Oisf-users] af_packet and rss queue count
>> Message-ID: <7EA678C7-26EC-40DD-80C8-8B09BB6B7068 at gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Pinning threads and disabling flow director should help. No time to test
>> it though. Well, a quick test with bro half a year ago looked promising.
>> There are more issues no one is aware of, I'll describe it later.
>>
>> > On Jan 26, 2017, at 7:05 AM, erik clark <philosnef at gmail.com> wrote:
>> >
>> > If you set a symmetric queue (posted elsewhere in some thread), I
>> > believe you do not see issues with reordering. We have seen output from
>> > pf_ring and af_packet as being near identical in logged connections, events,
>> > so unless pf_ring is also mangling connectings the same way as
>> > if_packet/AF_PACKET, we can assume this is a non-issue. Packet loss is
>> > actually substantually lower for both suricata and bro using a symmetric
>> > key, proper udp/tcp hashing, and af_packet compared to pf_ring on identical
>> > hardware. It comes at cost of cpu over memory however.
>> >
>> >
>> >> On Thu, Jan 26, 2017 at 9:56 AM, Seth Hall <seth at icir.org> wrote:
>> >>
>> >> > On Jan 26, 2017, at 8:29 AM, erik clark <philosnef at gmail.com> wrote:
>> >> >
>> >> > This is going into RHEL7.4, which is a 3.10 branch. We will be
>> >> > staying on RHEL7 as we have a full support contract with them, and to be
>> >> > honest, their engineers are amazing.
>> >>
>> >> I would still be concerned about the packet reordering issue coming
>> >> from the NIC with having multiple queues enabled.  This appears to be an
>> >> actual hardware behavior and not fixable through software.  The effects from
>> >> it can be fairly hard to discern too, but you may see an inflated
>> >> capture_loss (in Bro, I forget what the Suricata equivalent is called) due
>> >> to the packet reordering.  It can also more directly effect things in UDP
>> >> DNS query and reply matching.
>> >>
>> >> Sorry for the Bro stuff on the OISF mailing list, but I thought it was
>> >> relevant since Erik is running Bro as well as Suricata on his system and I
>> >> assume that Suricata would also have the same or similar issues with
>> >> reordered packets.  It's not an easy problem to diagnose.
>> >>
>> >>   .Seth
>> >>
>> >> --
>> >> Seth Hall
>> >> International Computer Science Institute
>> >> (Bro) because everyone has a network
>> >> http://www.bro.org/
>> >>
>> >
>> > _______________________________________________
>> > Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>> > Site: http://suricata-ids.org | Support:
>> > http://suricata-ids.org/support/
>> > List:
>> > https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170126/692e5abb/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 26 Jan 2017 11:52:49 -0500
>> From: erik clark <philosnef at gmail.com>
>> To: oisf-users at lists.openinfosecfoundation.org
>> Subject: [Oisf-users] question about http_uri and file_data
>> Message-ID:
>>
>> <CAK6atxqVcrpKomr_h4m3Grc9d7D1tF4T2ypono1OXjfzCuEgXQ at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I have a pcap I am trying to get a signature to fire off of. Here is the
>> sig:
>>
>> alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"packer";
>> content:"menu|2e|js"; http_uri; file_data;
>> content:"eval(function(p,a,c,k,e,d)"; fast_pattern:only; sid:1; rev:7;)
>>
>> I can't provide a pcap, but this is a standard dean edwards packer menu
>> javascript.
>>
>> The problem I have is:
>>
>> the http_uri hit comes from local to remote (this is a get request).
>> the file_data hit comes remote to local
>>
>> Is there any way to get one rule to fire off this? Maybe with flowbits?
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170126/c310160e/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Thu, 26 Jan 2017 17:55:21 +0100
>> From: Victor Julien <lists at inliniac.net>
>> To: oisf-users at lists.openinfosecfoundation.org
>> Subject: Re: [Oisf-users] question about http_uri and file_data
>> Message-ID: <910e5ab8-925b-8ea9-ffbc-2c9f91662d95 at inliniac.net>
>> Content-Type: text/plain; charset=utf-8
>>
>> On 26-01-17 17:52, erik clark wrote:
>> > I have a pcap I am trying to get a signature to fire off of. Here is the
>> > sig:
>> >
>> > alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"packer";
>> > content:"menu|2e|js"; http_uri; file_data;
>> > content:"eval(function(p,a,c,k,e,d)"; fast_pattern:only; sid:1; rev:7;)
>> >
>> > I can't provide a pcap, but this is a standard dean edwards packer menu
>> > javascript.
>> >
>> > The problem I have is:
>> >
>> > the http_uri hit comes from local to remote (this is a get request).
>> > the file_data hit comes remote to local
>> >
>> > Is there any way to get one rule to fire off this? Maybe with flowbits?
>>
>> Right now only flowbits can solve this.
>>
>> We're thinking about adding a class of bidirectional rules for this
>> scenario, but thats for the future.
>> --
>> ---------------------------------------------
>> Victor Julien
>> http://www.inliniac.net/
>> PGP: http://www.inliniac.net/victorjulien.asc
>> ---------------------------------------------
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Oisf-users mailing list
>> Oisf-users at lists.openinfosecfoundation.org
>> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>
>>
>> ------------------------------
>>
>> End of Oisf-users Digest, Vol 86, Issue 27
>> ******************************************
>
>
>
> _______________________________________________
> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>