The main question:
My Asterisk logs are littered with messages like these:
[2012-05-29 15:53:49] NOTICE[5578] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:53:50] NOTICE[5578] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:53:55] NOTICE[5578] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:53:55] NOTICE[5578] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:53:57] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device <sip:[email protected]>;tag=cb23fe53
[2012-05-29 15:53:57] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device <sip:[email protected]>;tag=cb23fe53
[2012-05-29 15:54:02] NOTICE[5578] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:54:03] NOTICE[5578] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 21:20:36] NOTICE[5578] chan_sip.c: Registration from '"55435217"<sip:[email protected]>' failed for '65.218.221.180' - No matching peer found
[2012-05-29 21:20:36] NOTICE[5578] chan_sip.c: Registration from '"1731687005"<sip:[email protected]>' failed for '65.218.221.180' - No matching peer found
[2012-05-30 01:18:58] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=dEBcOzUysX
[2012-05-30 01:18:58] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=9zUari4Mve
[2012-05-30 01:19:00] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=sOYgI1ItQn
[2012-05-30 01:19:02] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=2EGLTzZSEi
[2012-05-30 01:19:04] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=j0JfZoPcur
[2012-05-30 01:19:06] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=Ra0DFDKggt
[2012-05-30 01:19:08] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=rR7q7aTHEz
[2012-05-30 01:19:10] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=VHUMtOpIvU
[2012-05-30 01:19:12] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=JxZUzBnPMW
I use Asterisk for an automated phone system. The only thing it does is receives incoming calls and executes a Perl script. No outgoing calls, no incoming calls to an actual phone, no phones registered with Asterisk.
It seems like there should be an easy way to block all unauthorized registration attempts, but I have struggled with this for a long time. It seems like there should be a more effective way to prevent these attempts from even getting far enough to reach my Asterisk logs. Some setting I could turn on/off that doesn't allow registration attempts at all or something. Is there any way to do this?
Also, am I correct in assuming that the "Registration from ..." messages are likely people attempting to get access to my Asterisk server (probably to make calls on my account)? And what's the difference between those messages and the "Sending fake auth rejection ..." messages?
Further detail:
I know that the "Registration from ..." lines are intruders attempting to get access to my Asterisk server. With Fail2Ban set up, these IPs are banned after 5 attempts (for some reason, one got 6 attempts, but w/e).
But I have no idea what the "Sending fake auth rejection ..." messages mean or how to stop these potential intrusion attempts. As far as I can tell, they have never been successful (haven't seen any weird charges on my bills or anything).
Here's what I have done:
- Set up hardware firewall rules as shown below. Here,
xx.xx.xx.xxis the IP address of the server,yy.yy.yy.yyis the IP address of our facility, andaa.aa.aa.aa,bb.bb.bb.bb, andcc.cc.cc.ccare the IP addresses that our VoIP provider uses. Theoretically, ports 10000-20000 should only be accessible by those three IPs.+-------+-----------------------------+----------+-----------+--------+-----------------------------+------------------+ | Order | Source Ip | Protocol | Direction | Action | Destination Ip | Destination Port | +-------+-----------------------------+----------+-----------+--------+-----------------------------+------------------+ | 1 | cc.cc.cc.cc/255.255.255.255 | udp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 10000-20000 | | 2 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 80 | | 3 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 2749 | | 4 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 443 | | 5 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 53 | | 6 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 1981 | | 7 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 1991 | | 8 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 2001 | | 9 | yy.yy.yy.yy/255.255.255.255 | udp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 137-138 | | 10 | yy.yy.yy.yy/255.255.255.255 | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 139 | | 11 | yy.yy.yy.yy/255.255.255.255 | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 445 | | 14 | aa.aa.aa.aa/255.255.255.255 | udp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 10000-20000 | | 17 | bb.bb.bb.bb/255.255.255.255 | udp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 10000-20000 | | 18 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 1971 | | 19 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 2739 | | 20 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 1023-1050 | | 21 | any | all | inbound | deny | any on server | 1-65535 | +-------+-----------------------------+----------+-----------+--------+-----------------------------+------------------+ - Set up Fail2Ban. This is sort of working, but it's reactive instead of proactive, and doesn't seem to be blocking everything (like the "Sending fake auth rejection ..." messages).
- Set up rules in sip.conf to deny all except for my VoIP provider. Here is my sip.conf with almost all commented lines removed (to save space). Notice at the bottom is my attempt to deny all except for my VoIP provider:
[general] context=default allowguest=no allowoverlap=no bindport=5060 bindaddr=0.0.0.0 srvlookup=yes
disallow=all allow=g726 allow=ulaw allow=alaw allow=g726aal2 allow=adpcm allow=slin allow=lpc10 allow=speex allow=g726
insecure=invite
alwaysauthreject=yes
;registertimeout=20 registerattempts=0 register => user:pass:[email protected]:5060/700
[mysipprovider] type=peer username=user fromuser=user secret=pass host=sip.mysipprovider.com fromdomain=sip.mysipprovider.com nat=no ;canreinvite=yes qualify=yes context=inbound-mysipprovider disallow=all allow=ulaw allow=alaw allow=gsm insecure=port,invite
deny=0.0.0.0/0.0.0.0 permit=aa.aa.aa.aa/255.255.255.255 permit=bb.bb.bb.bb/255.255.255.255 permit=cc.cc.cc.cc/255.255.255.255
In short you're blocking the wrong port. SIP registration happens on port 5060 (TCP or UDP). The 10000+ ports are going to be for actual RTP bearer traffic, not call setup. Adjust your firewall to block 5060 and 5061 inbound and you should stop seeing the messages. While you're at it you might also consider whether you even want or need your system to be listening for SIP registrations on all interfaces. Remember - you likely connect to your provider, not vice-versa.
What I would do in this situation is set a specific deny rule as the first one on your firewall - blocking traffic on port 5060 to your Asterisk box. If the registrations are still being allowed - then you're going to have to take a closer look at your firewall configuration and determine why it's not working.
Of course - it should be stopped by your catchall deny rule which you have in place currently, but that's obviously failing to catch it.
Hope this helps.
How long have those firewall rules been in place? If you've only just configured them a short while ago, and depending on how you've configured them, the rules might only apply to new connection attempts, but any established connections will still be allowed. Hence, registration attempts coming through on an already-established connection will still be allowed.
You don't provide enough information about the type of firewall you're using, but take a look to see whether you can find a list of established connections on port 5060, and manually drop them. Subsequent new connection attempts should now be blocked according to your firewall rules.
I also see that you have set
bindaddr=0.0.0.0in your Asterisk config file, which causes Asterisk to listen on all available interfaces. How many IP addresses does this server have? If it has more than 1 IP address, then you need to specify them all in your firewall rules, since currently you only listxx.xx.xx.xxas a destination IP to block incoming traffic on port 5060.Registrations apparently can come in on ports 5060/5061. Even if you specify
port=5061
or
bindport=5061
or
bindaddr=0.0.0.0:5061
asterisk still appears to accept registrations on port 5060, and everything still works.