[VoiceOps] Strange register attack

[Peter Childs]

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