Missing ip address in log - can't ban with fail2ban

Asterisk Asterisk Support
1

I am looking for ideas how to improve asterisk and fail2ban integration.
I have used this guide for fail2ban setup:
http://www.voip-info.org/wiki/view/Fail2Ban+(with+iptables)+And+Asterisk

This works fine with some kinds of SIP attacks, but the problem is that I can easily simulate SIP attacks which fail2ban cannot possibly ban - because asterisk’s logs don’t mention the ip address where the attack comes from. Maybe some of you have an idea of how to improve the setup:

Two examples of SIP attacks without ip addresses in the logs: (trixbox 2.8.0.3 / asterisk 1.6.0.22)

Example #1 - An X-Lite phone, which is not registered with the domain, trying to make a call through mypbx.com from an extension number which does NOT exist:

full.log shows this entry, but without ip address, so we can’t know where it came from and fail2ban can’t do anything about it:

– Executing [123456@from-sip-external:1] NoOp(“SIP/mypbx.com-00000751”, “Received incoming SIP connection from unknown peer to 123456”) in new stack

messages.log (syslog): has no log entry

Example #2 - An X-Lite phone, which is not registered with the domain, trying to make a call through mypbx.com from an extension number which DOES exist, but with a wrong password:

full.log: has no log entry

messages.log (syslog): shows this entry, but without ip address, so we can’t know where it came from and fail2ban can’t do anything about it:

Aug 7 20:04:27 mypbx asterisk[3686]: NOTICE[32592]: chan_sip.c:18047 in handle_request_invite: Failed to authenticate user sip:567890@mypbx.com;tag=6719422d

Is the any way to get asterisk to show the ip addresses in these cases?
Or any other ideas?

(I know asterisk should not be exposed to the internet, but in this case it is simply nessesary!)

Peter :question:

2

I think alwaysauthreject will help you
asteriskdocs.org/html/apas02.html

Good Luck

3

Not a bad idea regarding security, however it had no effect initially, but after adding both:

alwaysauthreject=yes
allowguest=no

…then I get a notice entry both when using an exsiting and an non-exisitng extension number.

/var/log/messages:

[i]Aug 7 23:32:03 mypbx asterisk[3686]: NOTICE[27307]: chan_sip.c:18047 in handle_request_invite: Failed to authenticate user sip:165411@mypbx.com;tag=1660ec63

Aug 8 00:03:50 mypbx asterisk[3686]: NOTICE[27307]: chan_sip.c:18044 in handle_request_invite: Sending fake auth rejection for user sip:165499@mypbx.com;tag=e6786d03 [/i]

However, it does not solve the main problem - the log does not mention the callers ip address.
And I find that strange, because in other cases the log does mention the ip address, e.g. when the extension no. exists, but the pw is wrong:

Aug 7 23:51:31 mypbx asterisk[3686]: NOTICE[27307]: chan_sip.c:19480 in handle_request_register: Registration from ‘sip:175017@mypbx.com’ failed for ‘86.48.43.192’ - Wrong password

What could it be that keeps the ip address from not showing up?

4

Hmmm, probably going to have to look at code, what version you using? 1.6.0?

5

trixbox 2.8.0.3 / asterisk 1.6.0.22 - as stated in my first post :wink:

6

Are there any news on this problem? Missing ip addresses in logs are quite a serious problem when dealing with intrusion detection and blocking!

To Joel Oliveira, who mailed me directly yesterday through my user account on this forum, but forgot to leave a reply address:

You wrote that you are implementing OSSEC (ossec.net) with Asterisk and have the same problem because Asterisk are not logging the offending ip addresses regarding unregistered SIP calls. Unfortunatly I haven’t found any solution. If you find a solution, please let me know!

Peter :confused:

7

Hi

Are you actually seeing this in the “wild” ? we have many servers running in many countries and we haven’t seen what you mention, EXCEPT when testing on the local network as you say.

Ian

8

I can’t tell if it is happening in the wild, because the intrusion detection systems are made for detecting log enties which contain an ip addresses only. Of cource it would be possible to set up an alert if these entries appear in the logs, but because of the missing ip-address they can’t be blocked anyway.

But even if it is not happening in the wild, it is only a matter of time until someone makes use of this weekness:

