HOWTO: Thwarting SIP Scanners during Set-up

<< < (18/20) > >>

infin8loop:
Quote from: Mango on June 16, 2015, 07:21:13 pm

Better yet, place your device behind a firewall.

There have been reports - very few, but not nonexistant - of scanners finding and attempting to exploit VoIP equipment with port numbers above 6000.  If your VoIP equipment is behind a restricted cone NAT firewall, the firewall will only allow traffic from your service provider to reach your equipment.  For everyone else, there will not be any indication that VoIP hardware even exists.


No doubt excellent advice, but a lot of folks (including me ;)) probably have no idea what that means and are too lazy (including me) to Google it.  I think my port is exposed by a stun server (yeah, go ahead, beat me down for that) since the OBi is behind a router (not expensive) that serves as a firewall of sorts and there are no port forwards setup in the router. The OBi is not registered to either IPKall (not allowed) nor Callcentric (don't want to). I guess I could go figure out the IP addresses for IPKall and Callcentric and put them in the X_AccessList but I'm too lazy.  I'm so lazy I'm surprised I'm even typing this message.  Someone in another post suggested using ports in the 20000 to 65535? range.  I didn't go that extreme because it would have involved typing extra digits (you know that lazy thing).

Is someone going to commandeer my OBi and launch rockets or something? Or will my phone just ring again at 2am if someone finds my port? I have no virtual PBX and am too lazy to go figure that tech out as well.

<serious>But seriously, what are the risks of a hacker taking over the OBi if they find an open SIP port?</serious>

I always enjoy your informative posts and hope you see the hopefully humorous spirit I have while writing this.

I'm no network guru and if you can't tell already, this stuff ceased to be fun for me months ago.  ;D

Mango:
A STUN server does not introduce a security risk.  (But it does add an additional point of failure.)  Your router is a "full cone NAT" type.  This means that even though you didn't set up any port forwards, your router did automatically.  This is why the scanner traffic can reach your ATA.

You mentioned that you're not registered to some of your service providers, and that does make security more tricky - particularly since Callcentric has a great deal of IP addresses.

I think the worst case scenario is that someone figures out how to route calls via your Callcentric account.  As long as you don't keep a very high balance, I wouldn't expect a significant problem.

Ostracus:
Quote from: infin8loop on June 16, 2015, 07:17:50 pm

I would suggest using option 2:
2. Change the (Voice Services)SPn Service->X_UserAgentPort ports for each SPn  to a number not in the 506x range. 

I was hit with a SIP scanner yesterday when the phone started ringing at 2am about every 4 minutes. The incoming number was 7 digits long but was changing.  I had blocks in place for 1 thru 6 digit numbers. I added a block for 7 digit numbers and the phone stopped ringing. However looking at the debug log I have running for the OBi I noticed the log file was unusually large.  Looking closer I noticed the SIP scanner had been beating the OBi to death for quite some time. Bogus INVITEs with incremented phone numbers that didn't ring the phone because they were less than 7 digits. It appears the OBi responded to the bogus INVITEs with one to many "SIP/2.0 503 Service Unavailable" messages. This was filling up the debug log. The incoming phone number wasn't a solid sequential increment but changing upward until it reached 7 digits and the phone rang.  I changed the X_UserAgentPort to outside the 506x range and that stopped the bogus traffic.  In this case port 5061 was the target on SP2 of an OBi110.  The point I'd like to make is, that if they find your open port they might just keep beating on it like they did mine. You won't know it unless the phone rings, but it's a lot of unnecessary traffic.  Just change the port to something that probably won't be scanned/found in the first place.  I updated my IPKall and Callcentric SIP URL forwards to the new port. I also added an email alert on the debug log that will notify me if it sees more than five "SIP/2.0 503 Service Unavailable" messages in an hour.


IPv6 can't get here soon enough. Yes, that's security through obscurity. Next up, port knocking.

Mango:
Why not use security through firewall, which is available today?

curt00:
Quote from: Shale on March 11, 2013, 08:57:16 am


OBi202  with one trusted caller with service 2 being routed to phone line 2; (Voice Services)SP2 Service->X_InboundCallRoute:
{(x.6065556789):aa},{ph2}  [before]

These are both tested to work:
{(x.6065556789):aa},{>17771234567:ph2}  [ Tested and works]
{(x.6065556789):aa},{>('17771234567'):ph2}  [Permits alphanumerics]
[The single quotes are not needed if the ID is all numbers, but will not hurt]



I have OBi202, but I do not have:

{(x.6065556789):aa},{ph2}

I have:

{(‘curt00’):aa},{ph1}

I changed it to:

{(‘curt00’):aa},{>12221234567:ph1}

where 12221234567 is my AuthUserName.  Did I do it right?

Navigation

[0] Message Index

[#] Next page

[*] Previous page