Security - strange Asterisk behaviour

Hi,
Some days ago, one of our operators received a call from extensions 1000, which actually it has not been configured. I went to the logs in order to see what details I could find about this issue. This is what I found:

[2013-01-03 18:56:43] NOTICE[25529] chan_sip.c: Sending fake auth rejection for device 1000sip:1000@aa.aa.aa.aa;tag=426c268c
[2013-01-03 18:56:46] NOTICE[25529] chan_sip.c: Sending fake auth rejection for device 1000sip:1000@aa.aa.aa.aa;tag=0d40b032
[2013-01-03 18:56:46] NOTICE[25529] chan_sip.c: Sending fake auth rejection for device 1000sip:1000@aa.aa.aa.aa;tag=0d40b032
[2013-01-03 18:56:47] NOTICE[25529] chan_sip.c: Sending fake auth rejection for device 1000sip:1000@aa.aa.aa.aa;tag=19446429

The message goes on for about 250 “attempts”.

Note that aa.aa.aa.aa is the server’s public IP address.

After reading some posts related to this:

serverfault.com/questions/394399 … n-asterisk
viewtopic.php?t=78988
viewtopic.php?t=78538

I tried to come along with a similar log message by trying to make calls without registering with the domain. But the message I got is different not only because IP address changes, but because the port is added.

Log messages when trying to call to some number from an unregistered extension (666):

[2013-01-08 14:28:00] NOTICE[25529] chan_sip.c: Sending fake auth rejection for device sip:666@ss.ss.ss.ss:43114;tag=82c0ccf4
[2013-01-08 14:28:00] NOTICE[25529] chan_sip.c: Sending fake auth rejection for device sip:666@ss.ss.ss.ss:43114;tag=82c0ccf4

Being ss.ss.ss.ss the source IP address from where I’m trying to call

I don’t know what is behind this and don’t know how to solve it.

Any clue how to?

Thanks in advance.

B.

You are connected to the internet and don’t have any filters on incoming SIP traffic.

What causes is criminal greed, and there is little you can do about it.

Setting your firewall to only accept port 5060 traffic from IP addresses that you trust, should stop them reaching Asterisk.

You should check that allowguest is set to no, but I think that may need to be true for alwaysauthreject to reject the calls.

The IP address in the messages is not the source one (in earlier versions of Asterisk, it happened to be, but that wasn’t for security purposes).

PS This is the wrong forum for support questions.

Thanks for the reply and osrry about posting in the wrong place (you might move it).

However, in the second type of messages, IT IS the source address as I said in the post.

About the first one, what is the “history” behind it? I mean, what has happened in order to that message to be logged?

I always have had set allowguest=no and alwaysauthreject =yes.

This is a peer support forum. Peers have no more power to move postings than you.

I may be getting mixed up with another issue about rejected calls, where the channel name is logged, and the channel name has changed from using the remote to the local address for anonymous calls.

I suspect, in this case, the caller is simply using your own address in the From: line, as that is more likely to get in and less likely to log anything useful. It seems to be logging the SIP header, rather than low level IP information. Many ITSPs require the domain in the From to be their address.

I think there have been calls to log the source IP address, to make it easier to use fail2ban, but you would have an unusual environment if you couln’t restrict port 5060 to a very few external address ranges.

The port number is included because it is not 5060.

I’ll be more restrictive with firewall rules and allow only known IP address to come in through 5060. However, I don’t understand what you mean when you say:

"…Many ITSPs require the domain in the From to be their address.

I think there have been calls to log the source IP address, to make it easier to use fail2ban,…"

If as you said, the caller (attacker?) changed the From: line from his address to my server address, how would the response get back to him?

Last sentence, about fail2ban, what is the point there?

Thank you!

The reply gets back based on the Contact header and Via headers, not the From: header, although sometimes one has to simply use the source IP address, because of broken NAT configurations.

Many ITSPs require one to set:

host=itsp.example.com
fromdomain=itsp.example.com
fromuser=…

Isn’t it fool to log From: header instead of Contact or Via if that is what is used for replying?

Why is this not changed?

The From header is what is used to match the sip.conf section name (for user type invites and all registers).

One suspects that identifying attackers was not the primary objective when this was coded, and no-one has submitted a community originated patch to change it. Note changes cannot be done retrospectively when, like this, they change observable behaviour. Any change would not be before version 12.

I suspect the message was designed to help solve problems with misconfigured friendly systems.

Note that fail2ban uses the source (layer 3) IP address. If you used any of the headers for that purpose, an attacker would make sure that there was a proxy in one direction, but not the other.

(I think there are some subtleties in the handling of Via that I haven’t fully considered.)

“Note that fail2ban uses the source (layer 3) IP address. If you used any of the headers for that purpose, an attacker would make sure that there was a proxy in one direction, but not the other.”

What puposes? What I use is the filters that fail2ban uses (regex matching against Asterisk log). Could you expand your explanation on this? :smile:

fail2ban creates temporary firewall rules. The firewall doesn’t work on the basis of the contents of the application layer data, but rather on the network layer (layer 3) for the host address and the transport layer, for the port number.

Thus, for fail2ban to successfully rate limit the attacks (and all it does is rate limit them, not stop them), it needs to know the address that appears in the network layer headers, not any of the addresses that are conveyed by the SIP protocol.

On Asterisk 11 at least, if you add to logger.conf:

then you will see the following type of message in the security log, which you can use with fail2ban:

SECURITY[2853] res_security_log.c: SecurityEvent="InvalidAccountID",EventTV="1357637305-525226",Severity="Error",Service="SIP",EventVersion="1",AccountID="2703641477",SessionID="0xb4ed0b3c",LocalAddress="IPV4/UDP/xx.xx.xx.xx/5060",RemoteAddress="IPV4/UDP/94.249.188.145/5131"
Regards