Fail2ban: False sense of security

Asterisk Asterisk General
1

Just heads up to people deploying fail2ban in order to improve the security of asterisk installs.
This tool is rather useless currently. It only bans IPs who try to register. Most people define their SIP devices/peers as type=friend which means registration is not necessary to initiate calls. Anyone with access to SIP port can send an INVITE and start cracking passwords. More info: viewtopic.php?t=78538

The problem number one is people using type=friend based on an incorrect info from the various online/offline sources including digium’s own.

Problem number two is asterisk does not log enough info for fail2ban to detect anything.
Adding additional regexes to mach will not help without changes in asterisk core.

Update: The problem has already been discussed in these threads:

http://forums.digium.com/viewtopic.php?t=77070

http://forums.asterisk.org/viewtopic.php?t=74947

2

You know your way around the C-language? How about putting together a patch to improve the logged message such that fail2ban can use it?

3

Malcolm,

your attitude shows a fundamental problem with digium’s approach to security.
Your company touts fail2ban as a panacea for security attacks and when shown it does not work you are asking the reporter to write a patch.

I would expect an internal audit of logging of all authentication request as I am sure the REGISTER and INVITE methods are not the only ones which can be used to brute force accounts. My guess is the next attack will be using the SUBSCRIBE method.

Please stop playing whack-a-mole with security and get serious about it.

4

Howdy,

I don’t see much attitude in my response. If you read any from it, I apologize for my word choice, it wasn’t my intention. In your response, I see attitude, more than none. Perhaps I’m mis-reading your comments as you mis-read mine?

You’ve been vocal on the forums lately. As Digium is a company of limited resources (aren’t we all), I’m trying to see if we can convert your enthusiasm into code contributions. Code contributions, more than anything else, help to move Asterisk’s capabilities forward.

Here’s a document, of what we’d like Asterisk to be able to do, to help users mitigate SIP attacks:

wiki.asterisk.org/wiki/display/ … ity+Events

It arose out of many discussions with users of Asterisk.

Sadly, Digium hasn’t been able to put internal resources behind it to move it forward. Sadder still, the community hasn’t taken up the cause to move it forward either. Maybe you’d like to, or maybe someone else reading this thread would like to?

Fail2ban is a great help for many, but it’s hard to declare anything a panacea. Fail2ban is also an encumbrance for Asterisk users, since it requires configuration of things outside of Asterisk, with which the user might not otherwise be familiar. So, beyond any actual limitations that it might have when used with Asterisk, which you’re pointing out here, it imposes further difficulty on the user.

If Digium is, corporately, touting fail2ban as a panacea, please point me to where we might be doing so.

Thanks again for your contributions.

Cheers.

5

Malcolm,

I sincerely appreciate your efforts to reach out to asterisk users, but I am simply disappointed the security is not taken seriously by the asterisk team. The problem is not only writing code. The docs suck, many self-proclaimed “experts” write books or online tutorials proposing configurations which, from security perspective, are simply mind boggling. Digium does not provide any BCPs, so in typical cases the best practices employed by many are a combination of hodge-podge and hearsay, or as David nicely put it - magic incantations.

[quote]Code contributions, more than anything else, help to move Asterisk’s capabilities forward[/quote].
I would have to talk to my company lawyers before signing the waiver required to contribute any code to the project. To be quite honest though, if I had this kind of time to invest I would rather spent it exploring the alternatives - Kamailio, FreeSwitch or Yate.

blogs.digium.com/2009/03/28/sip-security/

cheers

6

Yup, I remember that. I did some searching before responding and that came up. I didn’t consider that its mention by John Todd in his blog post there was commensurate with a declaration of panacea, but that’s the inside looking out, I suppose.

