Regarding SIP war-dialers (and I am getting dinged every frickin' night because I had made the mistake of NATing ports inbound for a single day):
(1) I think we can all agree that the use of a "DMZ" with these SOHO routers (e.g. Linksys or D-Link, and these are not real firewalls) should be limited to testing purposes only, such as to validate whether or not certain ports need to be open, or if they appear to be not open. It's akin to allowing "any port / any source" from the Internet. Best practice is to prohibit ALL inbound traffic from the Internet, except that which is expressly required.
(2) A firewall will generally NOT help you if you are allowing and NATing inbound traffic to your ATA. Forwarding purpose-specific ports inbound, will eliminate most firewalls from usefulness, because even application and protocol-aware firewalls will only deep dive the packets for RFC compliance and specifically-defined attack signatures. If the war-dialer's script is making use of the SIP protocol, a SOHO-class firewall offers little protection. You can impose little tricks by getting your listening service to use non-standard TCP/UDP ports - but this bites you in the ***** if legitimate traffic is trying to communicate with you on standard registered "well-known" ports associated with the listening service. For example, if you change your public-facing web server's listening ports to non-standard ports (e.g. ports other than TCP 80 and TCP 443), your site will likely not get the traffic it expects because the users' browsers are configured to hit web sites using their standard ports. If you somehow communicate to you your users that your web server is listening on non-standard ports (e.g. TCP 81 or TCP 444 for SSL), your users would have to manually suffix his URI with the port number to manually override the use of the standard ports (e.g. http://example.com:81 or https://example.com:444). As far as I can tell, there is no realistic way of communicating something like this to all users and all providers with VoIP.
All this to say, if the remote SIP/truck provider/VoIP system "needs" to generate inbound traffic to your ATA (and I contest this), it will likely do so on standard ports - changing the ports (e.g. UDP 5060 and UDP 5061) may not help at all.
My personal experience is this - I use an Obi202 and NO inbound ports are required to be open/ NAT'd to my ATA for the following VoIP providers:
(1) freephoneline.ca
(2) Google Voice
(3) CallCentric
All my services work fine, other than some detailed configs. that I need to figure out to suit my particular purposes. But in general, all inbound and outbound calls work fine with no need to open any inbound ports.
From my packet captures, the ATA makes periodic outbound socket calls to the respective provider, and when an inbound call is perceived, the session is managed via the OUTBOUND socket initiated by the ATA. It almost seems to work like UPnP, but I can't yet confirm this.
So, my (unsolicited) advice would be to NOT "port-forward" to your ATA, or you run the risk of being added to the database of some dammed script kiddy.
By contrast, I see some users here get no joy until they DO port-forward. Obviously, some more analysis is required to get the "right setup for all"
I think that, if we had the time and ability, if we could compile some sort of comparison matrix, starting with:
(1) The make/model ATA we use
(2) The VoIP provider we use
(3) Our ISP (and I doubt we really need this one)
(4) Things don't work until I port forward (yes/no)
Also
(1) I think we can all agree that the use of a "DMZ" with these SOHO routers (e.g. Linksys or D-Link, and these are not real firewalls) should be limited to testing purposes only, such as to validate whether or not certain ports need to be open, or if they appear to be not open. It's akin to allowing "any port / any source" from the Internet. Best practice is to prohibit ALL inbound traffic from the Internet, except that which is expressly required.
(2) A firewall will generally NOT help you if you are allowing and NATing inbound traffic to your ATA. Forwarding purpose-specific ports inbound, will eliminate most firewalls from usefulness, because even application and protocol-aware firewalls will only deep dive the packets for RFC compliance and specifically-defined attack signatures. If the war-dialer's script is making use of the SIP protocol, a SOHO-class firewall offers little protection. You can impose little tricks by getting your listening service to use non-standard TCP/UDP ports - but this bites you in the ***** if legitimate traffic is trying to communicate with you on standard registered "well-known" ports associated with the listening service. For example, if you change your public-facing web server's listening ports to non-standard ports (e.g. ports other than TCP 80 and TCP 443), your site will likely not get the traffic it expects because the users' browsers are configured to hit web sites using their standard ports. If you somehow communicate to you your users that your web server is listening on non-standard ports (e.g. TCP 81 or TCP 444 for SSL), your users would have to manually suffix his URI with the port number to manually override the use of the standard ports (e.g. http://example.com:81 or https://example.com:444). As far as I can tell, there is no realistic way of communicating something like this to all users and all providers with VoIP.
All this to say, if the remote SIP/truck provider/VoIP system "needs" to generate inbound traffic to your ATA (and I contest this), it will likely do so on standard ports - changing the ports (e.g. UDP 5060 and UDP 5061) may not help at all.
My personal experience is this - I use an Obi202 and NO inbound ports are required to be open/ NAT'd to my ATA for the following VoIP providers:
(1) freephoneline.ca
(2) Google Voice
(3) CallCentric
All my services work fine, other than some detailed configs. that I need to figure out to suit my particular purposes. But in general, all inbound and outbound calls work fine with no need to open any inbound ports.
From my packet captures, the ATA makes periodic outbound socket calls to the respective provider, and when an inbound call is perceived, the session is managed via the OUTBOUND socket initiated by the ATA. It almost seems to work like UPnP, but I can't yet confirm this.
So, my (unsolicited) advice would be to NOT "port-forward" to your ATA, or you run the risk of being added to the database of some dammed script kiddy.
By contrast, I see some users here get no joy until they DO port-forward. Obviously, some more analysis is required to get the "right setup for all"
I think that, if we had the time and ability, if we could compile some sort of comparison matrix, starting with:
(1) The make/model ATA we use
(2) The VoIP provider we use
(3) Our ISP (and I doubt we really need this one)
(4) Things don't work until I port forward (yes/no)
Also
(5) - the make/model of router we use and the firmware version.
... we'd be closer to solving the port-forwarding mystery (do we need it or not?) once and for all.
... we'd be closer to solving the port-forwarding mystery (do we need it or not?) once and for all.
(1) Some folks are using their ATA's in "router mode" rather having them simply participate on the network as a node on the internal subnet. An easy way to know who is doing what - if you have network cable plugged only into you LAN port (or only into your WAN port, in the case of the OBI hardware), then you are NOT in "router mode". If you have a network cable plugged into both the LAN and WAN ports, you are likely in "router mode").
What this could mean is that some people are using the regular router (i.e. their Linksys or D-Link, etc) as their demarc to the ISP, and then using their ATA also as a router, creating yet another layer of NAT and routing.... this could throw a wrench into the works as well.
(2) If we know that our incoming calls are ONLY coming from the IP addresses our VoIP service providers, rather than the IP address of any VoIP user out there, then we should to isolate the inbound traffic to the SP's external IP address/subnet, and create an ACL (firewall rule) to allow SIP inbound traffic ONLY from those source IP addresses. This could function to thwart the War Dialers.... and then we only complain when the SP's change their IP's. I will take that over getting the SIP spam!
What this could mean is that some people are using the regular router (i.e. their Linksys or D-Link, etc) as their demarc to the ISP, and then using their ATA also as a router, creating yet another layer of NAT and routing.... this could throw a wrench into the works as well.
(2) If we know that our incoming calls are ONLY coming from the IP addresses our VoIP service providers, rather than the IP address of any VoIP user out there, then we should to isolate the inbound traffic to the SP's external IP address/subnet, and create an ACL (firewall rule) to allow SIP inbound traffic ONLY from those source IP addresses. This could function to thwart the War Dialers.... and then we only complain when the SP's change their IP's. I will take that over getting the SIP spam!
No comments:
Post a Comment
Note: only a member of this blog may post a comment.