The Problem
When making audio calls using SIP the phone rings but when it is answered there is only one way audio or no way audio.
What Cause One Way Audio
The cause of one way audio is a combination of NAT and STUN (which we’ll come onto later). Let’s talk about NAT first.
Full article here:
One Way Audio SIP Fix (Think Like A Computer)
This tip was posted by user “infotek” on the FreePBX site but applies to all software PBX systems that use the iptables firewall. “infotek” wrote:
By default the SipVicious scanner uses the ua : “friendly-scanner”. To block this ua, you can have iptables search the packet for that text.
add the following line to /etc/sysconfig/iptables
-A INPUT -p udp -m udp –dport 5060 -m string –string “friendly-scanner” –algo bm –to 500 -j DROP
Now the thing to keep in mind about this is that it only works if you know the string that will be sent as the user agent, and some hackers using SipVicious may take the trouble to change that default string, but some protection is better than none. However this same technique can be used to block any attack that constantly sends the same string as the user agent, if you know what that string contains.
For those that use Webmin to manage iptables, here are the settings to use. This should come BEFORE any other rules applicable to port 5060 – I made it the very first rule on the page “Incoming packets (INPUT) – Only applies to packets addressed to this host“:
Rule comment: Stop SipVicious
Action to take: Drop
Network protocol: Equals UDP
Destination TCP or UDP port: Equals Port(s) 5060
Additional IPtables modules: string
Additional parameters: –string “friendly-scanner” –algo bm –to 500
All other settings on the Webmin “Add Rule” page should be left at the default value (usually <ignored>).
To stop the hackers clever enough to change the default user agent string, consider also using this technique.
One problem that some VoIP users are experiencing these days is that they have trouble connecting to their home Asterisk, FreeSWITCH, YATE, or other software PBX server, but only when using certain ISP’s. One suspicion is that certain ISP’s that offer their own VoIP or traditional landline service attempt to mess with packets using the common SIP port 5060, hoping customers will think that VoIP is unreliable and will subscribe to the company’s overpriced offering instead (see this thread at BroadbandReports.com).
There are various ways to enable an alternate SIP port on the server (in addition to the usual port 5060) but if you are using Webmin to manage your firewall, here’s an easy way, in just three steps:
Step 1:
If you use Webmin to manage your firewall, then you already know how to get to the Linux Firewall page. So go there and select the Network Address Translation (nat) table in the dropdown at the top of the page. Then when the page changes, click the topmost Add Rule button (in the Packets before routing (PREROUTING) section):
Step 2:
Now you should see this page. The items you need to change are indicated by the red ovals. The Destination TCP or UDP port is set to 7654 in this example, but don’t use that. Pick your own unique port; just make sure that it’s not used by anything else on the server already. And yes, you really do put the alternate SIP port you want to use in the Destination setting; it may not make intuitive sense but that’s just how it is. Avoid using ports in the range 10000 through 20000 because those are used for RTP traffic, and avoid ports below 1024 because those are protected ports that are reserved by the system. There are also other ports you should avoid (those used by other software on your system) but if you don’t know how to find ports in use on your system, a bit of time with a search engine will lead you to several pages that show you how to detect already active ports. It can vary a bit depending on your operating system, and it’s beyond the scope of this article.
SIP traffic is UDP only, not TCP (there may be rare exceptions but most software PBX’s use UDP by default). If by some very odd chance you are using TCP for SIP traffic (why?!?) then you will need to specify that under the Network Protocol item. Also, note that the incoming interface is set to eth0 in this example – Webmin will usually show the correct one by default, but you want to select the interface used by incoming SIP traffic if you happen to have more than one. Don’t forget to click Save when you’re finished.
Step 3:
After you have saved the page you should be back at the page you came from, and it should now show your new forwarding rule. If it does, just click Apply Configuration at the bottom of the page to make it active:
One other thing you might need to to is add a rule on the main Linux Firewall page allowing incoming traffic on your selected alternate port, if you have a restrictive firewall that blocks most traffic by default. Try it first without doing that, but if your clients can’t connect on the alternate port, just be aware that you may need to do that before they will be able to connect. For more security, you can enable access to your SIP ports only from specific IP addresses, if your remote clients are at fixed IP addresses.
Now you should be able to change the port number on your SIP endpoints from the default 5060 to your alternate port. Of course I can’t guarantee it will always work, but if you try it and suddenly find that your SIP connections become far more reliable, you might want to leave a comment, and mention the ISP that you suspect might be messing with SIP traffic.
By the way, if you are NOT using Webmin to manage your firewall, and have iptables installed, then all you should need to do is enter these two lines from a command prompt (replace 7654 with your chosen alternate port). But I strongly caution you NOT to do this if you are using Webmin to manage your firewall:
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 7654 -j REDIRECT --to-ports 5060
/etc/init.d/iptables save
If you took the advice in the article, A possible way to thwart SIP hack attempts on your Asterisk (or other) PBX server, please be aware that an important note has been added:
IMPORTANT: Be sure to have a separate iptables rule (higher on the list than those above) that allows connections to port 5060 from devices on your local network. Otherwise, you may find that new extensions that you are adding for the first time will not register with your Asterisk server, or that after a system reboot, none of your local extensions will register!
Please take heed of that note, or you may be one power failure or reboot away from discovering that none of your local extensions are able to register with your PBX server.
If you’ve had the problem of hackers trying to break into your Asterisk server, you probably know that you can use tools like Fail2ban to at least slow them down. But why let them know you even have an Asterisk server in the first place? Maybe you need to leave port 5060 open so that remote users (not on your local network) can connect to the server, but that doesn’t mean that you have to advertise to the bad guys that you might have something of interest. With that in mind, we direct your attention to this post in the DSLReports VoIP forum:
The Linux netfilter/iptables firewall is capable of stopping these attacks before they even start.
At a bare minimum, this stops 99% of the attacks when added to your iptables ruleset:
-A INPUT -p udp --dport 5060 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p udp --dport 5060 -m string --string "REGISTER sip:your.pbx.dns.name" --algo bm -j ACCEPT
-A INPUT -p udp --dport 5060 -m string --string "REGISTER sip:" --algo bm -j DROP
-A INPUT -p udp --dport 5060 -m string --string "OPTIONS sip:" --algo bm -j DROP
-A INPUT -p udp --dport 5060 -j ACCEPT
To understand how this works, read the original post by DSLReports user espaeth.
For another line of defense against such attacks, see the article Stop SOME SipVicious attacks from reaching your Asterisk, FreeSwitch, YATE, etc. PBX server.
Recent Comments