[Oisf-users] threshold.conf with rate_limit or drop rules

amar countersnipe.com amar at countersnipe.com
Fri Sep 15 10:27:36 UTC 2017


Jeff! Are you saying we are not good enough on this list :-)

On a serious note, I do understand your point. There are many users of Suricata, but perhaps we could do with more contribution from some of them in response to the questions that are posted here...just to ensure that this list is done some justice.

The whole concept of Open Source is there so that as people use the software, try out some new features, they can share their knowledge with others. I think you might just be one of the leaders for rate_filter trials :-)

I do believe that documentation is open for anyone to update.

Amar

> On September 14, 2017 at 7:25 PM Jeff Dyke <jeff.dyke at gmail.com> wrote:
> 
>     Is there a better mailing list for suricata users only?  I feel like this information is not covered in the documents and is glazed over in both the rate_limit and IPS/Inline mode, sections.  and should be pretty standard in using suricata as an IPS.  It appears not.  If you're not running an interface on top of all of this, like securityonion or running in the cloud with headless servers, there are some missing portions.  I'd love to help others out, help document, but i first need to understand.
> 
>     as always, thank you,
>     Jeff
> 
>     On Thu, Sep 14, 2017 at 4:53 PM, Jeff Dyke <jeff.dyke at gmail.com mailto:jeff.dyke at gmail.com > wrote:
> 
>         > >         Hi, i have started to notice one thing on restarts.  the RX-QN notices, 
> > 
> >         $> grep "(RX" /var/log/suricata/suricata.log
> >         14/9/2017 -- 16:24:49 - <Notice> - (RX-Q0) Treated: Pkts 788124, Bytes 297444677, Errors 0
> >         14/9/2017 -- 16:24:49 - <Notice> - (RX-Q0) Verdict: Accepted 787983, Dropped 141, Replaced 0
> >         14/9/2017 -- 16:32:29 - <Notice> - (RX-Q0) Treated: Pkts 5552, Bytes 1534474, Errors 0
> >         14/9/2017 -- 16:32:29 - <Notice> - (RX-Q0) Verdict: Accepted 5422, Dropped 129, Replaced 0
> >         14/9/2017 -- 16:34:18 - <Notice> - (RX-Q0) Treated: Pkts 1658, Bytes 438573, Errors 0
> >         14/9/2017 -- 16:34:18 - <Notice> - (RX-Q0) Verdict: Accepted 1633, Dropped 24, Replaced 0
> >         14/9/2017 -- 20:45:51 - <Notice> - (RX-Q0) Treated: Pkts 176445, Bytes 62762358, Errors 0
> >         14/9/2017 -- 20:45:51 - <Notice> - (RX-Q0) Verdict: Accepted 176220, Dropped 223, Replaced 0
> > 
> >         Are these indeed properly dropped packets, hopefully from my rate_filter rules?  If so, i'm not seeing logs of what has been dropped to confirm i'm dropping the correct packets, how would i enabled this.  I have drop enabled in eve-ips.json, but since these are not drop rules i assume they would go elsewhere???  
> > 
> >         Thanks,
> >         Jeff
> > 
> >         On Wed, Sep 13, 2017 at 6:45 PM, Jeff Dyke <jeff.dyke at gmail.com mailto:jeff.dyke at gmail.com > wrote:
> > 
> >             > > >             Thanks Amar.  I could do this in sshd, but those rules are OK by me b/c i don't allow passwords, nor do i allow root login, you MUST have a valid key, so the defaults are OK, but you're correct i could reduce them to say 2 (at home, I accidentally ssh'd with the wrong/default key, then let me pass -i identity.foo for login).  To me writing the iptables rules is the same as leaving drops in OSSEC b/c it will learn from its sid's and auth.log and prevent it from happening again, and do so on my time schedule (currently 4h, 12h, 1d, 1 week).  I'm actually OK leaving them in OSSEC, but when i get a single ip trying to login and fail over a long period of time, i'd like to drop them, and my idea was to do so with suricata. 
> > > 
> > >             While this is not my question, i'm seeing these as event_type: "ssh", not event_type: "alert", my desire is to make this learn from repeated failed attempts that are outside the bounds of the alert sids, that i have tried to override in threshold.config.  again, not my question, i can open a new thread.
> > > 
> > >             Appreciate the comments, i hope the response points to what i am trying to accomplish with suricata, which i've really appreciated since taking the time to learn how to do most of it correctly.   Its the drops and overrides i continue to struggle with.
> > > 
> > >             Jeff
> > > 
> > >             On Wed, Sep 13, 2017 at 6:02 PM, amarhttp://countersnipe.com <amar at countersnipe.com mailto:amar at countersnipe.com > wrote:
> > > 
> > >                 > > > > 
> > > >                 Hi Jeff
> > > > 
> > > >                 Just an initial thought. Most of the services can be controlled via the service daemons. For example ssh login frequency can be controlled via sshd_config using
> > > > 
> > > >                 MaxAuthTries X(number you are happy with) or using MaxStartups
> > > > 
> > > >                 Alternatively, since you are using iptables, an even better approach would be to use iptables with something like:
> > > > 
> > > >                 iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds X --hitcount Y --rttl --name SSH -j DROP
> > > > 
> > > >                 Once you have eliminated the basic problem then you could get Suricata to inspect deeper.
> > > > 
> > > >                 Hope I didn't just miss the requirement in the first place.
> > > > 
> > > > 
> > > >                 regards
> > > > 
> > > >                 Amar Rathore
> > > >                 CounterSnipe - Suricata based IDS/IPS with so much more.
> > > > 
> > > >                     > > > > >                     On September 13, 2017 at 3:57 PM Jeff Dyke <jeff.dyke at gmail.com mailto:jeff.dyke at gmail.com > wrote:
> > > > > 
> > > > >                     I should have stated that i'm successfully attached to NFQUEUE in inline/IPS mode.  <Info> - NFQ running in standard ACCEPT/DROP mode.
> > > > > 
> > > > >                     On Wed, Sep 13, 2017 at 3:53 PM, Jeff Dyke <jeff.dyke at gmail.com mailto:jeff.dyke at gmail.com > wrote:
> > > > > 
> > > > >                         > > > > > >                         i am running an array of servers on aws (EC2 instances), one server in both the staging and production environments has SSH open and 2 have 443/80 open (active/passive HAProxy instances)
> > > > > > 
> > > > > >                         I've been using OSSEC with active-response to block malicious ssh attacks, and while i like the software and the other things that it finds, I would like to move this type of logic to the edge servers, using suricata.  i'll concentrate on SSH for now, from there i can apply my knowledge or other protocols.
> > > > > > 
> > > > > >                         If i'm understanding correctly (likely not) i could add a rate_filter into threshold.conf, or i could add drop rules.  What is the best practice in this instance.  I know the threshold.config is getting parsed as i see the warning 
> > > > > >                         [ERRCODE: SC_ERR_EVENT_ENGINE(210)] - signature sid:2019876 has a threshold set. The signature event var is given precedence over the threshold.conf one. Bug #425.  
> > > > > > 
> > > > > >                         I'm running suricata 4.0.0 RELEASE
> > > > > > 
> > > > > >                         Thanks, for any pointers.  If rate_filter is correct, how do i convert it to a drop event when threshold is hit?  The docs are great, but i seemed to have missed this piece.
> > > > > > 
> > > > > >                         Jeff
> > > > > > 
> > > > > >                         my 4 threshold.config entries.
> > > > > >                         rate_filter gen_id 1, sig_id 2019876, track by_rule, count 3, seconds 120, new_action drop, timeout 14400
> > > > > >                         rate_filter gen_id 1, sig_id 2101638, track by_rule, count 3, seconds 120, new_action drop, timeout 14400
> > > > > >                         rate_filter gen_id 1, sig_id 2001219, track by_rule, count 3, seconds 120, new_action drop, timeout 14400
> > > > > >                         rate_filter gen_id 1, sig_id 2006546, track by_rule, count 3, seconds 120, new_action drop, timeout 14400
> > > > > >                         suppress gen_id 1, sig_id 2221002, track by_src, iphttp://10.0.0.0/16
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >                     > > > > > 
> > > > >                     _______________________________________________
> > > > >                     Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org mailto:oisf-users at openinfosecfoundation.org
> > > > >                     Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/ http://suricata-ids.org/support/
> > > > >                     List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> > > > > 
> > > > >                     Conference: https://suricon.net
> > > > >                     Trainings: https://suricata-ids.org/training/ https://suricata-ids.org/training/
> > > > > 
> > > > >                 > > > > 
> > > > 
> > > >                 Kind regards
> > > > 
> > > >                 Amar Rathore
> > > > 
> > > >                 CounterSnipe Systems LLC
> > > >                 Tel: +1 617 701 7213
> > > >                 Mobile: +44 (0) 7876 233333
> > > >                 Skype ID: amarrathore
> > > >                 Web:http://www.countersnipe.com <http://www.countersnipe.com/>
> > > > 
> > > > 
> > > >                 This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.
> > > > 
> > > >                 E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions.
> > > > 
> > > >             > > > 
> > > 
> > >         > > 
> > 
> >     > 
>     _______________________________________________
>     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
> 
>     Conference: https://suricon.net
>     Trainings: https://suricata-ids.org/training/
> 


Kind regards

Amar Rathore

CounterSnipe Systems LLC
Tel: +1 617 701 7213
Mobile: +44 (0) 7876 233333
Skype ID: amarrathore
Web: www.countersnipe.com <http://www.countersnipe.com/>


This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170915/80466d5a/attachment-0002.html>


More information about the Oisf-users mailing list