[Emerging-Sigs] ET uni-directional TCP "IP only" rules are a mistake

Matthew Jonkman jonkman at emergingthreatspro.com
Wed Oct 19 11:52:44 EDT 2011


The reasons for going uni-directional were:

1. Blocking is more predictable this way

2. ALl the other IP lists are unidirectional 

So it was to get consistent and to make blocking easier primarily.

But, I've heard from a number of people that would prefer bi-directional or uni directional the other direction for rbn. So… I don't know what the best solution is. :)

Long term we're moving toward making this data, and the ET Pro IP and DNS reputation feeds available in a form that suricata's ip and dns reputation module will be able to let you query categories and such in rules and block that way. Much more efficient. And likely the Snort blacklist matcher if it supports categories one day. But we definitely need a way to do these in rules for the forseeable future.

So, we could put the rbn rules in 2 versions, bi and uni directional. Or leave as is and put up an easy tool to let anyone generate a version as they'd like. 

I'll make available what you all like. More versions I feel may make it a bit more confusing to the beginning suricata/snort user (and we certainly have things difficult enough as is). But it's possible.

Thoughts?

Matt


On Oct 17, 2011, at 5:15 PM, David.R.Wharton at regions.com wrote:

> Concerning the ET "IP only" rules like emerging-rbn.rules, emerging-rbn-malvertisers.rules, emerging-compromised.rules , etc. (technically, the versions written for Snort are not true IP rules but are split into separate TCP and UDP rules since performance is better in that case and Snort does not seem to be able to handle true IP only rules as well as Suricata), in regard to the TCP rules written for Snort, recently there has been some changes from bi-direction to uni-directional rules.  For example, 2408002 used to be: 
> 
> alert tcp 168.75.207.0/24 any <> $HOME_NET any ... flags:S; ... 
> 
> but now it is: 
> 
> alert tcp 168.75.207.0/24 any -> $HOME_NET any ... flags:S; ... 
> 
> The problem is that with the uni-directional rules, you are only going to alert on the initial inbound (to $HOME_NET) TCP packet from a client (the SYN packet) and not the SYN-ACK response from a server or a client connection initiating from any (including $HOME_NET) to !$HOME_NET.  So if you have $HOME_NET configured (not set to 'any'), this does not make sense for things like emerging-rbn-malvertisers.rules since most of these are going to be connections initiating from $HOME_NET to !$HOME_NET ($EXTERNAL_NET). 
> 
> I propose we go back to the bi-directional rules or change 'flags:S;' to 'flags:S+;'. 
> 
> Make sense? 
> 
> -David_______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
> 
> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!


----------------------------------------------------
Matt Jonkman
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 866-504-2523 x110
http://www.emergingthreatspro.com
http://www.openinfosecfoundation.org
----------------------------------------------------



More information about the Emerging-sigs mailing list