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 don’t think that is what is being asked, and chan_sip and chan_pjsip are not actually that different, except that FreePBX prioritises IP over username, whereas chan_sip always prioritises user over IP.
I don’t think the OP is actually interested in source identifiers, but rather the request URI, presumably because attackers don’t bother doing a reverse lookup when constructing their requests. As this is registrations, they may be talking about the address of record in the To header.
I’m not sure, but, if this is about AORs, I have a feeling that chan_pjsip permits AORs to contain both user and domain, whereas I think chan_sip only ever matches on the user part.
Maybe the OP can clarify the request type and which part of the request they are interested in.
I’m assuming that /ucp was supposed to mean /UDP. However, UDP doesn’t convey domain names, so any domain name presence check can only be done on the application level (SIP) data.
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 
)
What does this have to do with accessing the UCP by FQDN only? This sounds like an Apache/iptables thing.
The /ucp is how users get to the user portal on FreePBX.
I worked that out from the OP’s reply.
It sounds like what is needed is to make real service a virtual host and have the fallback, for no Host: header, be an error. How you do that within the FreePBX framework, I’ll leave to others.
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.
https://wiki.freepbx.org/display/FPG/Firewall+Custom+Rules
-A INPUT -m string --algo bm --string "my.domain.com" -j ACCEPT
An example but keep in mind, you need to account for the other firewall rules too so you need to adjust accordingly to jump into the right chain for the existing firewall rule or whatever other rules you want.
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?
The one thing you have to keep in mind is that RTP will 99% not have a FQDN in it. You need to account for this because you could end up blocking RTP.
The HTTP requests may well not be sent with a Host header, so the IP address may not exist as a string in requests.
The original form of an HTTP request was something like:
GET /ucp HTTP/1.0
and I think the current official way is:
GET /ucp HTTP/1.1
Host: your-domain-name
so something issuing basic HTTP requests will not actually be sending domain or IP address.
(It is possible to send the absolute URL on the request line, but that is normally only for proxies. The very original HTTP didn’t, I believe, have the third stanza on the request line.)
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