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

Thu Sep 14 23:25:45 UTC 2017

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> 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> 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, amar countersnipe.com <
>> 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> 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> 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, ip 10.0.0.0/16
>>>
>>>
>>>
>>> _______________________________________________
>>> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>>> Site: http://suricata-ids.org | Support: http://suricata-ids.org/suppor
>>> t/
>>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/ois
>>> f-users
>>>
>>> Conference: https://suricon.net
>>> Trainings: https://suricata-ids.org/training/
>>>
>>>
>>> Kind regards
>>>
>>> Amar Rathore
>>>
>>> CounterSnipe Systems LLC
>>> Tel: +1 617 701 7213 <(617)%20701-7213>
>>> Mobile: +44 (0) 7876 233333 <+44%207876%20233333>
>>> 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/20170914/7c27420d/attachment-0002.html>