I don’t think characterizing the Asterisk community as lacking in care about security is very fair. In my opinion, the Asterisk community is ahead of the other communities you’ve mentioned with its response to security-related issues. Where can I go to find security reporting for any of those projects? When a security-related Asterisk issue reported (downloads.asterisk.org/pub/security/.

For contributions, here’s a copy of the license agreement:
issues.asterisk.org/jira/secure … cense.jspa

We’ve had a lot of people say the same thing with respect to the time that it takes to get an agreement reviewed by their legal department and signed; but the benefits of doing so, and in pushing to get your code into Asterisk, are great. The work you contribute enables Asterisk to grow faster, and ensures that as you’ve benefitted from Asterisk, other users benefit from your own use of Asterisk.

Once upon a time, Kevin Fleming, with whom you might be familiar, was a tireless voice on the mailing lists pointing out ways Asterisk could improve. One day, he began contributing code, and Asterisk has been better ever since.

7

You remember ? This link is in the README-SERIOUSLY.bestpractices.txt file distributed with asterisk.

Depends on your definition of “Asterisk community”. Most people use asterisk via some distro where the situation is not as rosy as you describe. Just check forums.digium.com/viewtopic.php?t=78054 .

also voipfraud.net/en/node/1865

8

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.

9

Roderick,

I am trying to understand why are you jumping into the conversation without reading what already has been said on the subject.

Please understand we are not talking about REGISTER packets, we are talking about INVITE.
I would suggest re-reading the thread and rolling back your change to voip-info wiki.
You might also want to take the test: viewtopic.php?t=79018

10

Hello Thor,

As I described in my reply, you have mentioned a number of different issues across a number of threads. You’re right, I missed a case and I’ll answer that in just a moment. But first I’d like to ask that you relax and take a more constructive tone with others on this board. Strong opinions are welcome, but splaying this sort of negativity is not. Be constructive, or move along.

One of the SIP attacks you referenced was account enumeration (without registration). This was answered by the security advisory and the directive to use alwaysauthreject, so I replaced the non-actionable warning message on voip-info with useful information to mitigate the vulnerability and a link to more information.

You described another situation (the one I missed) in which an IP address is not recorded in the log for a failed call from a non-registered SIP agent. This logging behavior was changed in revision 321511, which was rolled into Asterisk 1.8.5. Please see the changed behavior below:

[code]Asterisk 1.8.0:
[Jul 16 05:34:27] NOTICE[2970] chan_sip.c: Call from ‘’ to extension ‘395’ rejected because extension not found in context ‘default’.

Asterisk 1.8.5:
[Jul 16 05:49:55] NOTICE[29385] chan_sip.c: Call from ‘’ (10.23.228.150:5060) to extension ‘395’ rejected because extension not found in context ‘default’.[/code]

The IP address of the non-registered caller now appears in the logs and may be used in fail2ban rules if you so choose.

Please note that Asterisk is open source software and the change that made this possible was one line of code. One line that could have been copy-pasted from a similar log message that behaves the way you desired. Asterisk thrives because of its vibrant community of users and developers. Please participate constructively.

11

Hello RoderickM,

thank you for not cross-posting. Unfortunately, as in your previous posts, you are off topic. The log you provided shows the call has been accepted by asterisk and an attempt to find a matching extension has been made. This happens because you did not set allowguest=no and you used non existent user in the From: header.

The original problem is when someone tries to bruteforce an existing user w/o reaching any extensions. I pulled the trunk and built SVN-trunk-r328502. Asterisk still does not log the IP address, as before it logs the From: header instead as in:

You must rely on the attacker to provide the correct IP in the From: header for fail2ban to execute the correct action.

12

Hello Thor,

If the topic is fail2ban and Asterisk logging, then this discussion is very much on topic. I reviewed the threads once more, and see that paf61 was asking about the particular log message I noted. For your case, I set allowguest=no and used a valid username but invalid password. I tried another one-line patch for Asterisk (though the same line is applied in three places within chan_sip.c) and got the following results:

Asterisk 1.8.5.0 before patch:
[Jul 16 14:27:53] NOTICE[29385] chan_sip.c: Sending fake auth rejection for device "roderickm" <sip:girstwce@192.168.1.104>;tag=PNNjEgTzE4K.2w221Kd5qYLoL5MCG8I

with patch:
[Jul 16 14:34:44] NOTICE[1823] chan_sip.c: Sending fake auth rejection for device "roderickm" <sip:girstwce@192.168.1.104>;tag=aQF8ZHDlcTtoyERbjFkKOnoQHkisuEg9 (76.103.148.116:44752)

Does this do what you expect?

Here’s the patch…

[root@asterisk channels]# diff chan_sip.c chan_sip.c.orig 
21216c21216
< 				ast_log(LOG_NOTICE, "Sending fake auth rejection for device %s (%s)\n", get_header(req, "From"), ast_sockaddr_stringify(addr));
---
> 				ast_log(LOG_NOTICE, "Sending fake auth rejection for device %s\n", get_header(req, "From"));
21870,21871c21870
< 				ast_log(LOG_NOTICE, "Sending fake auth rejection for device %s (%s)\n", get_header(req, "From"), ast_sockaddr_stringify(addr));
< 
---
> 				ast_log(LOG_NOTICE, "Sending fake auth rejection for device %s\n", get_header(req, "From"));
23640c23639
< 			ast_log(LOG_NOTICE, "Sending fake auth rejection for device %s (%s)\n", get_header(req, "From"), ast_sockaddr_stringify(addr));
---
> 			ast_log(LOG_NOTICE, "Sending fake auth rejection for device %s\n", get_header(req, "From"));
23857c23856
< 				ast_log(LOG_NOTICE, "Sending fake auth rejection for device %s (%s)\n", get_header(req, "From"), ast_sockaddr_stringify(addr));
---
> 				ast_log(LOG_NOTICE, "Sending fake auth rejection for device %s\n", get_header(req, "From"));
13

Okay, we are finally making progress. The patch misses at least one place around line 16134 and it does nothing for methods other than REGISTER and INVITE. This is your typical whack-a-mole. In my second message in this thread I said:

It is also worth mentioning, if people used type=peer instead of type=friend, none of these attacks would have a chance of succeeding as type=peer forces registration which fail2ban already knows how to protect.

14

For the record, fail2ban is also mentioned in “Asterisk™: The Definitive Guide” by Leif Madsen, Jim Van Meggelen, and Russell Bryant - in chapter Security

ofps.oreilly.com/titles/97805965 … urity.html

15

Oh, I might be late to this but I really like this thread. Wow, Thor! You nailed it and made progress!!! Something that very rarely happens here. Unfortunately, anyone reporting a problem is labelled a troll.

Digium’s attitude is same to most of other “Asterisk communities” attitude as well. There is either a big distrust issue from Digium developers towards Asterisk users or ignorance plays a big role on their part.

Thanks to you for following and being patient with both other posters.

I would very much like to see what sort of regex patterns you came up for Fail2ban related to Asterisk (If you are still using Asterisk and haven’t moved on) :stuck_out_tongue: . I have the same problem with Asterisk logging. There is no universal logging practice and it changes from version to version.

16

Hi,

I was wondering if sby found a solution regarding the attacker’s IP address not logged.
I am running 1.8.7 and got same pbm yesterday.

“chan_sip.c:21975 handle_request_invite: Sending fake auth rejection for device 5550000sip:5550000@myIPaddress;tag=b136ef91”

Nothing went bad but that’s scary not to be able to log attacker’s IP. You can’t do annything
to prevent it.

17

I concur with torontob. Thank you thor for your diligence and attention to digium’s fiduciary responsibility. Socrates liked to ask questions and point out inaccuracies too. And we know what happened to him. So thor, please don’t let the “senators” of these forums deter you by their argumentum ad hominem. Of course the silence from roderickm is deafening, he must be busy preparing a pot of hemlock… yeah, I said it. :laughing:

There’s many a slip 'twixt the cup and the lip.
–Old English Proverb

19

Hello guys,

I know it’s been a while since this topic was hot but recently my asterisk has been under attack and unfortunately it succeeded by making international calls for at least $100 :[

I use version 1.8.17 and from what I see the problem with the INVITE packets is still there. Is there any progress on this MAJOR issue? I can’t find any solution to that. Should I switch to Asterisk 10 (which I really don’t want to because I have enough clients with working 1.8 systems and don’t want to risk losing stability by making a big jump)?

For me it’s unacceptable this issue no to be resolved for so much time. I’m very worried about the security of asterisk systems.

20

Hello geeks,

first of all, I am very disappointed and maybe you can find this frustration in my choice of words. If anybody feels offended, please note that this was not my intention.

I am using asterisk since version 1.2 and while the time went by I decided to choose asterisk 1.8 for a new setup. Now I am facing the problem which has been discussed on many threads in here but for wich I was not able to find a SERIOUS answer - may someone from digium please be so nice and explain in clear words, WHY they changed the code so that I am not able to block attacking IPs?

Yes, you guys know what I mean:

All those discussions that popped up here and their related answers just let me think one thing:“You guys gotta be kidding me.”

I do not know how other voip-admins work on security issues but one of the first things I do is to use SIPVICIOUS against asterisk on the external interface to see what information an attacker might gain. And it is hillarious that I cannot block such IPs (with Fail2Ban or AgentSmith) because asterisk “was re-programmed in such a way” that it lazily does not log the attacking IP.

Of course, I always set alwaysauthreject and allowguest to the suggested values, because with that security issue I do not have a choice ! Of course I never used type=friend as long as I do not need to. All these tips do not shoot the problem and should always be used were appropriate.

I do really wonder how this change of behaviour can be accepted by anyone in the voip-area. Since I do not see any changes on this topic I tend to write some exploits with my fellows at metasploit to prove how this issue can lead to a DoS-attack - maybe then someone wakes up @ digium.

Trying to bring it back to a constructive discussion:

  1. Why did you change the code for logging ?
  2. Is there a patch that corrects the logging of asterisk ?
  3. If there is one patch, why isn’t it integrated in 1.8-CURRENT ?
  4. Does digium really suggests its customers to fall back to version 1.6 or even 1.4 ?
  5. Did you ever use SIPVICIOUS ?
  6. What else plea you got ?

Best wishes, r0n

21

The “you” that you refer to are on the asterisk-dev mailing list, not here!