I just made some tests with Wireshark, using X-Lite 3.0 as a client, and found that Asterisk replys diffrently when sending an unregistered INVITE depending on if the calling extension number exists or not. Asterisk also replies differently when making unregistered calls from a valid extension number, depending on if the password is correct or not. (The settings “alwaysauthreject=yes” and “allowguest=no” is enabled at the system I am testing on.)

Those two facts means that it is possible to loop through an extension number range and for each number sending an unregistered INVITE with a blank password to any number; and this way finding existing extension numbers. When a valid extension number is found a new loop can be made, making unregistered INVITE’s from that valid extension number to any number, brute-forcing the password. When the password is found, unregistered “free” calls can be made through the system.

All of this is logged by Asterisk, but without a single ip-adresses in the logs, so it can’t be blocked! As far as I see the problem, it could be happening just now on any internet-connected Asterisk system…!

But if the Asterisk code were slightly modified so it added the ip-address to the full-log also for unregistered INVITE’s, it could be easily blocked by fail2ban or any other similar application; just like it is done with registered INVITE’s today.

If anyone knows how to report this weakness in the right place, please do so! Hopefully someone working with Asterisk code daily will analyze it and tell if there is a workaround, or else get the code patched soon.

Peter

9

Hi

Firstly As I said , We have MANY servers world wide being poked on a permanent basis and we nave NEVER seen an entry as you describe. even if the ip address resolves to a dns name the log will show the IP address. This is shown by the fact that once the IP is in iptables, iptables -L will show the resolved name.

It has nothing to-do with trying a password of a registered extension.

I do think you are looking for a problem and bug that doesn’t exist. if it did it would have been exploited a long time ago.
Just get a banning script in place and then check what it sees and misses in the real world, by worriying about whats not happening you are going to miss what is.

even if it did it would be fairly trivial for banning scripts to sort out the IP address by doing a dns lookup.

10

Actually, it does happen “in the wild” a lot! It happens to my Asterisk box on a daily basis (I tried both 1.6. and 1.8 and it happens on both). The attacks are coming from the Internet, NOT the local network.

Does anyone have a solution?

11

Frutza asked (in an email sent through this forum, however it seems a reply address is missing):

“Did you find a solution for the Asterisk / fail2ban issue? Asterisk is indeed not logging IP’s in certain situations, which prevents fail2ban to prevent some attacks.”

No, I did not find any solution, it seems none exists. As soon as my time allows I will see if I can make a proof of concept script which will show that any asterisk installation with fan2bail can be brute force attacked, because of the situations where the ip address is missing in the log. I hope this will give some focus on the problem, so it will be fixed.

Frutza, could you please post the log entries your are getting “from the wild” where the ip address is missing? It would be interesting to see if they are similar to those I posted in august, which was genereated by myself.

Peter

12

Sure, here it is:

I also posted details here:
viewtopic.php?f=1&t=77070

13

The problem has not gotten any attention so far from digium. I was not aware of this thread and made another post - forums.digium.com/viewtopic.php?t=78988 - which provides some more info on the subject.
Basically you should not be using type=friend with your SIP endpoints. This does not block the attack, but it prevents it from ever succeeding.

14

There are two issues discussed here.

The first is that in the past, Asterisk 1.4 and 1.6.2 responded differently to SIP requests from an invalid SIP user than they did to a user configured on the system. This was resolved in Asterisk Security Advisory AST-2011-011, and is corrected in versions 1.4.41.2, 1.6.2.18.2, and 1.8.4.4.

IT IS ABSOLUTELY IMPERATIVE that users of Asterisk 1.4 and 1.6.2 set alwaysauthreject=yes in the general section of sip.conf. Please read the advisory for more details.

The second claim is that Asterisk does not properly log the IP address. This may have been true for certain conditions prior to the security patch, but all current versions of Asterisk report the IP address in registration failures:

This works great with fail2ban and other monitoring/reporting/intrusion-detection systems.

15

roderickm, about the second claim, you are writing “all current versions of Asterisk report the IP address in registration failures”.

But this is actually not what my original post is about.

My observation was that the ip address was logged correctly with registration failures, but was not logged if trying to make a call from a SIP client which is not registered. (My tests were done with X-Lite 3.0 build 41150, leaving “Register with domain an receive incoming calls” unchecked.)

