Jump to content

Blocked IPs in "IP Access Control"


DLS

Recommended Posts

Hi,

 

I'm guessing this isn't strictly a SnomONE question, but thought I'd ask it here anyway...

 

I am seeing three blocked IP addresses in the "IP Access Control" section of the SnomONE web console, as follows:

 

108.163.194.149/32 Block (sip)

113.105.167.122/32 Block (sip)

46.165.195.130/32 Block (sip)

 

The Snom ONE is behind a NAT firewall, with all ports blocked apart from 80, 443, 8443, and 4125 which are forwarded to the server running Snom ONE.. None of these are related to our Snom ONE (it uses ports 8080 and 7443).

 

Our trunks are set up as SIP registrations with Entanet and BT. I was kind of assuming that these were outbound connections managed by our firewall, so weren't leaving anything open to the elements as it were.

 

I've tried probing our firewall with ShieldsUP! (grc.com) and it shows only the ports I was expecting as open - any pointers as to how these are getting picked up by the PBX, what they actually are and what other measures I need to put into place to block access attempts?

 

Cheers,

Andrew

Link to comment
Share on other sites

The automatic blocking of IP addresses is not related to the open ports. It is just a logic so that the PBX temporarily blocks traffic from certain sources which failed to authenticate. When sendng traffic out from the PBX to an address, that address is automatically considered valid. So this takes care about the trunk.

 

When doing port forwarding keep in mind this works for TCP, but it does not work for UDP. Keep in mind that the PBX will choose the RTP ports from a port range, and it needs to advertize the port and IP address to the outside phone.

Link to comment
Share on other sites

sounds like someone is trying to login into snom ONE web interface and failing and the ip's are being blocked for that reason.

 

Hi Matt - thanks for your reply. The Snom ONE web interface isn't available outside our local network - it's on port 8080 which isn't open on the firewall, so I don't think it's that.

Link to comment
Share on other sites

The automatic blocking of IP addresses is not related to the open ports. It is just a logic so that the PBX temporarily blocks traffic from certain sources which failed to authenticate. When sendng traffic out from the PBX to an address, that address is automatically considered valid. So this takes care about the trunk.

 

When doing port forwarding keep in mind this works for TCP, but it does not work for UDP. Keep in mind that the PBX will choose the RTP ports from a port range, and it needs to advertize the port and IP address to the outside phone.

 

My curiousity was that the IP addresses that were being blocked should never have got to the PBX, as the only ports forwarded to this server are 80, 443, 8443, and 4125, none of which the PBX service is listening on. They are services on the same server, just not from the Snom ONE service.

 

So if I understand it correctly, somehow connections from these IP addresses have made it to the server, on port 5060 (sip)?

 

Cheers,

Andrew

Link to comment
Share on other sites

No blacklisting also works on the HTTP ports (80 and 443).

 

The PBX isn't on port 80 or 443 - this server has IIS on those ports. The PBX is on 8080 and 7443 neither of which are open on the firewall on our router.

 

I've increased the blacklisting period to 7 days and fortunately haven't had any more intrusions yet, so hopefully they've got bored.

 

Cheers,

Andrew

Link to comment
Share on other sites

The PBX isn't on port 80 or 443 - this server has IIS on those ports. The PBX is on 8080 and 7443 neither of which are open on the firewall on our router.

 

Strange. Sounds like an attack from aliens or what.

 

I've increased the blacklisting period to 7 days and fortunately haven't had any more intrusions yet, so hopefully they've got bored.

 

I am not a big fan of that. The problem is if you accidentially entered the password wrong three times in the web interface, you are screwed. I believe reasonably secure passwords and a one-hour lock out duration are absolutely enough to defend attacks. If you have 8 digits with true 5 bits randomness, this is 40 bits equal to 1,000,000,000,000 combinations and each hour you have three tries, the expectation value for hacking one account would be 300,000,000,000 hours, which is more than 5 million years. For most services that is good enough...

 

Most people make the mistake to choose extension 40 with password 40, and then are surprised that their system got hacked. Thats why we added the password policy and a warning sign next to the account to tell the admin that a user just refused to cooperate on a good password.

Link to comment
Share on other sites

  • 2 months later...

In this specific case, there are all SIP level blocking (most probably, someone is sending too many packets during a short interval)

 

108.163.194.149/32 Block (sip)

113.105.167.122/32 Block (sip)

46.165.195.130/32 Block (sip)

 

Hi,

 

I need help!

 

We are in problem with the Snom 300.

 

The Cisco IPS is blocking the connections with this signature: http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=25999&signatureSubId=0

 

Log IPS:

Drop:

evIdsAlert: eventId=1333636247462315372 vendor=Cisco severity=high

originator:

hostId: ips

appName: sensorApp

appInstanceId: 456

time: Abr 09, 2012 16:43:02 UTC offset=-180 timeZone=GMT-03:00

signature: description=Malformed SIP Packet Denial of Service id=25999 version=S598 type=vulnerability created=20100512

subsigId: 0

sigDetails: Malformed SIP Packet Denial of Service

marsCategory: DoS/NetworkDevice

interfaceGroup: vs0

vlan: 0

participants:

attacker:

addr: "X.X.X.X Local IP Network" locality=OUT

port: 2048

target:

addr: "X.X.X.X - PBX IP" locality=OUT

port: 5060

os: idSource=unknown type=unknown relevance=relevant

actions:

droppedPacket: true

alertDetails: InterfaceAttributes: context="single_vf" physical="Unknown" backplane="GigabitEthernet0/1" ;

riskRatingValue: 95 targetValueRating=medium attackRelevanceRating=relevant

threatRatingValue: 60

interface: GigabitEthernet0/1 context=single_vf physical=Unknown backplane=GigabitEthernet0/1

protocol: udp

 

This only happens with Snom phones because we have other phones from Cisco, and these Policom works perfectly.

Link to comment
Share on other sites

As far as I can see, there was a vulnerability in the Cisco server, so that they added that to the firewall. That does not apply to snom servers. Can you disable the Signature (false alarm)?

 

Also, if you use TLS, then the Cisco server would not have the option to intercept the traffic and the traffic would pass through.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...