Lately (almost everyday), I have seen SIP registration attempt on our Asterisk SIP servers. The following are asterisk message log.
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9973”<sip:9973@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9975”<sip:9975@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9979”<sip:9979@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9980”<sip:9980@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9983”<sip:9983@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9984”<sip:9984@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9985”<sip:9985@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9986”<sip:9986@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9987”<sip:9987@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9988”<sip:9988@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9989”<sip:9989@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9990”<sip:9990@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9991”<sip:9991@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9992”<sip:9992@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9993”<sip:9993@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9994”<sip:9994@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9995”<sip:9995@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9996”<sip:9996@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“9999”<sip:9999@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
Oct 17 23:52:29 NOTICE[4570] chan_sip.c: Registration from ‘“10000”<sip:10000@XX.99.71.ZZ>’ failed for ‘203.86.167.220’ - Username/auth name mismatch
The rouge hacker are simply using scripts to attempt SIP account registration from 1-10000 and this blog down the asterisk trying to respond to a burst of hundreds of attempt in a seconds.
The filter #8 was in place to block attempt from sip_blacklist. Filter #9 attempt block any UDP packet destined for port 5060-5099 with a 1secs. burst of 25 attempt, by the destination address. The last filter #10 will add rogue hacker to the sip_blacklist. Please note that I intend to use the filter to block sip registration on all asterisk server behind the Mikrotik router. Did I screw up by using the INPUT and OUTPUT chain, as the Rule 8-10 does not work.
8 ;;; Drop SIP brute force registration
chain=input action=drop protocol=udp src-address-list=sip_blacklist dst-port=5060-5099
You have mentioned “make UDP port 5060-5099 to be recognize by the filter rule”, are you not able to update the rule or what seems to be your issue here ?
Will appreciate if you could comment on the 3 filter rules posted earlier, will this stop rouge scripts/server from attempting
to request for a SIP registration with the Asterisk server ?
I’ve changed my rules to indentify and route traffic UDP 5060-5099. But still nothing seems to be filtered. Bytes and packets counter are at 0. You can look at the picture attached.
4 ;;; Checking for VoIP protectin
chain=forward action=jump jump-target=Protect VoIP protocol=udp
dst-port=5060-5099
5 chain=Protect VoIP action=accept protocol=udp dst-port=5060-5099
dst-limit=1,25,dst-address/1m40s
6 chain=Protect VoIP action=add-dst-to-address-list protocol=udp
src-address-list=!Inside-IPs address-list=Detected VoIP Hack
address-list-timeout=4w2d dst-port=5060-5099
7 chain=Protect VoIP action=drop protocol=udp
src-address-list=Detected VoIP Hack dst-port=5060-5099
My 2nd rule seems to work somewhat, but it failed to capture the hacker’s source IP address to the filter list.
Will anyone from Mikrotik care to offer any advise or suggestion on getting a working filter to block rouge SIP registration.
I will offer a PayPal cash bounty of USD100 for your effort if the submission is tested
and proven to filter and block rouge hacker’s SIP registration attempt . You effort will
be rewarded, please PM me directly or post it here
I can’t tell you if it’s to block failed registrations, or failed invites?
All I can tell is that I get several attemps in a short period of time. Look at the log below. Those attempts can be as high as 70 requests per seconds. All I want is to be able to trigger, tag hacker, drop and ban future attempts and hacker if the amount of request is higher than 50 or customizable threshold per second. You can see that they are all coming from the same IP. If you see a better way of doing it, feel free to tell.
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"andrew"sip:andrew@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"hello"sip:hello@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"maggie"sip:maggie@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"monday"sip:monday@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"pascal"sip:pascal@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"Smokey"sip:Smokey@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"baseball"sip:baseball@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"daniel"sip:daniel@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"diamond"sip:diamond@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"joshua"sip:joshua@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"michelle"sip:michelle@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"mike"sip:mike@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"silver"sip:silver@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"1q2w3e"sip:1q2w3e@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"Friends"sip:Friends@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"George"sip:George@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"falcon"sip:falcon@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"fuckyou"sip:fuckyou@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
[Oct 15 23:00:56] NOTICE[16142] chan_sip.c: Registration from ‘"pepper"sip:pepper@192.168.88.20:5060’ failed for ‘184.106.247.188’ - No matching peer found
. Check “SIP blocked” filter list, if src-add = IP found in list. Drop packet.
. If packet from same src- add > 20/50 per seconds burst for 5060 SIP registration (failed) or SIP invites (failed)
block src-address for X secs
. Add src-add to “SIP blocked” filter list.
This is a first stab, it is by no means complete. But we can expand on it to fit your needs. After running this for a weekend I see 8 IP addresses in my list. You need to whitelist your SIP server (sip-auth) just in case, as well as any clients that seem to have problems with this. You then use the forward chain to drop packets in the sip-not-auth address-list:
If this isnt stable enough, I would suggest using a script on the linux box to parse the SIP log and use a port knock to Mikrotik to block them. If you want help doing it this way let me know.
I know this is an old threat, but hopefully someone could help me out here.
I don’t have a problem “catching” the SIP (UDP:5060) hackers, but I do have a problem rejecting them.
What I mean is this:
If I create a single filter rule with the hacker’s IP as source, the counters goes ballistic, so I’m happy that any traffic from that IP will be “cought”. But when trying Drop or Reject (with all its sub options), my external interface is still transmitting full blast (maxing out my outbound bandwidth).
I do understand that you don’t have much control over traffic between your router and the Internet (your firewall only applies to traffic reaching the “inside” of your router), but surely there should be a way to make the hacker “give up” trying?
I redialed the PPPoE connection (to drop all established connections), but after a few seconds the hacker just comes back for more. I ended up creating a queue to limit that IP to 1bps up/down.
It’s been a long day and I’m really tired, perhaps I’m missing the obvious, any help (even if you just shake me awake) would be extremely welcome!
I think the original solution is more efficient, as it is just looking for total connections per second instead of deep inspection. It also would block the new sip attack where an inbound call is placed as part of the scan, and any other types of anonymous 5060 traffic. But if it has no affect I will give this a try.