Se example #1 and #2 in the first post in this thread (Aug 7, 2010)

frutza reported at Feb 11, 2001 that such attacks was seen in the wild, and documented it in this thread at Feb 17, 2011.

Has this been fixed so that the log now also shows the ip address of unregistered call attempts, and if so, from which version?

If it has been fixed, a sample from the log showing call attempts for example #1 and #2 in my first post, would be interesting to see.

16

Let’s consolidate the discussion on a single thread. I’ve posted an answer to your question here:

viewtopic.php?t=78988

17

Hey folks, so Ive also been searching the web for a solution to this issue using asterisk 1.8. To review the issue we are talking about, in the asterisk logs we see something like this “chan_sip.c: Sending fake auth rejection for device sip:mysipserversip;tag=seqgxjfs4r” and we dont know the ip of the attacker because our own servers ip is listed instead.

so the patch here issues.asterisk.org/jira/browse … y-tabpanel is not for asterisk 1.8. magically i was able to work this out on my own with asterisk 1.8. i havent tested this yet and this will not cause any damage to your server whatsoever. please understand that i am no pro. do this at your own risk! :-p

so find the source of where your asterisk installation is located. this is the directory where you compiled asterisk. for me it is /usr/src/myasterisk_svn. now find inside the directory called “channels” a file called chan_sip.c. backup the file just in case. cp /usr/src/thedir/channels/chan_sip.c /usr/src/chan_sip.c.old than edit the file.
nano /usr/src/asteriskinstall/channels/chan_sip.c and search for this section.

} else if (sip_cfg.alwaysauthreject) {
res = AUTH_FAKE_AUTH; /* reject with fake authorization request */
}

and change it to look like this

} else if (sip_cfg.alwaysauthreject) {
res = AUTH_FAKE_AUTH; /* reject with fake authorization request */
ast_log(LOG_NOTICE, “heres the mofo %s\n”, get_header(req, “From”));
}

so all we did basicly was we added this line
ast_log(LOG_NOTICE, “heres the mofo %s\n”, get_header(req, “From”));

so now in the log instead of just seeing this

NOTICE[9363] chan_sip.c: Sending fake auth rejection for device 100sip:101@my_servers_ip;tag=2d3e197a

we see something like this instead
NOTICE[9363] chan_sip.c: testing sip:the_mofos_ip;tag=2d3e197a
NOTICE[9363] chan_sip.c: Sending fake auth rejection for device 100sip:101@my_servers_ip;tag=2d3e197a

now recompile asterisk,
make && make install

and then all you need to do is add a new line to the asterisk filter in fail2ban!

hope this was of help to someone! would really love to hear your feedback

edit:
i have now finished my testing and i can confirm it works. heres what i added to chan_sip.c

right under the line

res = AUTH_FAKE_AUTH; /* reject with fake authorization request */

add

ast_log(LOG_NOTICE, “hacking attempt detected ‘%s’\n”, ast_sockaddr_stringify_addr(addr));

so now it looks like

res = AUTH_FAKE_AUTH; /* reject with fake authorization request */
ast_log(LOG_NOTICE, “hacking attempt detected ‘%s’\n”, ast_sockaddr_stringify_addr(addr));

then recompile

make && make install

than in fail2ban edit the jail file

/etc/fail2ban/filter.d/asterisk.conf

and add this line

NOTICE.* .*: hacking attempt detected ‘’

restart your services!!!

18

Why not use Asterisk 10/11 and put, for example, security => security in logger.conf?

Regards.

19

@gavimobile
thanks very much for this info, your fix works great. I implemented it in asterisk-10.7.0 and now the log is displaying the ip address of the ‘fake auth’ intruder, and fail2ban has just banned a mofo who I think has been hammering at my server for ages. Thanks again!

20

Digging up an old thread here but it helped me figure out an issue. Anyone that needs to stop this type of attack and can’t recompile asterisk in the short term…

Install wireshark and run:

on whichver interface is your primary one for SIP. You see a number of connections from the same IP. like:

That is likely your attacker, give it a quick ban and you should see the traffic stop. Just a quick fix for anyone else that gets here through the same search that lead me here.