<div dir="ltr">Closing the loop on this, since rate_filter indeed won't work with threshold rules set in the *.rules files. I started to notice that everything i wanted to apply as a drop rather than an alert were pretty well contained in a fairly small set of rule files, so i used oinkmaster.conf to change the entire rule file(s) to drop rather than alert via the modifysids directive.  The one drawback of course is that you can't put a time on this, so a brute force ssh attack is dropped when it hits the threshold, but then is allowed to start over again a few seconds later, which was the most appealing part of rate_filter for me.  The upside is this is where my HIDS kicks in b/c once that IP attempts more than N times, it is added to iptables at a increasing timeout.  <div><br></div><div>Personally i think rate_filter overriding the thresholds in signatures would be a great feature and seemingly not hard to implement (i'm not a great C programmer), so given that fact and that it's been open for many years, and incrementally improved, leads me to believe that there is some complexity i'm missing in, or after, the rule building code namely util-threshold-config.c  I can think of some complexities that would need to be monitored by the admin employing rate_filters as i was trying to use them, but that comes with most of this type of work anyway.</div><div><br></div><div>Appreciate the input/feedback, both here and on IRC, i definitely have a greater understanding of the code/process as i've trolled through quite a bit of the relevant parts that apply to this problem.  And most importantly have working solution to my problem. </div><div><br></div><div>Jeff</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 16, 2017 at 1:01 PM, Jeff Dyke <span dir="ltr"><<a href="mailto:jeff.dyke@gmail.com" target="_blank">jeff.dyke@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks, i'm trying that now, i've upped my threshold to be an  hour and removed it from the rule, i'll report back.  good stuff, didn't realize i could remove that section from the rules, will have to brush up on that apparently. </div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 16, 2017 at 12:16 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"><span>On Sat, Sep 16, 2017 at 5:07 PM, Jeff Dyke <<a href="mailto:jeff.dyke@gmail.com" target="_blank">jeff.dyke@gmail.com</a>> wrote:<br>
> please all, don't get me wrong, I have had wonderful success, and respect<br>
> for the folks that contribute, on many mailing lists starting with apache,<br>
> mysql in the 90's and contributing as possible.  I like to follow OSS<br>
> project mailing lists that i have an active interest in, i won't list them<br>
> here.  That is the main reason i asked if there was another avenue, b/c it<br>
> seemed like a simple question, perhaps i underestimated, my apologies if i<br>
> was terse.<br>
><br>
> I found there was a PR merged in 2016 (current memory) which updated the<br>
> documentation for rate_filter, I've also been looking through the source and<br>
> while i'm not a C programmer, it looked well supported.  Also I now have<br>
> confirmation from one of the developers, via IRC, that it is indeed<br>
> supported other than bug 425.  Now to dig more into the code and see if more<br>
> logging can be enabled for it, as it looks functional from the stats.log<br>
> output, but waiting on confirmation on that.  Hopefully i'll be able to<br>
> report back some further information.  If its enough to suggest a doc update<br>
> i'll be sure to do that as it looks like a great feature for this product<br>
> and understanding it fully could help folks trying to solve similar issues.<br>
<br>
</span>Jeff,<br>
<br>
Can you try the following as a test  -<br>
<br>
for example for one of the ET Open rules that you had in mind -<br>
sid:2019876 - remove the threshold part like so:<br>
alert ssh $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN SSH<br>
BruteForce Tool with fake PUTTY version"; flow:established,to_server;<br>
ssh.softwareversion:"PUTTY"; classtype:network-scan; sid:2019876;<br>
rev:4; metadata:created_at 2014_12_05, updated_at 2014_12_05;)<br>
<br>
and use the rate_filter in your <a href="http://threshold.com" rel="noreferrer" target="_blank">threshold.com</a> as you have originally specified:<br>
<span>rate_filter gen_id 1, sig_id 2019876, track by_rule, count 3, seconds<br>
120, new_action drop, timeout 14400<br>
<br>
</span>and confirm if it behaves as expected?<br>
<br>
Thank you<br>
<div class="m_375049232654276419HOEnZb"><div class="m_375049232654276419h5"><br>
><br>
> Best,<br>
> Jeff<br>
><br>
> On Fri, Sep 15, 2017 at 7:43 PM, Chris Boley <<a href="mailto:ilgtech75@gmail.com" target="_blank">ilgtech75@gmail.com</a>> wrote:<br>
>><br>
>> Jeff, adding to Amar's comments; I was doing some unorthodox inline<br>
>> scanning over a tagged vlan link in router-on-a-stick topology once upon a<br>
>> time with hsrp configurations that traversed the transparent Linux bridge. I<br>
>> asked about others experiences with similar scenarios and got crickets.<br>
>> Sometimes we're pioneers. Sometimes the venture ends in frustration. Overall<br>
>> I'm thankful for this list. I love seeing everyone's ideas.<br>
>> Chris<br>
>><br>
>> On Fri, Sep 15, 2017 at 6:27 AM amar <a href="http://countersnipe.com" rel="noreferrer" target="_blank">countersnipe.com</a><br>
>> <<a href="mailto:amar@countersnipe.com" target="_blank">amar@countersnipe.com</a>> wrote:<br>
>>><br>
>>> Jeff! Are you saying we are not good enough on this list :-)<br>
>>><br>
>>> On a serious note, I do understand your point. There are many users of<br>
>>> Suricata, but perhaps we could do with more contribution from some of them<br>
>>> in response to the questions that are posted here...just to ensure that this<br>
>>> list is done some justice.<br>
>>><br>
>>> The whole concept of Open Source is there so that as people use the<br>
>>> software, try out some new features, they can share their knowledge with<br>
>>> others. I think you might just be one of the leaders for rate_filter trials<br>
>>> :-)<br>
>>><br>
>>> I do believe that documentation is open for anyone to update.<br>
>>><br>
>>> Amar<br>
>>><br>
>>> On September 14, 2017 at 7:25 PM Jeff Dyke <<a href="mailto:jeff.dyke@gmail.com" target="_blank">jeff.dyke@gmail.com</a>> wrote:<br>
>>><br>
>>> Is there a better mailing list for suricata users only?  I feel like this<br>
>>> information is not covered in the documents and is glazed over in both the<br>
>>> rate_limit and IPS/Inline mode, sections.  and should be pretty standard in<br>
>>> using suricata as an IPS.  It appears not.  If you're not running an<br>
>>> interface on top of all of this, like securityonion or running in the cloud<br>
>>> with headless servers, there are some missing portions.  I'd love to help<br>
>>> others out, help document, but i first need to understand.<br>
>>><br>
>>> as always, thank you,<br>
>>> Jeff<br>
>>><br>
>>> On Thu, Sep 14, 2017 at 4:53 PM, Jeff Dyke <<a href="mailto:jeff.dyke@gmail.com" target="_blank">jeff.dyke@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi, i have started to notice one thing on restarts.  the RX-QN notices,<br>
>>><br>
>>> $> grep "(RX" /var/log/suricata/suricata.log<br>
>>> 14/9/2017 -- 16:24:49 - <Notice> - (RX-Q0) Treated: Pkts 788124, Bytes<br>
>>> 297444677, Errors 0<br>
>>> 14/9/2017 -- 16:24:49 - <Notice> - (RX-Q0) Verdict: Accepted 787983,<br>
>>> Dropped 141, Replaced 0<br>
>>> 14/9/2017 -- 16:32:29 - <Notice> - (RX-Q0) Treated: Pkts 5552, Bytes<br>
>>> 1534474, Errors 0<br>
>>> 14/9/2017 -- 16:32:29 - <Notice> - (RX-Q0) Verdict: Accepted 5422,<br>
>>> Dropped 129, Replaced 0<br>
>>> 14/9/2017 -- 16:34:18 - <Notice> - (RX-Q0) Treated: Pkts 1658, Bytes<br>
>>> 438573, Errors 0<br>
>>> 14/9/2017 -- 16:34:18 - <Notice> - (RX-Q0) Verdict: Accepted 1633,<br>
>>> Dropped 24, Replaced 0<br>
>>> 14/9/2017 -- 20:45:51 - <Notice> - (RX-Q0) Treated: Pkts 176445, Bytes<br>
>>> 62762358, Errors 0<br>
>>> 14/9/2017 -- 20:45:51 - <Notice> - (RX-Q0) Verdict: Accepted 176220,<br>
>>> Dropped 223, Replaced 0<br>
>>><br>
>>> Are these indeed properly dropped packets, hopefully from my rate_filter<br>
>>> rules?  If so, i'm not seeing logs of what has been dropped to confirm i'm<br>
>>> dropping the correct packets, how would i enabled this.  I have drop enabled<br>
>>> in eve-ips.json, but since these are not drop rules i assume they would go<br>
>>> elsewhere???<br>
>>><br>
>>> Thanks,<br>
>>> Jeff<br>
>>><br>
>>> On Wed, Sep 13, 2017 at 6:45 PM, Jeff Dyke <<a href="mailto:jeff.dyke@gmail.com" target="_blank">jeff.dyke@gmail.com</a>> wrote:<br>
>>><br>
>>> Thanks Amar.  I could do this in sshd, but those rules are OK by me b/c i<br>
>>> don't allow passwords, nor do i allow root login, you MUST have a valid key,<br>
>>> so the defaults are OK, but you're correct i could reduce them to say 2 (at<br>
>>> home, I accidentally ssh'd with the wrong/default key, then let me pass -i<br>
>>> identity.foo for login).  To me writing the iptables rules is the same as<br>
>>> leaving drops in OSSEC b/c it will learn from its sid's and auth.log and<br>
>>> prevent it from happening again, and do so on my time schedule (currently<br>
>>> 4h, 12h, 1d, 1 week).  I'm actually OK leaving them in OSSEC, but when i get<br>
>>> a single ip trying to login and fail over a long period of time, i'd like to<br>
>>> drop them, and my idea was to do so with suricata.<br>
>>><br>
>>> While this is not my question, i'm seeing these as event_type: "ssh", not<br>
>>> event_type: "alert", my desire is to make this learn from repeated failed<br>
>>> attempts that are outside the bounds of the alert sids, that i have tried to<br>
>>> override in threshold.config.  again, not my question, i can open a new<br>
>>> thread.<br>
>>><br>
>>> Appreciate the comments, i hope the response points to what i am trying<br>
>>> to accomplish with suricata, which i've really appreciated since taking the<br>
>>> time to learn how to do most of it correctly.   Its the drops and overrides<br>
>>> i continue to struggle with.<br>
>>><br>
>>> Jeff<br>
>>><br>
>>> On Wed, Sep 13, 2017 at 6:02 PM, amar <a href="http://countersnipe.com" rel="noreferrer" target="_blank">countersnipe.com</a><br>
>>> <<a href="mailto:amar@countersnipe.com" target="_blank">amar@countersnipe.com</a>> wrote:<br>
>>><br>
>>> Hi Jeff<br>
>>><br>
>>> Just an initial thought. Most of the services can be controlled via the<br>
>>> service daemons. For example ssh login frequency can be controlled via<br>
>>> sshd_config using<br>
>>><br>
>>> MaxAuthTries X(number you are happy with) or using MaxStartups<br>
>>><br>
>>> Alternatively, since you are using iptables, an even better approach<br>
>>> would be to use iptables with something like:<br>
>>><br>
>>> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent<br>
>>> --update --seconds X --hitcount Y --rttl --name SSH -j DROP<br>
>>><br>
>>> Once you have eliminated the basic problem then you could get Suricata to<br>
>>> inspect deeper.<br>
>>><br>
>>> Hope I didn't just miss the requirement in the first place.<br>
>>><br>
>>><br>
>>> regards<br>
>>><br>
>>> Amar Rathore<br>
>>> CounterSnipe - Suricata based IDS/IPS with so much more.<br>
>>><br>
>>> On September 13, 2017 at 3:57 PM Jeff Dyke <<a href="mailto:jeff.dyke@gmail.com" target="_blank">jeff.dyke@gmail.com</a>> wrote:<br>
>>><br>
>>> I should have stated that i'm successfully attached to NFQUEUE in<br>
>>> inline/IPS mode.  <Info> - NFQ running in standard ACCEPT/DROP mode.<br>
>>><br>
>>> On Wed, Sep 13, 2017 at 3:53 PM, Jeff Dyke <<a href="mailto:jeff.dyke@gmail.com" target="_blank">jeff.dyke@gmail.com</a>> wrote:<br>
>>><br>
>>> i am running an array of servers on aws (EC2 instances), one server in<br>
>>> both the staging and production environments has SSH open and 2 have 443/80<br>
>>> open (active/passive HAProxy instances)<br>
>>><br>
>>> I've been using OSSEC with active-response to block malicious ssh<br>
>>> attacks, and while i like the software and the other things that it finds, I<br>
>>> would like to move this type of logic to the edge servers, using suricata.<br>
>>> i'll concentrate on SSH for now, from there i can apply my knowledge or<br>
>>> other protocols.<br>
>>><br>
>>> If i'm understanding correctly (likely not) i could add a rate_filter<br>
>>> into threshold.conf, or i could add drop rules.  What is the best practice<br>
>>> in this instance.  I know the threshold.config is getting parsed as i see<br>
>>> the warning<br>
>>> [ERRCODE: SC_ERR_EVENT_ENGINE(210)] - signature sid:2019876 has a<br>
>>> threshold set. The signature event var is given precedence over the<br>
>>> threshold.conf one. Bug #425.<br>
>>><br>
>>> I'm running suricata 4.0.0 RELEASE<br>
>>><br>
>>> Thanks, for any pointers.  If rate_filter is correct, how do i convert it<br>
>>> to a drop event when threshold is hit?  The docs are great, but i seemed to<br>
>>> have missed this piece.<br>
>>><br>
>>> Jeff<br>
>>><br>
>>> my 4 threshold.config entries.<br>
>>> rate_filter gen_id 1, sig_id 2019876, track by_rule, count 3, seconds<br>
>>> 120, new_action drop, timeout 14400<br>
>>> rate_filter gen_id 1, sig_id 2101638, track by_rule, count 3, seconds<br>
>>> 120, new_action drop, timeout 14400<br>
>>> rate_filter gen_id 1, sig_id 2001219, track by_rule, count 3, seconds<br>
>>> 120, new_action drop, timeout 14400<br>
>>> rate_filter gen_id 1, sig_id 2006546, track by_rule, count 3, seconds<br>
>>> 120, new_action drop, timeout 14400<br>
>>> suppress gen_id 1, sig_id 2221002, track by_src, ip <a href="http://10.0.0.0/16" rel="noreferrer" target="_blank">10.0.0.0/16</a><br>
>>><br>
>>><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@openinfosecfoundati<wbr>on.org</a><br>
>>> Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/suppor<wbr>t/</a><br>
>>> List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfound<wbr>ation.org/mailman/listinfo/<wbr>oisf-users</a><br>
>>><br>
>>> Conference: <a href="https://suricon.net" rel="noreferrer" target="_blank">https://suricon.net</a><br>
>>> Trainings: <a href="https://suricata-ids.org/training/" rel="noreferrer" target="_blank">https://suricata-ids.org/train<wbr>ing/</a><br>
>>><br>
>>><br>
>>> Kind regards<br>
>>><br>
>>> Amar Rathore<br>
>>><br>
>>> CounterSnipe Systems LLC<br>
>>> Tel: <a href="tel:%2B1%20617%20701%207213" value="+16177017213" target="_blank">+1 617 701 7213</a><br>
>>> Mobile: <a href="tel:%2B44%20%280%29%207876%20233333" value="+447876233333" target="_blank">+44 (0) 7876 233333</a><br>
>>> Skype ID: amarrathore<br>
>>> Web: <a href="http://www.countersnipe.com" rel="noreferrer" target="_blank">www.countersnipe.com</a> <<a href="http://www.countersnipe.com/" rel="noreferrer" target="_blank">http://www.countersnipe.com/</a>><br>
>>><br>
>>> This message contains confidential information and is intended only for<br>
>>> the individual named. If you are not the named addressee you should not<br>
>>> disseminate, distribute or copy this e-mail. Please notify the sender<br>
>>> immediately by e-mail if you have received this e-mail by mistake and delete<br>
>>> this e-mail from your system.<br>
>>><br>
>>> E-mail transmission cannot be guaranteed to be secure or error-free as<br>
>>> information could be intercepted, corrupted, lost, destroyed, arrive late or<br>
>>> incomplete, or contain viruses. The sender therefore does not accept<br>
>>> liability for any errors or omissions.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@openinfosecfoundati<wbr>on.org</a><br>
>>> Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/suppor<wbr>t/</a><br>
>>> List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfound<wbr>ation.org/mailman/listinfo/<wbr>oisf-users</a><br>
>>><br>
>>> Conference: <a href="https://suricon.net" rel="noreferrer" target="_blank">https://suricon.net</a><br>
>>> Trainings: <a href="https://suricata-ids.org/training/" rel="noreferrer" target="_blank">https://suricata-ids.org/train<wbr>ing/</a><br>
>>><br>
>>><br>
>>> Kind regards<br>
>>><br>
>>> Amar Rathore<br>
>>><br>
>>> CounterSnipe Systems LLC<br>
>>> Tel: <a href="tel:%2B1%20617%20701%207213" value="+16177017213" target="_blank">+1 617 701 7213</a><br>
>>> Mobile: <a href="tel:%2B44%20%280%29%207876%20233333" value="+447876233333" target="_blank">+44 (0) 7876 233333</a><br>
>>> Skype ID: amarrathore<br>
>>> Web: <a href="http://www.countersnipe.com" rel="noreferrer" target="_blank">www.countersnipe.com</a> <<a href="http://www.countersnipe.com/" rel="noreferrer" target="_blank">http://www.countersnipe.com/</a>><br>
>>><br>
>>> This message contains confidential information and is intended only for<br>
>>> the individual named. If you are not the named addressee you should not<br>
>>> disseminate, distribute or copy this e-mail. Please notify the sender<br>
>>> immediately by e-mail if you have received this e-mail by mistake and delete<br>
>>> this e-mail from your system.<br>
>>><br>
>>> E-mail transmission cannot be guaranteed to be secure or error-free as<br>
>>> information could be intercepted, corrupted, lost, destroyed, arrive late or<br>
>>> incomplete, or contain viruses. The sender therefore does not accept<br>
>>> liability for any errors or omissions.<br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@openinfosecfoundati<wbr>on.org</a><br>
>>> Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/suppor<wbr>t/</a><br>
>>> List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfound<wbr>ation.org/mailman/listinfo/<wbr>oisf-users</a><br>
>>><br>
>>> Conference: <a href="https://suricon.net" rel="noreferrer" target="_blank">https://suricon.net</a><br>
>>> Trainings: <a href="https://suricata-ids.org/training/" rel="noreferrer" target="_blank">https://suricata-ids.org/train<wbr>ing/</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@openinfosecfoundati<wbr>on.org</a><br>
> Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/suppor<wbr>t/</a><br>
> List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfound<wbr>ation.org/mailman/listinfo/<wbr>oisf-users</a><br>
><br>
> Conference: <a href="https://suricon.net" rel="noreferrer" target="_blank">https://suricon.net</a><br>
> Trainings: <a href="https://suricata-ids.org/training/" rel="noreferrer" target="_blank">https://suricata-ids.org/train<wbr>ing/</a><br>
<br>
<br>
<br>
</div></div><span class="m_375049232654276419HOEnZb"><font color="#888888">--<br>
Regards,<br>
Peter Manev<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>