<font size=2 face="sans-serif">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. &nbsp;Similarly
for the botcc rules.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">sed -i 's/flags:S;/flags:S+;/g'</font>
<br>
<br><font size=2 face="sans-serif">-David</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">Matthew Jonkman &lt;jonkman@emergingthreatspro.com&gt;</font>
<br><font size=1 color=#5f5f5f face="sans-serif">To: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">David.R.Wharton@regions.com</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">emerging-sigs@emergingthreats.net</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">10/19/2011 10:52 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject: &nbsp; &nbsp;
&nbsp; &nbsp;</font><font size=1 face="sans-serif">Re: [Emerging-Sigs]
ET uni-directional TCP &quot;IP only&quot; rules are a mistake</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>The reasons for going uni-directional were:<br>
<br>
1. Blocking is more predictable this way<br>
<br>
2. ALl the other IP lists are unidirectional <br>
<br>
So it was to get consistent and to make blocking easier primarily.<br>
<br>
But, I've heard from a number of people that would prefer bi-directional
or uni directional the other direction for rbn. So&#8230; I don't know what
the best solution is. :)<br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
Thoughts?<br>
<br>
Matt<br>
<br>
<br>
On Oct 17, 2011, at 5:15 PM, David.R.Wharton@regions.com wrote:<br>
<br>
&gt; Concerning the ET &quot;IP only&quot; 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. &nbsp;For
example, 2408002 used to be: <br>
&gt; <br>
&gt; alert tcp 168.75.207.0/24 any &lt;&gt; $HOME_NET any ... flags:S;
... <br>
&gt; <br>
&gt; but now it is: <br>
&gt; <br>
&gt; alert tcp 168.75.207.0/24 any -&gt; $HOME_NET any ... flags:S; ...
<br>
&gt; <br>
&gt; 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. &nbsp;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).
<br>
&gt; <br>
&gt; I propose we go back to the bi-directional rules or change 'flags:S;'
to 'flags:S+;'. <br>
&gt; <br>
&gt; Make sense? <br>
&gt; <br>
&gt; -David_______________________________________________<br>
&gt; Emerging-sigs mailing list<br>
&gt; Emerging-sigs@emergingthreats.net<br>
&gt; </font></tt><a href="http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs"><tt><font size=2>http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs</font></tt></a><tt><font size=2><br>
&gt; <br>
&gt; Support Emerging Threats! Subscribe to Emerging Threats Pro </font></tt><a href=http://www.emergingthreatspro.com/><tt><font size=2>http://www.emergingthreatspro.com</font></tt></a><tt><font size=2><br>
&gt; The ONLY place to get complete premium rulesets for Snort 2.4.0 through
Current!<br>
<br>
<br>
----------------------------------------------------<br>
Matt Jonkman<br>
Emerging Threats Pro<br>
Open Information Security Foundation (OISF)<br>
Phone 866-504-2523 x110<br>
</font></tt><a href=http://www.emergingthreatspro.com/><tt><font size=2>http://www.emergingthreatspro.com</font></tt></a><tt><font size=2><br>
</font></tt><a href=http://www.openinfosecfoundation.org/><tt><font size=2>http://www.openinfosecfoundation.org</font></tt></a><tt><font size=2><br>
----------------------------------------------------<br>
<br>
</font></tt>
<br>