[Emerging-Sigs] ET uni-directional TCP "IP only" rules are a mistake
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
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
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 220.127.116.11/24 any <> $HOME_NET any ... flags:S; ...
> but now it is:
> alert tcp 18.104.22.168/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
> I propose we go back to the bi-directional rules or change 'flags:S;' to
> Make sense?
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net
> Support Emerging Threats! Subscribe to Emerging Threats Pro
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 866-504-2523 x110
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Emerging-sigs