[VoiceOps] Strange register attack

Fri Nov 26 20:09:45 EST 2010

If the attacks come from an identifiable set of IP addresses, might it
be more effective to use something like an IP-layer black hole?  E.g.:
<http://packetlife.net/blog/2009/jul/6/remotely-triggered-black-hole-rtbh-routing/>

It requires some creative use of iBGP, but keeps all the work down in
the routers and out of your SIP gear.

--Richard

On Fri, Nov 26, 2010 at 7:53 PM, Christian Pena <cpena at ststelecom.com> wrote:
> 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 sip:1.1.1.1
>
> anorexicpoodle wrote:
>
> 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.
>
> On Sat, 2010-11-27 at 09:38 +1030, Peter Childs wrote:
>
> 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: voiceops-bounces at voiceops.org [voiceops-bounces at voiceops.org] On
> Behalf Of anorexicpoodle [anorexicpoodle at gmail.com]
> Sent: Saturday, 27 November 2010 7:15 AM
> To: Christian Pena
> Cc: voiceops at voiceops.org
> 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"<PChilds at internode.com.au<mailto:PChilds at internode.com.au>>  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
>>> http://tools.ietf.org/html/rfc5635 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\"<sip:118 at my SBC IP>;    source port  5063
>>>> \"qwerty\"<sip:qwerty at my 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
>>>> VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>
>>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>
>>> _______________________________________________
>>> VoiceOps mailing list
>>> VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>
>>> https://puck.nether.net/mailman/listinfo/voiceops
>>
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>
>> https://puck.nether.net/mailman/listinfo/voiceops
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
>
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>