I’m wondering if there is a way to configure the FreePBX firewall to only allow inbound traffic with the FQDN in the request.
For example…
incoming traffic will be allowed for;
PBXdomainname.com/ucp
incoming traffic will be denied for;
111.222.333.444/ucp
Hi,
I am trying to achieve the same for sip registrations.
I came across this post: Securing Asterisk SIP PBX by simple iptables rule checking if the domain is correct – Jan Taczanowski’s tech blog
I tried implementing it alongside the FreePBX Firewall but it doesn’t work. It does when the FreePBX firewall is disabled.
I believe these rules need to be added to some other jail than INPUT.
Unfortunately that was easy to do in chan_sip, but chan_pjsip always has ‘ip’ in it’s list of Endpoint Identifiers
Endpoint Identifier Order . The Default order is as follows:
ip
username
anonymous
header
auth_username
So the bad guys can be sneaky.
I did intend UCP to be in the URL (not UDP).
domain/ucp is the URL to the user control panel.
I would love to have the firewall block the following inbound URL;
http://111.222.333.444/ucp
but allow the following URL through the firewall;
http://domainname.com/ucp
david55 is correct. most hackers do their approach using IP address and don’t bother to do a reverse lookup.
If I could block requests that have an IP address in the URL, and only allow requests that have a domain name in the URL, that should eliminate hackers that approach with an IP address in the URL.
By chance has anyone done this with the FreePBX firewall?
You can put a ‘reverse proxy’ in front of your services that enforces ‘strict SNI’. The proxy answers all connections and can drop IP based connections but forwards proper TLS traffic to the right service. (Personally I use HAProxy, I guess you could call it a ‘firewall’ of sorts 
)
You do it in web server configs. There’s nothing in FreePBX to do this.
web server configs would certainly cover http requests.
I was hoping for a firewall configuration that would cover ALL requests.
Hi Blaze,
This, i think, is getting me very close to what I am trying to do. Thank you!
What I want to do is deny a request that has a IP address in the URL to not be allowed through the firewall.
Say the reverse lookup IP address of the PBX’s FQDN (my.domain.com) is 111.222.333.444, would I write a rule like the following?
-A INPUT -m string --algo bm --string “my.domain.com” -j ACCEPT
-A INPUT -m string --algo bm --string “111.222.333.444” -j DENY
Would these two rules allow a request with my FQDN but deny a request with the FQDN revers lookup IP address?
Given that it is 2023 , perhaps consider insisting on TLS for connections for security and customer trust.
HAProxy set with as many ‘front ends’ for either TCP or HTTP, as you need will efficiently drop IP based connections then check certificates by URL and ultimately redirect approved connections to any number of ‘back ends’ . This it can do much quicker and cheaper than iptables followed by cert checking per service.
Put such a system between the internet and your internal services and have ‘front ends’ for UCP, provisioning, admin, webrtc , sips and anything else.
http traffic is rewriten to https, so custoners can type ‘u.r.l’ or ‘http://u.r.l’’ or ‘https://u.r.l’ and modern browsers will show green and not complain.
Now we find that
‘ucp.my.url’ goes to your UCP docroot
‘my.url/ucp’ can go to the same docroot
‘mysecreturl.com’ can go to your admin docroot (as could 'my.url/admin)
‘mumbojumbo.live’ goes to your provisioning docroot.
All phone stuff is filtered to only pass url based connections through to the asterisk TLS transport.
All certifications are centralized and cron updated automatically (I use acme.sh and a compliant name service over DNS01 so no effing with apache or firewall needed), your web server can remain http only, no rewriting necessary.
keep an eye on your access and error logs of your web server and your fail2ban and asterisk logs as always.
IWFM and you should get an ‘a’ or better at
edit: oops,
more useful
Hi Blaze,
Thats a good thought. I was worried about RTP not having the FQDN in it. I didn’t know if it did or not, now I know.
What about modifying the advanced firewall parameters to only lock down the FQDN requirement for a certain port where the known traffic does indeed use FQDN. See below I added in port 1220 to your original example. Is this a valid entry?
-A INPUT -m string --algo bm --string “my.domain.com:1220” -j ACCEPT
-A INPUT -m string --algo bm --string “111.222.333.444:1220” -j DENY
I believe it should look like this (not sure which jail to put it to when using FreePBX Firewall):
-A INPUT -p tcp --dport 1220 -m string --string “my.domain.com” --algo bm -j ACCEPT
-A INPUT -p tcp --dport 1220 -m string --string “111.222.333.444” --algo bm -j DROP
Thank you kamilk.
Ill give this a test over the weekend.
I appreciate everyone’s help that has contributed on this thread.
I suggest that you are tilting at a windmill that is not the only windmill to concern yourself with ( there are lots of them 
). Think about getting a newer lance and a wider visor
I fought this battle for years as we all seem to be doing here, going my suggested way goes towards new pragma running over old dogma, Pretty well 99.99% of all SIP penetration problems will be rooted at UDP:5060, and many of them originate by previous probes to IP based ‘drive-by’s’ ( not necessarily originally to VOIP as has been suggested here, the bad guys are so far cleverer than us) , so as the answer to “every-time I do that it hurts” is just “Then don’t do that !”
JM2CWAE