Spoofed caller ID - possible SIP hack attempt?

[gaijin]

Hi, some of my customers are reporting "prank calls" from MeucciSolutions.

I have investigated and a simple google search reveals that this is a fairly common thing.

Has anyone else in the PIAF community had this?

The IP that sent the SIP attack is 93.190.143.10. and I have since blocked this at the firewall for affected customers.

I am not too stressed about it because I have always used secure passwords and very few SIP extensions that are permitted externally on my customer's boxes. And I am slowly getting rid of SIP trunks (removing the need for anon inbound SIP) and moving to IAX where possible. The customers that reported this are ones that I have allowed a anycid/anydid inbound route. (I have since found & implimented a workaround for the original reason I had this route in the first place)

My questions are:

1: Is there any form of common list, a bit like an SMTP RBL, for dodgy SIP hackers?
2: What could the hackers possibly achieve through this kind of port scanning? (are they simply just looking for IPs that respond on port 5060 to target later for a more targeted hacking attempt?)
3: Can I put a dyndns address (FQDN) in the permit field? I have some customers that wish to use remote SIP extensions from thier non static connections.

4: How hard would it be for some guru to write a macro that would "honeypot" an anycid/anydid attempt that then write that IP to a fail2ban, IP table rule or similar?

 

[Snapdragon]

There's some discussion about this company here:
http://pbxinaflash.com/community/threads/unwanted-anonymous-sip-requests.3975/?t=3975
http://www.dslreports.com/forum/r22169632-My-wife-is-ready-to-kill-me-and-the-Phone-Power-phone

 

[cliff]

I received 8 SIP calls today from -
"MeucciSolutions" - SIP/93.190.143.10-b770b820.
They were all disconnected in 17 seconds or less. I haven't had the time to look at my logs yet.

 

[wardmundy]

We got the calls as well. The price you pay for opening the SIP port. All the creep got was Congestion, but I agree. There's got to be a better way. Seems that some of the greenies didn't fare as well.

 

[gaijin]

It's a bit frustrating... These attacks will over time get more and more sophisticated.

It seems as though however easy it is to setup a VOIP server right now... In the future it will be a hell of a lot cheaper to get an expert in to do this... (as long as they get it right)...

 

[wardmundy]

Adding the following line to /etc/sysconfig/iptables above the last COMMIT line will get rid of the creep:

-A INPUT -s 93.190.143.10 -j DROP

Then... service iptables restart

 

[wardmundy]

How hard would it be for some guru to write a macro that would "honeypot" an anycid/anydid attempt that then write that IP to a fail2ban, IP table rule or similar?

Good idea. I'll skip adding it to the TO-DO pile. We should be able to just add another Fail2Ban rule to search for these in the Asterisk log...

[May 13 18:53:57] VERBOSE[6620] logger.c: -- <SIP/93.190.143.10-b7df57d8> Playing 'ss-noservice' (language 'en')

Should look something like this:

VERBOSE.* logger.c: -- .*IP/<HOST>-.* Playing 'ss-noservice' (language '.*')

And it goes in the failregex section as a new line in /etc/fail2ban/filter.d/asterisk.conf. Anyone want to test it and report back? Don't forget to restart Fail2Ban: service fail2ban restart

 

[gaijin]

Anyone want to test it and report back? Don't forget to restart Fail2Ban: service fail2ban restart

As always, you are the man!

I will check on my lab server (1.5 Beta) tonight and report!

 

[WAudette]

Watching this thread too. Similar issues.

WAudette...

 

[jimmyswimmy]

Don't know what everyone else is seeing but I'm not getting pinged all that often. Every 15 minutes or so. The default fail2ban jail setting in /etc/fail2ban/jail.conf requires three fails in 10 or 15 minutes. You'll need to change findtime (and probably bantime) to address this.

 

[wardmundy]

Working on another approach. Stay tuned!

 

[paulvk]

Why not just go to SSL with pre shared key and certificate its going to have to happen eventually

 

[jehowe]

Wouldn't this be a case where disallowing anonymous SIP calls would at least prevent the phones from ringing? Leaving fail2ban to catch the password attacks.

It's amazing how many people this IP/group has affected, including those with ATA's, not just SIP PBX's. Right now all my working installs are IAX and I haven't seen this. But I'll have to look at the Pfsense logs to see who's been knocking on SIP ports.