<font size=2 face="sans-serif">Thanks William. &nbsp; In my first email
I gave the example of SID 2408002 which can be found in emerging-rbn-malvertisers.rules
-- </font><a href="http://lists.emergingthreats.net/pipermail/emerging-sigs/2011-October/016142.html"><font size=2 face="sans-serif">http://lists.emergingthreats.net/pipermail/emerging-sigs/2011-October/016142.html</font></a><font size=2 face="sans-serif">.</font>
<br>
<br><font size=2 face="sans-serif">I agree with you that there are valuable
uni-directional rules targeting server responses. &nbsp;However, In the
case of the ET &quot;IP only&quot; rules like emerging-rbn-malvertisers.rules,
none of them will fire if your $HOME_NET IPs are not part of the RBN, malvertiser,
etc. IPs specified in the rule. &nbsp;This is because the rules are looking
for the SYN flag inbound and only the SYN flag. &nbsp;A server acting like
a server is going to send a SYN-ACK but never just a SYN flag.</font>
<br>
<br><font size=2 face="sans-serif">Make sense? Perhaps I should have been
clearer. &nbsp;The issue isn't just that they are uni-directional, it is
uni-directional inbound with 'flags:S;'. &nbsp;Yes, sometimes you want
this but most of the time for malvertising and C&amp;C communication, the
$HOME_NET client is going to initiate the communication.</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">William Salusky &lt;william.salusky@teamaol.com&gt;</font>
<br><font size=1 color=#5f5f5f face="sans-serif">To: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">&lt;emerging-sigs@emergingthreats.net&gt;</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 11:23 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><font size=1 color=#5f5f5f face="sans-serif">Sent by: &nbsp; &nbsp;
&nbsp; &nbsp;</font><font size=1 face="sans-serif">emerging-sigs-bounces@emergingthreats.net</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>You didn't provide an example of which rule(s) you
were referring, but<br>
considering malvertising is a major issue I am involved in the<br>
investigation of, there are indeed intentional uni-directional rules<br>
that target server responses and should/would never fire on client -&gt;<br>
server requests. <br>
<br>
It's not a mistake if you know exactly what you are looking for.<br>
<br>
W<br>
<br>
On 10/19/11 12:04 PM, David.R.Wharton@regions.com wrote:<br>
&gt; The malvertising rules don't make sense being uni-directional in-bound
the <br>
&gt; way they are now since most connections to malvertisers are going
to <br>
&gt; initiate from the client's browser. &nbsp;Similarly for the botcc
rules.<br>
&gt;<br>
&gt; That said, a simple sed on emerging-rbn-malvertisers.rules, <br>
&gt; emerging-rbn.rules, emerging-botcc.rules, etc. will fix this so it
is easy <br>
&gt; to deal with on my end; I just thought the global rules repos should
be <br>
&gt; changed too.<br>
&gt;<br>
&gt; sed -i 's/flags:S;/flags:S+;/g'<br>
&gt;<br>
<br>
_______________________________________________<br>
Emerging-sigs mailing list<br>
Emerging-sigs@emergingthreats.net<br>
</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>
<br>
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>
The ONLY place to get complete premium rulesets for Snort 2.4.0 through
Current!<br>
</font></tt>
<br>