Strange register attack
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
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 https://puck.nether.net/mailman/listinfo/voiceops
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> 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 https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
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> 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 https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list 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
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> 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 https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list 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
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Are there any other creative blocking strategies? I'll implement the User-Agent idea immediately. Duh. Hadn't even occurred to me. - Darren From: anorexicpoodle <anorexicpoodle at gmail.com<mailto:anorexicpoodle at gmail.com>> Date: Thu, 25 Nov 2010 22:38:34 -0800 To: Lee Riemer <lriemer at bestline.net<mailto:lriemer at bestline.net>> Cc: "VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>" <VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>> Subject: Re: [VoiceOps] Strange register attack 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
An HTML attachment was scrubbed... URL: <https://puck.nether.net/pipermail/voiceops/attachments/20101126/e2089de1/att...>
On 11/26/2010 9:26 AM, 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
As an FYI, that is a sipvicious scan against your machine. I've seen something to the tune of an 1800% increase in these scans beginning on Halloween of this year (www.infiltrated.net/voipabuse/logs/) and I try to keep track of what is going on. As long as your devices are on the 'net, you will see the debris. Not much you can do other than try blocking either entire netblocks or individual hosts. While I've had honeypots up tracking what it is these guys do, it is becoming increasingly difficult due to the mass amounts of scans. I have a theory that about one or two dozen groups have created a distributed SIP scanning method as when I see one attacker plop up from one netblock, about 1/2 dozen follow suit immediately after. My view is that they're sending multiple scans out in the event that if one is detected and blocked, the others will pick up and continue on. Attacker1 --> scans --> 100-200 Attacker2 --> scans --> 100-200 Attacker1 is detected and blocked when it reaches say extension 150 Attacker3 pops up and scans 151 - 200 I see these come through now with some pretty specific targets that make little sense at first, but when I parse out and analyze the logs, I come to what I concluded above. For those who've read about the VoIP Abuse Project or perhaps have heard the TUC conference I was on, there is a lot more sophistication going on right now. As a test, I changed the passwords of about 100 honeypot accounts I have on the net, within 2-3 hours, they had re-established connections to try to place calls through. From what I see, two distinct attacks: 1st, enumeration (someone tries to find an account) 2nd, when an account is found a completely different host sends calls. The individual's IP SENDING the call NEVER (ever, ever, ever) is on any bruteforcing log. I truly believe the individual sending the calls or at least trying to is an actual person and not some script. I base this on the fact of the timing parameters involved with dial plan tinkering. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E
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> 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 https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list 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
VoiceOps mailing list 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
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
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
An HTML attachment was scrubbed... URL: <https://puck.nether.net/pipermail/voiceops/attachments/20101126/add2eeb3/att...>
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-rou...> 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
Greetings, On Fri, 26 Nov 2010, Christian Pena 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
Uh???? 1/8 is an allocated network now. It would be bad form to be pumping traffic toward their network as if it were a garbage pile or /dev/null. Please be a good net citizen and pump black hole traffic toward a non-routable address like one from RFC1918 or a non-existant host on your own LAN. Here was IANA's announcement of the 1/8 address space: -----Original Message----- From: Leo Vegoda [mailto:leo.vegoda at icann.org] Sent: Thursday, January 21, 2010 6:37 PM To: Leo Vegoda Subject: 1/8 and 27/8 allocated to APNIC Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in January 2010: 1/8 and 27/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. The IANA free pool contains 24 unallocated unicast IPv4 /8s. Regards, Leo Vegoda Number Resources Manager, IANA ICANN ***************************************************************** Thank You, --- Jay Nugent () ascii ribbon campaign in /\ support of plain text e-mail Train how you will Operate, and you will Operate how you were Trained. +------------------------------------------------------------------------+ | Jay Nugent jjn at nuge.com (734)484-5105 (734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com] | | Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller | | ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring | | Web-Pegasus [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts| +------------------------------------------------------------------------+ 11:01pm up 80 days, 8:28, 3 users, load average: 0.03, 0.03, 0.06
On 27 November 2010 14:07, Jay Nugent <jjn at nuge.com> wrote:
Greetings,
On Fri, 26 Nov 2010, Christian Pena 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
? Uh???? ?1/8 is an allocated network now. ?It would be bad form to be pumping traffic toward their network as if it were a garbage pile or /dev/null. ? Please be a good net citizen and pump black hole traffic toward a non-routable address like one from RFC1918 or a non-existant host on your own LAN.
I spoke to one of the researchers that analyzed the data from the test advertisements of 1/8 by APNIC. 1.1.1.1 got 11 mbit/s of RTP thanks to people using Friendly scanner. "The number you have dialed is disconnected or not in service" or words to that effect. -- Craig Askings Network Engineer | Over the Wire Pty Ltd craig at overthewire.com.au | www.overthewire.com.au Phone: 07 3847 9292 | Fax: 07 3847 9696 | Mobile: 0404 019 365
Also, make sure you have a proper DDoS config. -Victor On Nov 27, 2010, at 1:53 AM, 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
If you don't mind sending back a failure response, then you can instead add a route for sip:0.0.0.0 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). -hadriel On Nov 26, 2010, at 7:53 PM, Christian Pena 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<mailto:voiceops-bounces at voiceops.org> [voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>] On Behalf Of anorexicpoodle [anorexicpoodle at gmail.com<mailto:anorexicpoodle at gmail.com>] Sent: Saturday, 27 November 2010 7:15 AM To: Christian Pena Cc: voiceops at voiceops.org<mailto: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><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><mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto: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><mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org<mailto: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><mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <ATT00001..c>
Hello, I run a little IP PBX on Linux in my home with a public IP on a cheap DSL line and often I see this kind of "attack". After having the fail2ban blocked them at firewall level, they still use several KB/s of my slow Internet connection and this it really upsetting me. I end writing to the abuse department of the provider hosting the server and after one or two days, the flow stops. If you have only few hosts sending probe, make them stop, the world will be a better place... For now I have dealed with hosting from Europe and US, never found someone from china... maybe they haven't an abuse@ email address. I never had to setup a "fight back" strategy, but I think it will acceptable to over flow the host sending probes with hundred of megabits of UDP packets (with a clear payload). Leandro 2010/11/26 Peter Childs <PChilds at internode.com.au>
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 https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (13)
-
anorexicpoodle＠gmail.com -
cpena＠ststelecom.com -
craig＠overthewire.com.au -
d＠d-man.org -
HKaplan＠acmepacket.com -
jjn＠nuge.com -
ldardini＠gmail.com -
lriemer＠bestline.net -
PChilds＠internode.com.au -
richard.barnes＠gmail.com -
sil＠infiltrated.net -
victor.pascual.avila＠gmail.com -
zavoid＠gmail.com