Hello Mikrotik experts,
I set up a FreePBX (Asterisk) server in my home and opened a 5060 UDP port using my Mikrotik RB951G-2HnD router. Currently, I did not set any firewall filtering rule to secure the 5060 port. Now the problem is when I look into the asterisk log file, I noticed a bunch of unusual activity there. It looks like my server getting random SIP attacks using port 5060. Because of that, my PBX server’s CPU & memory usage always remains high. I know that I can change the default port 5060 to something else but why will not I secure this port and use the default one? It’s easy for everyone to use the default one.
In my asterisk log file, I found thousands of lines like this:
[2022-08-04 22:03:10] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:141@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:61176' (callid: e5f4a479704493e4f7a) - Failed to authenticate
[2022-08-04 22:03:14] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:141@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:61176' (callid: e5f4a479704493e4f7a) - Failed to authenticate
[2022-08-04 22:03:20] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:284@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:53437' (callid: e5f4a614058530e4f7a) - Failed to authenticate
[2022-08-04 22:03:20] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:284@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:53437' (callid: e5f4a614058530e4f7a) - Failed to authenticate
[2022-08-04 22:03:23] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:299@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:54905' (callid: e5f4a895692138e4f7a) - Failed to authenticate
[2022-08-04 22:03:36] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:315@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:50105' (callid: e5f4a487266884e4f7a) - Failed to authenticate
[2022-08-04 22:03:37] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:315@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:50105' (callid: e5f4a487266884e4f7a) - Failed to authenticate
Here,
XXX.XXX.XXX.XXX = My public IP
10.10.10.1 = My local IP gateway
10.10.10.0/24 = My local network IP
10.10.10.111 = My PBX server’s IP
Now, can you guys please help me out to stop this kind of attack? Once I installed FreePBX in a VPS with default port 5060 opened. In that VPS there was no unusual activity in the asterisk log file like this. Definitely, this attack can be prevented by using a firewall rule which I just don’t know how. So if you know, please guide me to prevent this attack.
Not sure what you mean by SIP.
Are you connecting to a SIP provider or are you pretending to be a SIP provider.
A normal home router does not have the capacity to handle attacks, its the ISP that should do this for ddos etc…
Who is connecting to this server.
a. ensure that there is some sort of encryption to join (preferred)
b. ensure its password protected
c. ensure you use a source-address-list for the dst-nat rule, only those you authorize should use it.
the use of source-address list ensures that only those on the list can make it through the firewall rules, and the other benefit is that the port does NOT appear on scans. Without a source address the port will be visible on scans but appear as closed. Better to be invisible.
Recommend if possible that you instruct your authorized users to use a different easy to remember number and if you cant change it on your server then simply do port translation…
add chain=dstnat action=dst-nat in-interface-list=WAN dst-port=55,555 protocol=tcp to=addresses=ServerIP to-ports=5060 src-address-list=Authorized
Where
/ip firewall address list
add address=fixedIP9user1 list=Authorized
add address=fixedIP-userxx list=Authorized
add address=dynamicDNSname-1 list=Authorized
add address=dynamicDNSname-xx list=Authorized.
In other words users come in on port 55,555 and if on the list gain access to your server on port 5060
If a user has a dynamic WANIP, they can easily get FREE dyndns names on the internet and the mikrotik router when you enter the name will automatically resolve it to the IP address.
Take my apologies, I did not clear my scenario with this post.
I run a small size business with 15 employees. 10 of them are delivery personnel so they use mobile data to connect with my PBX server. I’m using a home internet connection with 300 Mbps of bandwidth. I brought a SIP Trunk connection from one of the SIP providers and using this as a call center number.
It’s me and my employees who are using this server. We’ve some office IP telephones and the rest of them are using the Groundwire SIP client app. Definitely, we’re using strong passwords with our extensions. It’s not like hackers managed to gain access to our extensions or something like that. I guess someone who is using scripts that keeps my server busy all the time.
It’s not possible in my case. Because maximum of my users is using mobile data which uses shared IP, not a public one.
Again, most of them are mobile data users. So this will be very complicated in my case.
How can I restrict/limit amount of requests per second on port 5060?
Yes, I’m using fail2ban with my server. But the problem is it blocks my internet gateway IP only after a few seconds it starts.
You can see here: “failed for ‘10.10.10.1:50105’”. Where 10.10.10.1 is my router gateway.
[2022-08-04 22:03:36] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:315@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:50105' (callid: e5f4a487266884e4f7a) - Failed to authenticate
So when it blocks my Internet Gateway only after a few seconds, my server lost internet connection. If I whitelist my entire network 10.10.10.0/24 then I started receiving random SIP registration requests like this.
[2022-08-04 22:03:10] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:141@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:61176' (callid: e5f4a479704493e4f7a) - Failed to authenticate
[2022-08-04 22:03:14] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:141@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:61176' (callid: e5f4a479704493e4f7a) - Failed to authenticate
[2022-08-04 22:03:20] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:284@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:53437' (callid: e5f4a614058530e4f7a) - Failed to authenticate
[2022-08-04 22:03:20] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:284@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:53437' (callid: e5f4a614058530e4f7a) - Failed to authenticate
[2022-08-04 22:03:23] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:299@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:54905' (callid: e5f4a895692138e4f7a) - Failed to authenticate
[2022-08-04 22:03:36] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:315@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:50105' (callid: e5f4a487266884e4f7a) - Failed to authenticate
[2022-08-04 22:03:37] NOTICE[26744]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '<sip:315@XXX.XXX.XXX.XXX>' failed for '10.10.10.1:50105' (callid: e5f4a487266884e4f7a) - Failed to authenticate
The FAIL2BAN probably does not look at the sip:315@**XXX.XXX.XXX.XXX** IP address which contains the real public IP of the attempt.
Not sure if you can tune FAIL2BAN to work on certain fields from your logging in stead of only "failed for ‘10.10.10.1:50105’
It seems you can make some filter “custom” and that is what you need.
I don’t know much about SIP and what exactly its ALG does, but it seems weird that it would change source addresses of all clients. Could it be that you just have some too broad srcnat rule doing that?
I could do that but there are restrictions in my country. I could not use my country's sip connection from any foreign country. So I've to self-host or use any VPS server from my country.
Install fail2ban on freepbx and create custom action called for example mikrotik to make your PBX VM/Server/PI to block IP addresses directly on your mikrotik: https://wiki.mikrotik.com/wiki/Use_Mikrotik_as_Fail2ban_firewall
Whitelist your known ip addresses in fial2ban in ignoreip section.
You also can make a custom Address List in mikrotik - for example called Fail2ban and modify actionban to add that IP addresses in that access list.
Make a firewall input rule → if source address list is Fail2ban - Action DROP.
Here my action ban on few debian/almalinux machines:
root@lb: ~ $ cat /etc/fail2ban/action.d/mikrotik.conf
# Fail2Ban configuration file
#
# Author: Ludwig Markosyan
# Release 09/02/2013
#
# $Version: 1.0 BETA $
#
# Moded: Plamen Vasilev
# Date: 06/08/2022
[Definition]
# Option: actionstart
# Notes.: command executed once at the start of Fail2Ban.
# Values: CMD
#
#actionstart = mikrotik-fail2ban 'ip firewall address-list remove [find list="Fail2Ban"]'
# Option: actionstop
# Notes.: command executed once at the end of Fail2Ban
# Values: CMD
#
#actionstop = mikrotik-fail2ban 'ip firewall address-list remove [find list="Fail2Ban"]'
# Option: actioncheck
# Notes.: command executed once before each actionban command
# Values: CMD
#
actioncheck =
# Option: actionban
# Notes.: command executed when banning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: <ip> IP address
# <failures> number of failures
# <time> unix timestamp of the ban time
# Values: CMD
#
#actionban = mikrotik ":ip firewall filter add action=drop chain=forward dst-address=<ip> comment=AutoFail2ban-<ip>"
actionban = /root/bin/mikrotik-fail2ban 'ip firewall address-list add address=<ip> comment="Blocked by Fail2Ban on <fq-hostname>. Service: <name>" list=Fail2Ban'
/root/bin/mikrotik-fail2ban 'ip firewall connection remove [find where src-address~"<ip>"]'
# Option: actionunban
# Notes.: command executed when unbanning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: <ip> IP address
# <failures> number of failures
# <time> unix timestamp of the ban time
# Values: CMD
#
#actionunban = mikrotik ":ip firewall filter remove [:ip firewall filter find comment=AutoFail2ban-<ip>]"
actionunban = /root/bin/mikrotik-fail2ban 'ip firewall address-list remove [find address=<ip> list=Fail2Ban]'
You can use that if you have another vms on your home network that you have NATed port - for example - mail, http, https etc.
With that you have a centralized firewall system
So if all these packets appear to come from the IP of your Mikrotik 10.10.10.1 there seems to be some (SOURCE) NAT somewhere in the chain on the wrong side.
The packets arriving at the PBX server should have an untouched “Mobile IP” as SOURCE and not 10.10.10.1 for some reason.
For the purpose of NAT handling, it is enough to know that SIP is similar to FTP in terms that one protocol (SIP itself) establishes a "control session" used to exchange information about sockets to be used by another protocol (RTP) for the actual delivery of the payload (in this case, the media streams).
The SIP ALG is yet another "helper" in the firewall, which extracts the information about LAN side socket(s) provided by the actual endpoint host in the incoming SIP packet, prepares a pinhole (tracked connection) to that socket from an available socket on the WAN side, and replaces the socket information in the SIP packet accordingly before sending it out. Since the functionality is triggered by src-nat (masquerade) operation, its scope of work is limited - it only works fine for simple calls and for individual phones on LAN side registered to a PBX or public exchange at the WAN side. And it cannot work at all if SIP messages are encrypted.
So far I haven't seen a SIP ALG as a part of a firewall that would be 100% trouble-free, and for the scenario above (not the OP's one) where they mostly work, provisions at the PBX or public exchange side work equally good. Specialized devices called SBCs (Session Border, not Single Board, Controllers) are a different matter, these are developed by SIP specialists and do far more than ALGs, but they also require far more configuration than just "enable/disable".
A nice approach. I didn't need it myself so far, but I was always thinking of populating the address list by means of sending a a DNS query for something like totallyunlikelyname.nonsensetld to the address to be banned rather than using SSH to issue the /ip firewall address-list add command, and intercepting that DNS query using layer7-protocol rules at the router. The purpose of the whole exercise is to lower the load of the server running fail2ban, and calculating session keys for SSH is definitely a heavier operation than sending a DNS query.