<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="Generator" content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Along those lines – since most of these Sipviscious REGISTER scans originate from Compromised servers out there……it makes sense to look at REGISTER scans and then actual Traffic (INVITEs) and then correlate data to make ACL Deny decisions. </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I have been told Palladion has something like this and its flexible enough to change detection parameters. However, implementing the automated Blocking piece is what needs to be figured out in conjunction with product.</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"></span></p>
</div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></p><div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:voiceops-bounces@voiceops.org">voiceops-bounces@voiceops.org</a> [mailto:<a href="mailto:voiceops-bounces@voiceops.org">voiceops-bounces@voiceops.org</a>] <b>On Behalf Of </b>anorexicpoodle<br>
<b>Sent:</b> Thursday, May 19, 2011 2:34 PM<br><b>To:</b> Peter Eisengrein<br><b>Cc:</b> <a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a><br><b>Subject:</b> Re: [VoiceOps] Fraud fun</span></p></div></div><p class="MsoNormal">
</p><p class="MsoNormal">Was probably me you're referring to. <br><br>I do this primarily off of syslog data since my process is based off of the acme trust demotion messages. Every time the SD demotes an endpoint to the deny trust level it produces a syslog message, which I write into sql. I then have a process that parses these messages, extracts the IP addresses and generates counts of the number of times an address has been blacklisted in given timeframes, so while at this level the SD is actually protecting the network from the "bad" traffic, it still needs to see X messages before the demotion policy takes effect and the demotion is relatively short term. This short-term blacklist is where my process picks up, and looks for larger trends scoring bad behavior across wider time ranges, and across different SD's and using that data to determine if a given address needs a heavier handed response at the router, so we can preserve SD cpu cycles.<br>
<br>-anorexicpoodle<br><br><br><br><br><br><br>On Thu, 2011-05-19 at 15:59 -0400, Peter Eisengrein wrote: </p><pre> </pre><pre>Someone (sorry, don't have the email handy) previously mentioned that they monitor the output from their acme and then blacklist IP's. Very interesting idea -- how are you determining who the "bad guys" are? From the "friendly-scanner" agent field? In what field is this? Are you doing this from the RADIUS CDRs?</pre>
<pre> </pre><pre>Thanks,</pre><pre>Pete </pre><pre> </pre><pre>_______________________________________________</pre><pre>VoiceOps mailing list</pre><pre><a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a></pre>
<pre><a href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a></pre><p class="MsoNormal"> </p></div></body></html>