I have my FreePBX system set up and running properly at this point, thanks in part to lots of community posts from here, but I am one of those people that religiously look at my logs to see what kind of intrusion attempts are being made. I have a pfSense firewall running with port 5060 forwarded to the FreePBX box and have the responsive firewall turned on. I am using IP verification for my trunk to voip.ms. I am seeing the random port scanner junk coming through but I am now seeing one or two very dedicated hackers (or bots) that have scanned my IP and found the web addresses that I have proxied and are now trying to authenticate with FQDN’s (i.e. sip:1001@mydomain) instead of just through my fixed IP address. First question is, should I be worried as this is not in my estimation random, but someone actively working at finding a way in. Or… is it easy to scan for webhosts and proxies at an IP to use for SIP scanning? Second question, is there a way to create a rule in pfSense that allows me a direct connection only to voip.ms for inbound calls and to completely wipe out the port scanning junk? I do not have any out of LAN phones connecting to this system and don’t plan to if keeping that secure is a problem.
As kind of an aside, I changed the firewall settings in FreePBX to ban IP’s for a long time to try and dissuade the scanning attempts. Ban time – 86400, Max Retry – 2, Find Time – 6000. I didn’t know if I could punch those to the moon or what but I do have a few that are persistent and stay in the ban list. 3 of which are from the same hosting provider located in Miami but under separate IP’s… 45.*.185.71, 186.101 and 186.98
If your firewall allows everything from your VSP first you can safely move to a different port for UDP before dropping UDP/5060 later but I suggest also moving the transport to TLS which apparently voip.ms supports or at least TCP
If your VSP insists on only UDP/5060 for ip connections then SNAT/PNAT 5060 to your listening port for the VSP’s IP’s or move to registration
as a kind of aside, use a current version of fail2ban, use pyinotify for the backend and enable the recidive jail, and adjust the asterisk jail to reflect your port changes but given the above, it wont be needed too often.
leaks your domain, then the bad guys have you as they ‘drive-by’ the internet, if you use the same domain for SIPS/TLS then that would be a mistake that I think you are seeing the results of, enforcing strict SNI with haproxy would not have leaked that domain in the first place because haproxy answers not your web-server so IP based connections are dropped without that leak.
Any valid domain can be forwarded to your local services using separate ‘front-ends’ so at a second level not using the same domain for SSIP (or other secured services) but completely different but validly certified domains and having haproxy forward your HTTPS/TLS/TCP connections to your insecure ‘back-end’ services which are only now listening on 127.0.0.1:(port_number) which would further protect you similarly.
So you would have your extensions register using TLS transport to [email protected] and connections would be forwarded to your VOIP server with haproxy serving the certs not your webserver or Asterisk’s TLS
I have been doing a lot of reading and Google-Fu and figured out what I was missing… and that is the firewall component I already have, not the firewall in FreePBX. I only have one source that should be allowed in and the rest don’t even need to know I am there. With that said…
From another source (Who actually uses pfSense daily…)
The proper way to stop the script kiddies from finding your FreePBX server while forwarding through pfSense:
Edit your Port Forward
Select “Display Advanced” in the “Source section
Set “Type” to “Single host or alias”
Fill in the IP of your provider in “Address/Mask”
Set From port” & “To port” in “Source port range” to SIP
Being as I have the easiest possible system layout, for my phone system to work, it doesn’t take any kind of workarounds or intense protocol setup. I need a direct line to my trunk provider and nothing else at this point. I have pfSense running on a dedicated box instead of a “consumer grade” router so I have the ability to make the script kiddies pass on by without even knowing I am here. So I told pfSense to allow an inbound connection which is sent directly to my PBX and that is the ONLY one allowed in to that port. Period. If I add softphones down the road, I will give them access with the same rule sets. Everyone else gets told to get lost.
I just verified my logs and in the last 3 hours since making the above changes, my logs have zero intrusion attempts and I have been able to use my phones in and outbound without issue. So that is a serious gain on this issue.
Then all is good, yet you were concerned with domain name leakage and those rules won’t help that, many penetrations are not initially through SIP but through your Web service and if you inadvertently leak your auth with your VSP, then your firewall might not be involved in the later bill.
If pfSense is set up to not rewrite source port numbers and with a reasonably long (e.g. 300 seconds) UDP timeout, forwarding the SIP port should not be necessary, because registration and qualify will keep the NAT association open, and incoming calls will appear as ‘replies’ and pass through.
Interesting @Stewart1 . In my initial setup, I tried to not have port forwarding on at any level and I could not get inbound calls to work at all. Once I had a direct port to the PBX open, it all worked. I have now just allowed a direct connection from the provider IP only and it works fine as well. Can you point me in the right direction as to where to look to confirm settings? Outside of a few items, this is a stock install of pfSense. I have been running it for a few years now but consider myself to be a pretty basic level user since it hasn’t required a lot of tweaking.
I am also using IP authorization instead of user/pass registration as Voip.ms suggested (though I can’t understand why that would be “more secure” according to them). I could not get FreePBX to reconnect if it disconnected without forcing it to register. I have not had that issue with IP authorization. So if you might have suggestions there, would be greatly appreciated.