Bypassing Broken SIP ALG Implementations

The SIP protocol is commonly used for IP telephone communications. Unfortunately it’s notorious for having issues with NAT traversal. Even some major vendors can’t seem to get it right. [Stephen] had this problem with his Cisco WRVS4400N router. After a bit of troubleshooting, he was able to come up with a workaround that others may find useful.

The router had built in SIP ALG functionality, but it just didn’t work. [Stephen] was trying to route SIP traffic from a phone to an Asterisk PBX system behind the router. The router just couldn’t properly handle these packets regardless of whether SIP ALG was enabled or disabled.

[Stephen] first tried to change the SIP port on the external VOIP phone from the default of 5060 to something else. Then he setup port forwarding on the router to the Asterisk box to forward the traffic to the Asterisk system on the original port. This sort of worked. The calls would go through but they would eventually drop after about 20 seconds.

The only thing that [Stephen] could get to work completely was to change the SIP port in Asterisk’s sip.conf file using the “bindport” directive. He changed it to some random unused high port number. Then he setup port forwarding on the router to forward incoming UDP packets on that port to the Asterisk system. This worked fine, but now all of the original phones behind the router stopped working because they were configured to use the default port of 5060.

Rather than re-configure all of the phones in the organization, [Stephen] made one change on the Asterisk system. He setup an iptables rule to forward all incoming traffic on UDP port 5060 to the new SIP port. Now all of the phones are working with minimal changes across the organization. It’s a lot of hassle to go through just because the router couldn’t handle SIP correctly, but it gets the job done.

WiFi and Bluetooth tethering on Android


Many G1/ADP1 owners have been using the app Tetherbot to get internet access on their laptop via USB to the phone’s data connection. The app relied on the Android Debug Bridge to forward ports. It worked, but people wanted a solution better than a SOCKS proxy. The community figured out a way to create a properly NAT’d connection using iptables and then [moussam] rolled them up into easy to use applications. There’s one for setting up a PAN device on Bluetooth and another for adhoc WiFi networking. It requires you to have root on your phone, but hopefully you’ve achieved that and are already running the latest community firmware.

[photo: tnkgrl]

Dismantling the Storm Worm botnet


Zero Day has an interview with German researchers who have found a way to take down the Storm Worm botnet. Their program, Stormfucker, takes advantage of flaws in Storm’s command network: Nodes that are NAT‘d only use a four-byte XOR challenge. Nodes that aren’t NAT’d are only using a trivial 64bit RSA signature. Their solution can clean infected machines and also distribute to other nodes. Unfortunately, installing software without the user’s consent is the exact same behavior as malware. Don’t expect to see this in any sort of widespread use. The researchers did point out that some ISPs have moved to shutting off service for infected customers until their machines are cleaned.