Hacking attempts?

At Nerd Vittles, we’ve been wrestling with VoIP firewall approaches for more than 5 years. In the spirit of cooperation, let me offer a few comments about what we’ve learned in hopes that it will provide a safer VoIP computing environment for all of us.

Blacklists are better than nothing, but not my much. The reason is that the bad guys can jump on an IP-spoofing VPN virtually anywhere in the world and avoid any blacklist you can come up with.

A firewall that doesn’t protect all of your server resources is better than nothing, but not by much. Protecting UDP 5060 and leaving TCP 80 or 22 exposed is basically a waste of computing resources. The same bad guy trying to break in on port 5060 will be testing the vulnerabilities of ports 80 and 22 as well.

The more distance you can put between your firewall application and your VoIP application, the safer you will be. If a firewall failure compromises your VoIP application or your server, that’s not desirable. If a VoIP application failure compromises your firewall or your server, that’s obviously not desirable either. IPtables runs as an independent application with hooks to the Linux kernel for a reason. It requires root permissions for any changes… for a reason. Separation! VoIP (and other) applications should never be run with root permissions. When that operational separation is short-circuited or compromised, you’re asking for trouble. I don’t know whether that’s the case with the new FreePBX firewall, but I suspect it’s a problem based upon the fact that a server was compromised through a FreePBX firewall vulnerability and the intruder ended up with root access. Perhaps Rob can better explain how these pieces fit together and what led to a root access compromise when FreePBX presumably runs with asterisk user permissions only.

The closest you can get to a safe computing environment is a firewall that whitelists the IP addresses of only the good guys and keeps everybody else out. Good Guys means you, your users, and trusted providers. For everybody else including those who travel and those with dynamic IP addresses, their access should be handled using a VPN or tools that supplement (on a temporary basis) the access granted by your firewall. Any VPN is probably better than no VPN. Temporary access can be accomplished easily using a product such as PortKnocker with randomized ports to gain access. PortKnocker works on all computer platforms as well as on iOS and Android devices.

1 Like

I also have being building iptables for many years, my few of points that can “getya” if not considered

Things to never use:-

ssh on port 22 (just plain dumb)
voip signalling on 50** (just plain dumb)
http on 80

Things to filter:-
rewrite http to https, provide a legitimate cert on it.
port scanners/flooders, they always get dumped.
Any service that you don’t fully trust.

If you have fail2ban properly configured, then enable the stock jails to apache-nohome and apache no-script . . . These guys are probing you . . . they can derivatively extract Elastix/PIAF/Schmooze/ . . . signatures ( along with the older phpmyadmin/recordings/blah-blah) just look at your current logs.

Identify the network the attack vector comes from, denying 4000+ addresses in a network in PSNET for example is dumb, tomorrow there will be 4001+, unless you have clients likely in Gaza, just deny all those PS networks. (be careful networks like with Comcast or Apple :wink: but Amazon/OVH/tisacali/databank etc. . . are all fair game.)