Hi, I am running Asterisk currently and trying to figure out how to limit SIP Registration Requests to devices from the local network.
The problem I am trying to address is that because my SIP ports are open and visible to the outside world I occasionally get brute force hacking attempts using SIP Registration Requests which get picked up by fail2ban and ban those IP addresses. I have set my IP gateway to accept SIP calls only from my ISPs/VSPs. However, this does not stop anyone who is on my VSP network trying to make SIP Registration Requests to my PBX.
So, the question is, is there anyway in Asterisk to limit SIP Registration Requests coming from my local network? I do not have any remote handsets so limiting to devices on my local network will work fine. Ideally, it would be great if there was any way to simply drop SIP Registration Requests from devices that are not in a pre-defined list of IP addresses. BTW, I am running RasPBX so the Asterisk firewall module is not available in my case.
You can use ACLs to block traffic from being accepted for certain peers or endpoints (depends on which SIP channel driver). They are mentioned in the respective sample configuration file.
@jcolp, thanks - my knowledge of Asterisk is pretty basic and I use Freepbx to do my configs. I would appreciate if you can expand or point to relevant config settings as this sounds exactly what I am looking for. Thanks again.
EDIT: just had a look at the doco - are you referring to acl.conf where I should be able to deny all IP addresses apart from the known handsets and sip trunk end points? BTW, I am using chan_sip for all my connections. Thanks.
@david551, will not work in my case, as I have SIP trunks which are necessary to route external calls. What I am trying to do is to prevent SIP Registration Request calls being sent via my SIP trunks.
acl.conf is used to configure global named lists you can use, it is also configured in sip.conf to use them or just to configure the ACLs there using “permit” and “deny”.
Thanks jcolp. I have created acl.conf to permit all my local handsets and SIP trunk peer addresses. Hopefully this will restrict any sip registration requests coming via existing sip trunks. Will keep you posted.
If you like to use contact_* settings, which rely on SIP-Header Field named Contact, I would suggest you turn on pjsip set logger on or use pjsip history to see what is going on and which contacts you like to allow, deny.
Also, my investigations lead to the conclusion that a real tight firewall ruleset is a must have. I found something which looks very promising at this URL:
Thanks very much @_fuz. I take it that contact_acl option is available only on on pjsip? In this case I would need to change my handset definitions to pjsip - not a major issue.
Lin’s Tech Blog is a great resource - many thanks!
Whilst it’s not a Asterisk based solution,I use IPtables on the PI and a little bit of crafty extension naming to restrict connections to my server.
Main elements of my IPtables rules:
Basic INPUT policy is DROP
ACCEPT connections all internal network ranges
ACCEPT UDP connections from my VOIP suppliers on the correct port ranges
ACCEPT a string match on the SIP header so that it matches the start of the naming convention for my extenstions (e,g. Extension is called #I654221, match rule “Contact: <sip:#I”
DROP all connections that start with REGISTER, INVITE or OPTIONS that aren’t initated by the PI
It’s not perfect, but I’ve had no brute force attacks or spoofed connections in over a year.
I should probably look into full ACL control, but as my Asterisk server is in a DMZ, I needed to restrict access for not just the VOIP connectivity.
@Hockeychap, thanks for sharing your config which is very interesting.
A couple of points;
Are you able to post the syntax for item 4 and 5 please?
With item 5, you are dropping all incoming REGISTER, INVITE and OPTIONS packets. With INVITE packet being dropped how do you handle incoming calls? My understanding is that VSPs will be using SIP Invite packets to set up incoming calls? The reason why I am asking this is, in my case I have set my gateway to drop all sip calls unless they are from the VSPs I use and despite this I get occasional SIP Register packet coming through which makes me conclude that it is coming from a device on one of the VSP networks - ie. UDP 5060 being forwarded by the VSP which has a SIP Register header embedded.
With regards to ACLs, I am still not sure whether acl_contact is applicable for chan sip configurations which is what I have.
@Hockeychap, I thought the idea of dropping unwanted packets before they reach Asterisk was a better idea so implemented the iptables rules to drop all SIP Register packets apart from the devices in my local network as per your suggestion. Tested and it all works fine so far.
One more question…when editing the iptables rules I noticed that my default input policy is ACCEPT which was rather strange. I do have fail2ban running as well so I am not sure whether this is a requirement of fail2ban or not. Would you be able to shed some light on this? Or should I change the default input policy to DROP? I haven’t got my head around how fail2ban interfaces with iptables and hence the question.
1: My current suummarised ruleset (which it sounds like you’ve got working anyway)
the first rule allows a connection from Sipgate
the string match rule is the one that allows me to connect internally
As the sip connection has been established , out of sequence registers etc do get dropped
FAIL2BAN - sorry don’t know. I use DROP as my default policy and don’t log the drops. One point to note, make sure you allow all the connections that you want to make from you local net (ie ssh) before turning on DROP, otherwise it’s back to teh console
:INPUT DROP [11152:724090]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [260622:54337133]
-A INPUT -s 217.10.68.151/32 -p udp -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 5060 -m string --string “Contact: <sip:######” --algo bm --to 65535 -j ACCEPT
-A INPUT -p udp -m udp --dport 5060 -m string --string “REGISTER” --algo bm --to 65535 -j DROP
-A INPUT -p udp -m udp --dport 5060 -m string --string “INVITE” --algo bm --to 65535 -j DROP
-A INPUT -p udp -m udp --dport 5060 -m string --string “OPTIONS” --algo bm --to 65535 -j DROP
-A INPUT -i eth0 -p udp -m udp --dport 5060 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 10000:12000 -j ACCEPT
-A INPUT -s -i eth0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
Hi.
fail2ban is operating on your logs. It won’t have the requirement to have default policy ACCEPT, because with DROP it will just work on the entries which made it into the log and just leave all others aside.
Default policy ACCEPT is REALLY NO GOOD IDEA! Please change that and control exactly what is going to be allowed. Otherwise you would have to declare everything you do not want to and this is high risk…
@Hockeychap, thanks for posting your configs - great help.
@_fuz You just confirmed my fears…I am operating behind my gateway so there is a bit of protection (allow only sip traffic from my ISP and voice providers IPs) but I certainly will set INPUT to DROP and only allow the ones I need. I never paid too much attention to iptables settings and I assumed that the default policy for input will be drop but obviously this is not the case - just a bad assumption… You live an learn!
Thanks so much everyone for all your suggestions and help.
