<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>If you don't mind sending back a failure response, then you can instead add a route for <a href="sip:0.0.0.0">sip:0.0.0.0</a> which should cause it to fail. In newer releases there's an explicit "reject" action which lets you just tell it to reject it more directly, as well as what response code to use when rejecting it, and you can still drop that response so it silently discards it. Using the reject action is the new recommended way (it's simpler, slightly more efficient, and has specific stats/counters and such).</div><div><br></div><div>-hadriel</div><div><br></div><div><div>On Nov 26, 2010, at 7:53 PM, Christian Pena wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
I did it by creating a bogus session-agent (say with ip 1.1.1.1) and
set it in disabled state. Then routed the packets to that session
agent by changing the route header to something like <a class="moz-txt-link-freetext" href="sip:1.1.1.1">sip:1.1.1.1</a><br>
<br>
anorexicpoodle wrote:
<blockquote cite="mid:1290818591.1954.21.camel@poodle-x300" type="cite">
Without getting into the gory details, the recommended method
seems to be using HMR to add a route header pointing at a bogus
session agent which will be obeyed over any local policy, then you
create a response map mapping 503's from that agent back to an
unused 6xx code, and then finally setting an option in the sip
interface to drop the unused 6xx code, and the effective result is
a black hole based on anything you can get at via HMR. <br>
<br>
On Sat, 2010-11-27 at 09:38 +1030, Peter Childs wrote:
<blockquote type="CITE">
<pre>I'm interested in this. We use some HMRs to do various manipulations, but is there a method to 'drop' traffic matching HMRs, or cause a DOS/ACL block on the source?
________________________________________
From: <a moz-do-not-send="true" href="mailto:voiceops-bounces@voiceops.org">voiceops-bounces@voiceops.org</a> [<a moz-do-not-send="true" href="mailto:voiceops-bounces@voiceops.org">voiceops-bounces@voiceops.org</a>] On Behalf Of anorexicpoodle [<a moz-do-not-send="true" href="mailto:anorexicpoodle@gmail.com">anorexicpoodle@gmail.com</a>]
Sent: Saturday, 27 November 2010 7:15 AM
To: Christian Pena
Cc: <a moz-do-not-send="true" href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a>
Subject: Re: [VoiceOps] Strange register attack
I have a fairly substantial HMR ruleset on our access side doing everything from user agent filtering, to collecting custom values for CDR's, and while there is a CPU hit, its not nearly as bad as you might think.
On Fri, 2010-11-26 at 09:26 -0500, Christian Pena wrote:
We have seen similar things on our network. I never setup the HMRs on the access side of the Acme thinking they would cause a substantial increase in CPU usage. Anyone have any luck in doing this on a production network?
Thanks,
Chris
anorexicpoodle wrote:
This is a well-known attack. If you're running an Acme, contact TAC, they have a HMR ruleset that will blackhole this attack based on the user agent, though if your access side is tuned up well enough it should black-hole itself pretty quickly.
On Thu, 2010-11-25 at 23:44 -0600, Lee Riemer wrote:
Yes, this is normal. Just figure out how to deal with it.
On 11/25/2010 11:03 PM, Darren Schreiber wrote:
> We've been suffering from this, too. The SIP headers are hacked and
> completely bogus. They seem to be from only a few select IPs from us.
>
> I'm about ready to abandon port 5060 :-)
>
> - Darren
>
>
> On 11/25/10 9:03 PM, "Peter Childs"<<a moz-do-not-send="true" href="mailto:PChilds@internode.com.au">PChilds@internode.com.au</a><<a moz-do-not-send="true" href="mailto:PChilds@internode.com.au">mailto:PChilds@internode.com.au</a>>> wrote:
>
>> sql> select count(ua) from sip_trace where ua = 'friendly-scanner';
>> COUNT(UA): 22330
>>
>> We get thousands of these scans from all over the joint all the time.
>>
>> That is in the last 8 hours...
>>
>> sql> select count(fromip), fromip from sip_trace where ua =
>> 'friendly-scanner' group by fromip;
>> COUNT(FROMIP): 3
>> FROMIP : 124.195.52.250
>>
>> COUNT(FROMIP): 1
>> FROMIP : 124.254.44.172
>>
>> COUNT(FROMIP): 13127
>> FROMIP : 202.101.187.66
>>
>> COUNT(FROMIP): 9199
>> FROMIP : 74.218.78.29
>> (4 rows, 10201 ms)
>>
>>
>> I occasionally have discussions with others about
>> <a moz-do-not-send="true" href="http://tools.ietf.org/html/rfc5635">http://tools.ietf.org/html/rfc5635</a> using some thresholds to block some of
>> these at the border, with the problem being that one day someone will use
>> some cloud platform and we will take out we shouldn't.
>>
>> The ACME SBCs we use seem to eat this stuff up ok, but some of the issues
>> we encounter
>> 1. Customers with SIP CPE where a high volume of SIP trash causes the
>> CPE to lock
>> 2. Customers running Asterisk implementations getting cracked and
>> owned
>>
>> Cheers,
>> Peter
>>
>> On 26/11/2010, at 1:32 PM, Colin wrote:
>>
>>> Tonight i'm seeing hundreds of register attempts per second to one of
>>> my SBC's from an IP in china 61.142.250.96.
>>>
>>> the From: and to: line is always one of these 2 below.
>>>
>>> \"118\"<<a moz-do-not-send="true" href="sip:118@my">sip:118@my</a> SBC IP>; source port 5063
>>> \"qwerty\"<<a moz-do-not-send="true" href="sip:qwerty@my">sip:qwerty@my</a> SBC IP>; source port 5067
>>>
>>>
>>>
>>> user-agent: friendly-scanner is always.
>>>
>>> Looks like sipvicious default user agent. Anyone seen a register flood
>>> like this before?
>>>
>>>
>>>
>>> Colin
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> VoiceOps mailing list
>>> <a moz-do-not-send="true" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><<a moz-do-not-send="true" href="mailto:VoiceOps@voiceops.org">mailto:VoiceOps@voiceops.org</a>>
>>> <a moz-do-not-send="true" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
>>
>> _______________________________________________
>> VoiceOps mailing list
>> <a moz-do-not-send="true" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><<a moz-do-not-send="true" href="mailto:VoiceOps@voiceops.org">mailto:VoiceOps@voiceops.org</a>>
>> <a moz-do-not-send="true" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
>
> _______________________________________________
> VoiceOps mailing list
> <a moz-do-not-send="true" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><<a moz-do-not-send="true" href="mailto:VoiceOps@voiceops.org">mailto:VoiceOps@voiceops.org</a>>
> <a moz-do-not-send="true" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
_______________________________________________
VoiceOps mailing list
<a moz-do-not-send="true" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><<a moz-do-not-send="true" href="mailto:VoiceOps@voiceops.org">mailto:VoiceOps@voiceops.org</a>>
<a moz-do-not-send="true" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
_______________________________________________
VoiceOps mailing list
<a moz-do-not-send="true" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><<a moz-do-not-send="true" href="mailto:VoiceOps@voiceops.org">mailto:VoiceOps@voiceops.org</a>>
<a moz-do-not-send="true" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
</blockquote>
<br>
</blockquote>
</div>
<span><ATT00001..c></span></blockquote></div><br></body></html>