RECOMMENDATIONS Auto open knockd ports on UPnP gateway router

[chris_c_]

System: IPBX 13-12 running on Ubuntu 14.04 Trusty.
Just completed a manual set up of IPBX's three randomly generated "port knocker" ports, to allow for remote SIP client registration (for a remote roadwarrior / traveling man softphone extension).

I have a recommendation regarding the auto configuration of said gateway ports.

http://miniupnp.tuxfamily.org/
to install on debian/ubunutu/raspbian (?):

apt-get install miniupnpc

to invoke :

upnpc

(careful... command name is different from package name!!)


Fact is, 99.9% of all hardware gateway routers that IPBX runs behind, have the UPnP feature available and enabled. So a client device (ie pbx server) hiding behind the gateway, on the LAN, can programatically issue a request to the gateway, to map a port on the public IP, to its private LAN IP and port.

So, have the IPX install script call a command line binary, called "miniupnpc", to use UPnP to attempt to automatically open those 3 randomly selected "KNOCK" TCP ports on the gateway router, and forward to the 3 TCP ports on the IP of the IPBX machine.

And while it's at it, to forward the 5060 SIP UDP port to the IPBX server, for the 2 way SIP registration and call traffic.

This new way is superior to the current way, because if any of the ports is already occupied, the script will detect that error condition, via return value from the

upnpc

binary, and retry by selecting another random port, until it succeeds and all 3 random TCP ports are mapped via UPnP.

Worse comes to worse, if the UPnP mappings fail due to UPnP disabled on the gateway router, the script can print out the instructions to tell the admin to manually forward the 3 TCP ports to enable this remote softphone port knock security feature.

Most of the time though it'll just work, and save thousands or even hundreds of thousands of IPBX admins, so much time..

 

[chris_c_]

Following up, the exact command to invoke is :

upnpc -r 5060 udp <knockport1> tcp <knockport2> tcp <knockport3> tcp

This command maps the 3 knock ports, plus the sip port (5060 UDP), to the current machine, which is the IPBX server.

 

[wardmundy]

Thanks, chris_c_. Also managed to get it working with CentOS/Scientific Linux. Here's how to retrofit existing servers:

# Which bit are you? (HINT: x86-64=64-bit anything-else=32-bit)
uname -a
# Execute 1 of the 3 operating system updates below:
# 1. CentOS (64-bit)
yum -y install ftp://rpmfind.net/linux/dag/redhat/el6/en/x86_64/dag/RPMS/miniupnpc-1.5-1.el6.rf.x86_64.rpm
# 2. CentOS (32-bit)
yum -y install ftp://rpmfind.net/linux/dag/redhat/el6/en/i386/dag/RPMS/miniupnpc-1.5-1.el6.rf.i686.rpm
# 3. Ubuntu 14 and Raspberry Pi (all bits)
apt-get install -y miniupnpc
# Decipher your PortKnocker ports
grep sequence /etc/knockd.conf | cut -f 2 -d "="
# Fill in the blanks and execute Chris' command below to activate UPnP on your Incredible PBX server:
upnpc -r 5060 udp <knockport1> tcp <knockport2> tcp <knockport3> tcp

 

[wardmundy]

NEW BUILDS AVAILABLE NOW:

incrediblepbx11-12.1-ubuntu14 now includes UPnP support for PortKnocker and SIP UDP 5060.
incrediblepbx13-12.1-ubuntu14 now includes UPnP support for PortKnocker and SIP UDP 5060.


incrediblepbx11-11.2-centos now includes UPnP support for PortKnocker and SIP UDP 5060.
incrediblepbx11-12.2-centos now includes UPnP support for PortKnocker and SIP UDP 5060.
incrediblepbx13-12.2-centos now includes UPnP support for PortKnocker and SIP UDP 5060.

 

[chris_c_]

Ward thanks for putting out the new release!
The port knocker UPnP ports work great and has worked through all my testing before posting up the info.
However on further testing, port 5060 UDP for SIP by itself may not be enough, since even though the SIP softphone connected OK, it gave me some one-way audio pain.

We'll need to either add a few more ports, or possibly add some code, so that the PBX will dynamically open additional required firewall ports on the fly, to allow a remote port knocker user, who they themselves are also behind their own NAT, to connect successfully, and use full two-way audio and signalling media etc. Specifically digging into RTP port range 10001-20000, google voice 5222, and SIP port range 5060-5082.

The challenging use case , is a remote "road warrior" with softphone, running on laptop or tablet/ipod wifi device, or voip deskphone, behind a NAT WITHOUT ability to open ports with UPnP... typically residential, hotel, fast food, coffee shop, train, airport, public, etc., while the IPBX itself is also behind its own separate NAT, on its own internet connection. Double-NAT as it's called affectionately.

