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

David.R.Wharton@regions.com David.R.Wharton at regions.com
Wed Oct 19 12:04:09 EDT 2011

The malvertising rules don't make sense being uni-directional in-bound the 
way they are now since most connections to malvertisers are going to 
initiate from the client's browser.  Similarly for the botcc rules.

That said, a simple sed on emerging-rbn-malvertisers.rules, 
emerging-rbn.rules, emerging-botcc.rules, etc. will fix this so it is easy 
to deal with on my end; I just thought the global rules repos should be 
changed too.

sed -i 's/flags:S;/flags:S+;/g'


From:   Matthew Jonkman <jonkman at emergingthreatspro.com>
To:     David.R.Wharton at regions.com
Cc:     emerging-sigs at emergingthreats.net
Date:   10/19/2011 10:52 AM
Subject:        Re: [Emerging-Sigs] ET uni-directional TCP "IP only" rules 
are a mistake

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.



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 any <> $HOME_NET any ... flags:S; ... 
> but now it is: 
> alert tcp 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 
> I propose we go back to the bi-directional rules or change 'flags:S;' to 
> 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 
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through 

Matt Jonkman
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 866-504-2523 x110

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.emergingthreats.net/pipermail/emerging-sigs/attachments/20111019/7cb4714e/attachment.html

More information about the Emerging-sigs mailing list