This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Firewall breach via SIP this morning!

OK, I had a MAJOR SIP breach this morning. Let me start with what I have configured on the firewall. I configured SIP settings under the network security section with a server network of the SIP service provider IP and the client network as my internal VoIP network (all VoIP phones and the PBX are located on their own network). SIP seemed to be working fine.

This morning I had a sheriff show up at my door because there was a 911 hang up from our number.  Looking at the PBX logs I saw that there was a very long list of attempts to access our server and in fact there were four attempts to place international calls and one 911 hangup. The fact that this traffic made it to the PBX means it got through the firewall.  I was under the impression that the security I setup would prevent this. The setup was done using version 8.xx from the web site and was upgraded via up2date to 8.103 and then 8.201.

I then decided to see if I could register a soft phone from outside of my VoIP network and in fact I was able to connect to the PBX from the WAN side of the link, right through the firewall.  Next I disabled the SIP configuration in the firewall and re-enabled it re-checking my settings.  Once I had done this, the settings seemed to take and I was no longer able to connect to the PBX from the WAN side. So while that particular vulnerability "seems" to be solved, I am not sure what caused it.  I am also not clear if I was vulnerable from the start or of it occurred at some point after configuration. However, the breach was significant and very unexpected.

Mike


This thread was automatically locked due to age.
Parents
  • I think you may be looking at the SMB version of Switchvox. We are using the free edition of the product, which is very capable, but lacks some of the sophistication of the SMB product.

    I did locate the same RTP range, but given the fact that the media (RTP) sessions go to a single IP address for our provider, and this is the only address specified in the rule, I am not sure how much additional security is gained by the port restriction.  

    Thanks for the additional information, but what concerns me more is how the traffic was forwarded in the first place and are there other boxes out there that are thought to be secure, but in fact are forwarding SIP traffic without their admins knowledge. I suppose my issue may have been some odd collection of upgrades, etc. but it is still disconcerting. I've checked on a couple of occasions today to ensure that inbound SIP traffic is *still* being blocked.

    Mike
  • I hate to re-activate an old thread, but our SIP trunk provider changed the way we connect to them today and that has introduced some new issues. I was hoping that someone might be able to help me figure out a way to make this work.

    Just some quick background. Previously, we connected to a single signaling IP with our provider and they also had a single media IP. We entered both into the SIP server box, but it was not clear that this did anything for the media IP. We put our PBX server IP into the client box. We also enabled strict to ensure that we did not get any unwanted traffic forwarded from the Internet to the PBX. This all seemed to work, but we also needed a packet filter that allowed the PBX to talk to the media IP.

    With today's change, we now have two signaling IPs and (count them) 26 media IPs to deal with. I have created a host definition for each of these IPs and then created a signaling network group and a media network group, placing the right ones in each group. I also created a provider network group, which includes both the signaling and media groups.

    I then put the provider network group into the SIP server box and left the rest of the SIP setup as it was. I modified the packet filter to include the provider network group, to allow communication from the PBX to all of the provider IPs. This was necessary or we dropped these packets. This mostly worked, except when we get an incoming SIP call, we see one of the media IPs being successfully handled, and then in a short time, we see another media IP coming in to the external IP and being dropped. We did not lose audio in either direction, but we seem to have this media IP not being passed.

    So I decided to turn off the strict setting (if you experience problems connecting to your provider, turn off strict...). This seemed to resolve the issue (I think), but now it is possible for a client on the internet to attempt to connect to our PBX. While the PBX passwords are secure, I want to prevent hackers from pushing a bunch of traffic into our network. So I would like to drop all of the traffic that is not from our SIP provider. If I need to enable client access from the Internet, I would rather do that on a case-by-case basis.

    Figuring I could not get the built-in SIP support to do what I wanted, I decided to turn it off and create explicit packet filter and DNAT rules to accomplish what I wanted. So I created a DNAT rule that allowed traffic from the provider network group to "VoIP protocols" (defined by us) (I later changed this to any port) on the PBX. I checked the automatic packet filter rules. I also created an outbound packet filter that allowed the PBX to talk to any port for the provider network group.

    This seemed like a good plan, but I now have one-way audio on my outbound calls. The inbound RTC stream does not appear to be making it to the PBX. Looking at the SIP debug information, I see one of the media IP specified as my peer audio, but it does not seem to get passed. I have spent a ton of time on this, and am not sure how else to make this work. The end goal is to allow communication with the providers 28 hosts, but not allow any other hosts to communicate with the PBX.

    I know this is long. I know there is a lot of information in here, but I could really use some help finding a solution to this issue.  Thank you to anyone willing to stick with me this long.

    Mike
Reply
  • I hate to re-activate an old thread, but our SIP trunk provider changed the way we connect to them today and that has introduced some new issues. I was hoping that someone might be able to help me figure out a way to make this work.

    Just some quick background. Previously, we connected to a single signaling IP with our provider and they also had a single media IP. We entered both into the SIP server box, but it was not clear that this did anything for the media IP. We put our PBX server IP into the client box. We also enabled strict to ensure that we did not get any unwanted traffic forwarded from the Internet to the PBX. This all seemed to work, but we also needed a packet filter that allowed the PBX to talk to the media IP.

    With today's change, we now have two signaling IPs and (count them) 26 media IPs to deal with. I have created a host definition for each of these IPs and then created a signaling network group and a media network group, placing the right ones in each group. I also created a provider network group, which includes both the signaling and media groups.

    I then put the provider network group into the SIP server box and left the rest of the SIP setup as it was. I modified the packet filter to include the provider network group, to allow communication from the PBX to all of the provider IPs. This was necessary or we dropped these packets. This mostly worked, except when we get an incoming SIP call, we see one of the media IPs being successfully handled, and then in a short time, we see another media IP coming in to the external IP and being dropped. We did not lose audio in either direction, but we seem to have this media IP not being passed.

    So I decided to turn off the strict setting (if you experience problems connecting to your provider, turn off strict...). This seemed to resolve the issue (I think), but now it is possible for a client on the internet to attempt to connect to our PBX. While the PBX passwords are secure, I want to prevent hackers from pushing a bunch of traffic into our network. So I would like to drop all of the traffic that is not from our SIP provider. If I need to enable client access from the Internet, I would rather do that on a case-by-case basis.

    Figuring I could not get the built-in SIP support to do what I wanted, I decided to turn it off and create explicit packet filter and DNAT rules to accomplish what I wanted. So I created a DNAT rule that allowed traffic from the provider network group to "VoIP protocols" (defined by us) (I later changed this to any port) on the PBX. I checked the automatic packet filter rules. I also created an outbound packet filter that allowed the PBX to talk to any port for the provider network group.

    This seemed like a good plan, but I now have one-way audio on my outbound calls. The inbound RTC stream does not appear to be making it to the PBX. Looking at the SIP debug information, I see one of the media IP specified as my peer audio, but it does not seem to get passed. I have spent a ton of time on this, and am not sure how else to make this work. The end goal is to allow communication with the providers 28 hosts, but not allow any other hosts to communicate with the PBX.

    I know this is long. I know there is a lot of information in here, but I could really use some help finding a solution to this issue.  Thank you to anyone willing to stick with me this long.

    Mike
Children
No Data