The same network settings, same ports, same softphone app or hardware voip phone, and same network connection profile credentials and settings, should allow the phone to physically go to the same LAN as the IPBX is on, connect and "just work", without any adjustment to the networking settings, or the phone's voip account settings.

** The icing on the cake would be to enable TLS encryption for both SIP call setup, and run SRTP instead of easily eavesdropped RTP phone call content.

 

[wardmundy]

Good points. Routers make a big difference in the one-way audio realm. Most good routers can sort out the RTP stuff, but some don't. Setting the NAT entries in SIP Settings usually works wonders without any additional firewall tinkering. SRTP will be great. Wish I had another 23 hours each day to play.

 

[chris_c_]

Good points. Routers make a big difference in the one-way audio realm. Most good routers can sort out the RTP stuff, but some don't. Setting the NAT entries in SIP Settings usually works wonders without any additional firewall tinkering. SRTP will be great. Wish I had another 23 hours each day to play.

The 2 NAT routers for this test case , are recent. A DD-WRT latest build 27506 running on recent hardware, and latest firmware version Arris (Motorola) NV510 DSL Gateway router.
NAT entries in SIP Settings:

(the external public internet IP)
192.168.2.0 / 24

How about including Sippy B2BUA and Sippy RTPProxy for SIP relaying and RTP relaying, regardless of the hardware nat firewall routers that happen to be in between.
https://github.com/sippy/b2bua
https://github.com/sippy/rtpproxy

pip install git+https://github.com/sippy/b2bua
b2bua_simple -f -n 192.168.1.1

https://github.com/sippy/b2bua/blob/master/documentation/documentation.md

Or, OpenSIPS, it seems to provide protection to asterisk plus nat traversal:
http://www.opensips.org/About/About

"Using OpenSIPS to protect an Asterisk Farm » IP-PBXs are great, but they were created with PBX features in mind. By just configuring a PBX it is not possible to prevent attacks such as SIP flooding, RTP flooding, RTP injection, Fuzzy and Toll fraud. OpenSIPS is an advanced SIP proxy capable to handle low-level parts of SIP. Positioned as an outbound proxy or b2bua, it can protect a farm of PBXs in an effective and affordable way. Learn how!"
OpenSIPS combines with RTPProxy also...

 

[wardmundy]

Our design is basically to block ALL SIP traffic except that coming from authorized users or providers registered on the server's IPtables WhiteList. That keeps ALL the bad guys out. I'm reluctant to add more layers that add more complexity to an already complex system. We've resisted adding Kamailio for the same reason. If you look at the problems others are having with these sorts of implementations, it explains it better than I ever could.

Please feel free to experiment and document your work. We'd be glad to take another look once there is a working model.

 

[chris_c_]

I'll take a look at Sippy B2BUA + RTPproxy, vs. OpenSIPS, and see which one is easier to get going, leaner, and best fits the needs for running on the same server as ipbx.

* Just to be sure how knockd is supposed to work - when a remote road warrior does the successful "3 knocks" - the system is supposed to whitelist their IP in iptables - and from that point, they are supposed to be allowed to register their SIP phone extension in ipbx, from that single IP, for a predetermined length of time - correct?

* Question: what if the road warrior "knocks" successfully over ipv6 on their tmobile or verizon ipv6 phone, and the server is running on a fully enabled ipv4/ipv6 network interface, is the system designed to detect that and put the whitelist entry into ip6tables ?

* I think I found a small bug in the knockd code from reading the log.
Knock at 5:37pm, OK it does the open sesame for your IP by adding an allow entry to iptables.
Knock at 6:15pm, OK it does the open sesame for your IP again by adding a redundant whitelist entry for it.
6:37PM the timeout occurs for the first knock and it deletes the entry from iptables.
7:15PM it deletes the second entry from iptables as that one times out.
Probably better to just "renew" the hour timeout, instead of adding 2 entries for the same IP and deleting them one at a time as their timeouts happen.
* Also, instead of allowing all ports from the knocker's IP, probably best just to allow all relevant ports. SIP, RTP, HTTPS for the ipbx admin gui (HTTP admin gui not allowed on public internet for security reasons/sniffing/session hijacking!), ssh (but the installer script needs to change this to a random port not 22), webmin port, etc.

 

[wardmundy]

The PortKnocker implementation was designed to allow a remote user temporary access. During this period, the user could add a permanent whitelist entry using add-ip or add-fqdn if the user has root permissions. For the traveling dude without root permissions, he/she gets an hour to make calls, check voicemail, etc. Multiple knocks are harmless. They all get wiped out after an hour. That's usually sufficient but obviously could be adjusted with cmd_timeout setting in the config file to meet unique requirements.

Never was designed as a permanent way to gain remote access. iptables-restart also wipes out any currently authorized Knocks.

You'd need to add an extra command in the config file if you want IPv6 support, i.e.

