Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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:912@xx.xx.xx.xx>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:53:50] NOTICE[5578] chan_sip.c: Registration from '<sip:912@xx.xx.xx.xx>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:53:55] NOTICE[5578] chan_sip.c: Registration from '<sip:100@xx.xx.xx.xx>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:53:55] NOTICE[5578] chan_sip.c: Registration from '<sip:100@xx.xx.xx.xx>' 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:100@xx.xx.xx.xx>;tag=cb23fe53
[2012-05-29 15:53:57] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device <sip:100@xx.xx.xx.xx>;tag=cb23fe53
[2012-05-29 15:54:02] NOTICE[5578] chan_sip.c: Registration from '<sip:100@xx.xx.xx.xx>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:54:03] NOTICE[5578] chan_sip.c: Registration from '<sip:100@xx.xx.xx.xx>' 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:55435217@xx.xx.xx.xx>' 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:1731687005@xx.xx.xx.xx>' 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:unknown@188.64.49.26>;tag=dEBcOzUysX
[2012-05-30 01:18:58] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;tag=9zUari4Mve
[2012-05-30 01:19:00] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;tag=sOYgI1ItQn
[2012-05-30 01:19:02] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;tag=2EGLTzZSEi
[2012-05-30 01:19:04] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;tag=j0JfZoPcur
[2012-05-30 01:19:06] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;tag=Ra0DFDKggt
[2012-05-30 01:19:08] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;tag=rR7q7aTHEz
[2012-05-30 01:19:10] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;tag=VHUMtOpIvU
[2012-05-30 01:19:12] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;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:

  1. Set up hardware firewall rules as shown below. Here, xx.xx.xx.xx is the IP address of the server, yy.yy.yy.yy is the IP address of our facility, and aa.aa.aa.aa, bb.bb.bb.bb, and cc.cc.cc.cc are 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     |
    +-------+-----------------------------+----------+-----------+--------+-----------------------------+------------------+
  2. 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).
  3. 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:user@mysipprovider.com: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
share|improve this question
    
The way I read the firewall configuration, you shouldn't have any 5060/5061 traffic at all. Somehow I suspect you start with an ALLOW ALL at the beginning that's not shown. But you need to leave 5060/5061 open to your VSP at least so you can receive SIP calls. –  jfalcon Jun 7 '12 at 21:50
    
I agree that I shouldn't have any inbound traffic on 5060/5061. There are no other firewall rules...no ALLOW ALL. I just changed my bindport yesterday and haven't gotten any banned IPs yet, but that's not really unusual. I guess time will tell if that worked or not. I thought that the calls were coming in on ports 10000-20000, which is why I opened those ports to my provider. Our firewall rules are only blocking inbound traffic, so I assumed that's why register => user:pass:user@mysipprovider.com:5060/700 works (since that's outbound). –  Travesty3 Jun 8 '12 at 13:56

4 Answers 4

up vote 0 down vote accepted
+50

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.0 in 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 list xx.xx.xx.xx as a destination IP to block incoming traffic on port 5060.

share|improve this answer
    
Also, as far as I know, you cannot completely disable incoming SIP registrations in Asterisk. Your 3 options are to change the port, unload the SIP channel driver, or firewall port 5060 (which is the recommended option). –  Richard Keller Jun 5 '12 at 13:27
    
The firewall rules have been in place for months, so I don't think it's the established connection. The firewall is a "Standard Hardware Firewall" provided by our server host, SoftLayer. Our server has only one IP address. All occurrences of xx.xx.xx.xx in my question refer to that IP address. I will look into changing the port or unloading the SIP channel driver. Thanks for your help. If I don't get a more solid answer, then I will accept this one. –  Travesty3 Jun 5 '12 at 17:20

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.

share|improve this answer

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.

share|improve this answer
    
I will try that and see what happens. Can we be 100% sure that they're coming in through port 5060? I know my sip.conf says bindport=5060, but I want to make sure that means that these attempts could only possibly be coming in from that port. –  Travesty3 Jun 5 '12 at 17:23

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.

share|improve this answer
    
See the last rule in my firewall list. This should deny all traffic on all ports, except for the rules above it (notice the Action on most rules is permit, and the last one is deny). I don't have any rules that open ports 5060 or 5061. How do I stop my system from listening for SIP registrations? –  Travesty3 Jun 1 '12 at 14:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.