Flooded inbound calls

Telco

Joined
Oct 4, 2007
Messages
275
Likes
0
Points
0
#1
My system is being flooded by inbound calls from the following:

Source: MichaelJackson
Src Chanel: SIP/66.197.156.197-089659d0

Is there anyway to block this on the elastix?

I have read that this is a worm.

There is no ph# to block, I turned on the anonymous rejection, but I guess because the name shows, it gets thru.
 

Telco

Joined
Oct 4, 2007
Messages
275
Likes
0
Points
0
#2
Sorry here is the image.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#3
You (perhaps all of us) should have a catchall inbound route with no did or cid that sends all calls to the hangup context or perhaps more satisfyingly to michaeljackson@66.197.156.197 (you'll need a custom extension for that) ). (all recognised DID's still will work)

Or deny the culprit host on your firewall,.

Fail2ban might work also, as might adding

alwaysauthreject=yes

to /etc/asterisk/sip_custom.conf

Looks like a new exploit to me, can you post your sip debug output

(sip debug ip 66.197.156.197)

for one of those calls, just for my edification.

technically you should report this to:

network:Abuse-Email:abuse@hostnoc.net
network:Abuse-Phone:+1-570-343-8551

(from the whois of this IP address)
unfortunately nobody gives a damn anymore about who they host and what they allow, so my guess is you will be ignored


dicko
 

Patrick_elx

Joined
Dec 14, 2008
Messages
1,120
Likes
0
Points
0
#4
I'm receiving these calls also since yesterday, it was approximately once per hour.

My catch all has the privacy mode activated then none of these calls reached my extensions.
But since I blocked this ip in iptables.

What is strange is that all these calls are all coming from the same IP. Strange that nobody shut downed this server already...
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#5

Patrick_elx

Joined
Dec 14, 2008
Messages
1,120
Likes
0
Points
0

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#7
Interesting thread, that's why I asked for a SIP debug, I suspect it's a SIP header rewrite and we need to identify the underlying perpetrator.
 

Patrick_elx

Joined
Dec 14, 2008
Messages
1,120
Likes
0
Points
0
#8
dicko said:
Send them to Zapateller
Does zapateller do anything for the caller using a purely SIP URI call?
If it was going through a PSTN link I would assume that it will be considered, but on a SIP link, the SIP header will inform of the answering first then it will just be a tone..

Would congestion not be better in that case?

anyway, this IP is banned.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#9
Are you sure the originator is that 66.197.156.197 and it's not a rewrite?

66.197.156.197 seems to be possibly a lowly apple machine (nmap -vv -p 1-65000 66.197.156.197) somewhere in hillbilly land (sorry Tennessee and South Carolina, but that's where that host is)

[edit]
of course if it doesn't actually come from that ip, one would have to go for a more expansive sip debug.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#10
And Yes congestion would be more adult, I just like messing with knuckle-draggers
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#11
update:

66.197.156.197

seems to have disappeared from "the tubes", (maybe he didn't like us messing with him)
 

Patrick_elx

Joined
Dec 14, 2008
Messages
1,120
Likes
0
Points
0
#12
dicko said:
Are you sure the originator is that 66.197.156.197
No as I'm not flooding my log with sip ip debug normally..
Can we trust the IP info in the channel name SIP/66.197.156.197-08ac6580? or is this one susceptible to spoofing?

Code:
-- Executing [4312297140@from-sip-external:1] NoOp("SIP/66.197.156.197-08ac6580", "Received incoming SIP connection from unknown peer to 4312297140") in new stack
-- Executing [4312297140@from-sip-external:2] Set("SIP/66.197.156.197-08ac6580", "DID=4312297140") in new stack
-- Executing [4312297140@from-sip-external:3] Goto("SIP/66.197.156.197-08ac6580", "s|1") in new stack
If not, is there a way to force to log a sip debug for the invite only of anonymous sip call?
 

Patrick_elx

Joined
Dec 14, 2008
Messages
1,120
Likes
0
Points
0
#13
Thank you for taking the time to contact the BurstNET Abuse Dept.
BurstNET in no way condones any spam related activities, hacking, warez, pirating, or other related abuse on our network.
BurstNET is one of the largest web hosting companies in the world, and unfortunately such activities will occur no matter how much preventive action we take against such.

:angry:
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#14
:) :)

trust nothing! go with the force!
 

Patrick_elx

Joined
Dec 14, 2008
Messages
1,120
Likes
0
Points
0
#15
dicko said:
update:

66.197.156.197

seems to have disappeared from "the tubes", (maybe he didn't like us messing with him)

Another answer... Fast response. Good for them, they are more reactive than I thought.

Thanks for your report. We've received notices about this however as per our policies our client has 24 hours to resolve this issue. As they have both chosen not to do this and due to volume of complaints we've received, this server will be suspended shortly.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#16
See, they don't give a damn!! they don't enforce their "terms of service" and there is no way to get past their mail bots.

Call the phone number and leave a message with a never to be heard voicemail service.

:) :)

[edit]
I thusly redact

a shame it took 4 days (assuming the aussies complained)!!
 

Patrick_elx

Joined
Dec 14, 2008
Messages
1,120
Likes
0
Points
0
#17
but still, is the channel IP reported in the standard verbose asterisk log is the IP of the UDP packets or is it taken from the content of the SIP invite and then easily 'spoofable'?

if the second, is there a way to record the invite packet only of anonymous call without filling the log with all the sip set debug ip?
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#18
1
From the ultimately negotiated invite, I believe, hence the vulnerability

the SIP non RFC

alwaysauthreject=yes

largely fixes one vulnerability, this one seems a little cleverer, and I don't believe it will go away with one host "taken out".

2

Not an easy one, a well constructed grep filter or perhaps at a lower level a ethereal capture might help.

If anyone can be more specific here I would appreciate input.

on tenterhooks, (but always ready to cross swords,)

dicko

FWIW

the host 66.197.156.197 (probably a virtual one hosted as previously identified) aka as jack, Brazilian or otherwise has been "interested" in mysql and VOIP on the internet (according to google) for five years now.
 

Patrick_elx

Joined
Dec 14, 2008
Messages
1,120
Likes
0
Points
0
#19
but I still don't understand the goal of these calls. Is it just spam or does it harvest info for another later attack. If so, why calling many times the same pbx with the same scenario. One call would be enough to collect info.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#20
Me neither, but I have always maintained that these guys, whilst they might be many things, are rarely stupid. The Whirlpool site and others indicate that ip-chains is penetrable by something involved in the exploit, presumably not the IP that was denied by the firewall rule.
 

Members online

No members online now.

Latest posts

Forum statistics

Threads
30,913
Messages
130,917
Members
17,589
Latest member
cristian.saiz
Top