&& same command using ip6tables instead of iptables

More design info here.

 

[Dave Gray]

Dumb question. If you're selectively forwarding those ports to the server running knockd, does this look different in any way whatsoever to an nmap scan? If you can see ports that 'do something funny', well, there aren't that many combinations of 3 ports to try.

IMHO knockd should *only* be running on the outermost firewall, and must be completely invisible to an external scan. If you're forwarding those ports, for instance, to an internal server, and that server is rightly returning connection refused, can I see an extra hop in the TTL returned?

 

[chris_c_]

Good point Dave. I was thinking the same. The topic is discussed and more or less answered here:
http://security.stackexchange.com/questions/40029/how-to-make-nmap-list-an-unfiltered-port
nmap should be tried on a live running ipbx system running behind a hardware residential/commercial gateway/firewall to verify if the knockd ports are easily discoverable with a simple nmap command or script.

 

[Dave Gray]

Yeah. The firewalking technique is exactly what I was thinking of. Looks like it would work to map out the ports, hopefully you wouldn't draw enough attention for someone to try something that intensive on your box.

 

[chris_c_]

Unfortunately hackers are seeking to commit toll fraud. There's a strong financial motivation. They can easily enlist an army of zombie machines to do the firewalking on a million pbx boxes. Eventually break into a sip extension and call their $4.99/minute toll service on your postpaid SIP account.
Ultimately it'd be best to add knockd to your hardware router to eliminate this possibiliy.
DD-WRT router firmware supports adding knockd.

http://www.dd-wrt.com/wiki/index.php/Knockd

 

[wardmundy]

Just did a port scan with 150 ports including the ones we use, and it picked up nothing. Most routers that forward ports do just that. They forward the ports to the destination device which then responds to pings, etc.

 

[Dave Gray]

Ah, but did you do a firewalk scan? The problem is, that when the router forwards the port, it also decrements the TTL field by one. This is used, for example by traceroute to get an ICMP response from each step in a connection which then maps out the connection path. With similar jiggery-pokery you should be able to tell *which hop* is refusing your connection, which would allow a mapping of which ports are being forwarded somewhere.

 

[chris_c_]

Yes ward but while the port is refused by the iptables on the ipbx server, a difference in ttl value for those ports would give away that there was an extra hop needed to reach from the hardware gateway/firewall to the ipbx server, where the TCP packet would be filtered. I say "would" because I haven't found out how to get nmap to display the TTL value for each port, on the console, for the "filtered" (no response) ports. It displays for the "reset" (actively refused) and "open" ports. The TTL is supposed to be present in the XML data returned by nmap however.

 

[jroper]

Hi

Port Knocker is an excellent piece of work, but as you say, there are issues with this method when connecting from broadband over which you don't have control.

The challenging use case , is a remote "road warrior" with softphone, running on laptop or tablet/ipod wifi device, or voip deskphone, behind a NAT WITHOUT ability to open ports with UPnP... typically residential, hotel, fast food, coffee shop, train, airport, public, etc., while the IPBX itself is also behind its own separate NAT, on its own internet connection. Double-NAT as it's called affectionately.

In this instance, I would look at OpenVPN, see http://www.bbc.co.uk/news/technology-33548728 for a very good step by step guide. I set mine up on port TCP 443 as this port is usually open in public networks, and now use it as a matter of course for all public wifi. Setting up the client on Android, IOS and OSX is simple (not tried Windows), and giving the config to users is simply a case of getting them to install the client software, and opening the file you send them.

** The icing on the cake would be to enable TLS encryption for both SIP call setup, and run SRTP instead of easily eavesdropped RTP phone call content.

OpenVPN encrypts as well.

Maybe time to write a script!

DD-WRT, mentioned in this thread, which I highly recommend, can also be configured to be an OpenVPN server

Joe



.

 

[wardmundy]

Ah, but did you do a firewalk scan? The problem is, that when the router forwards the port, it also decrements the TTL field by one. This is used, for example by traceroute to get an ICMP response from each step in a connection which then maps out the connection path. With similar jiggery-pokery you should be able to tell *which hop* is refusing your connection, which would allow a mapping of which ports are being forwarded somewhere.

Great article on firewalk scanning here. Makes the point of why a bundle-of-sticks approach to network security is so important. We have that in spades with the 7-Layer Security Model!

 

[chris_c_]

Great article on firewalk scanning here. Makes the point of why a bundle-of-sticks approach to network security is so important. We have that in spades with the 7-Layer Security Model!

The packetfactory.net domain, for downloading the firewalk tool from, as mentioned in the referenced Irby SANS paper, that domain got taken over by a Thai blogger.
Now find the firewalk tool at packetstormsecurity.com https://packetstormsecurity.com/files/10767/firewalk-0.99.1.tar.gz.html