Fail2ban: False sense of security

[thor]

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

[malcolmd]

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?

[thor]

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.

[malcolmd]

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:

https://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.

[thor]

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.

Code contributions, more than anything else, help to move Asterisk's capabilities forward

.
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.

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

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

cheers

[malcolmd]

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

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 (security@asterisk.org or open an issue on the issue tracker - https://issues.asterisk.org/jira), it's taken very seriously, and dealt with very quickly. The reporting infrastructure for dissemination of security-related information is also pretty well built-up, with mailing list and website notifications of the advisories. And, everything is available for posterity, archived at http://downloads.asterisk.org/pub/security/.

For contributions, here's a copy of the license agreement:
https://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.

[thor]

Yup, I remember that.

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

I don't think characterizing the Asterisk community as lacking in care about security is very fair.

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 http://forums.digium.com/viewtopic.php?t=78054 .

also http://www.voipfraud.net/en/node/1865

[roderickm]

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:

Code: Select all

[Jul 13 19:12:14] NOTICE[2970] chan_sip.c: Registration from '"baduser" <sip:baduser@asterisk.example.com>' failed for '216.207.245.1:61140' - No matching peer found

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

[thor]

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

[roderickm]

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: Select all

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'.

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.

[thor]

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:

chan_sip.c: Failed to authenticate device sip:100@random.crap;tag=J5zBr48MrJLLJQWPpHd02Bw.DxHGvEBZ

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

[roderickm]

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:

Code: Select all

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...

Code: Select all

[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"));


[thor]

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:

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.

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.

[thor]

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

http://ofps.oreilly.com/titles/97805965 ... urity.html

[torontob]

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) . I have the same problem with Asterisk logging. There is no universal logging practice and it changes from version to version.

[hazzmat]

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 5550000<sip: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.

[dunwright]

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.

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

[mjordan]

For those interested, JIRA issues for this topic have been created here:

https://issues.asterisk.org/jira/browse/ASTERISK-20506

Note that this was previously reported in ASTERISK-19348, which resulted in this issue being resolved in the Security Event Framework. This provides a consistent mechanism for receiving security related information over a variety of mechanisms, including the Asterisk logger. I understand that doesn't resolve this issue for folks on Asterisk 1.8, so we'll keep ASTERISK-20506 open to see if we can't find a path forward.

https://issues.asterisk.org/jira/browse/ASTERISK-19348

If anyone is interested in contributing towards a solution, please discuss this on ASTERISK-20506.

[stanimir_ss]

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.

[dadooronron]

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:

Code: Select all

[2012-12-03 10:48:07.098] NOTICE[4752] chan_sip.c: Sending fake auth rejection for device 100<sip:100@my_own_external_ip>;tag=7c09df41

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 ?
5) What else plea you got ?

Best wishes, r0n

[david55]

1) Why did you change the code for logging ?

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

[craigarno]

I tried to collect a little more information on one of these "attempts" on my system since like others here, they occur about 20-30/day and hit at high speed and run. I'm running:
Asterisk 11.2.1 built by root @ pluto on a x86_64 running Linux on 2013-02-27 17:10:37 UTC

On my asterisk console "asterisk -vvvr" I see:
[Mar 27 10:44:51] NOTICE[14760][C-00001770]: chan_sip.c:25081 handle_request_invite: Sending fake auth rejection for device 220<sip:220@50.132.114.182>;tag=52f1c7b1

50.132.114.182 is my external IP, changed for posting here.

I left wireshark (ethernet snoop) running to capture one of these events and here is what I see:

41248 282.745440000 37.75.215.95 50.132.114.182 SIP/SDP 797 Request: INVITE sip:99011972543424432@50.132.114.182 | , with session description

Frame 41248: 797 bytes on wire (6376 bits), 797 bytes captured (6376 bits) on interface 0
Ethernet II, Src: Cisco_b0:19:e2 (00:1d:70:b0:19:e2), Dst: AsustekC_0b:bf:ba (54:04:a6:0b:bf:ba)
Internet Protocol Version 4, Src: 37.75.215.95 (37.75.215.95), Dst: 50.132.114.182 (50.132.114.182)
User Datagram Protocol, Src Port: vtsas (5070), Dst Port: sip (5060)
Request-Line: INVITE sip:99011972543424432@50.132.114.182 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.4:5070;branch=z9hG4bK-5b3d7c0241b0370854f9fc0930d95996;rport

I know 192.168.1.4 isn't my private subnet because my subnet is numbered differently.

I also see the equipment used in this "drive-by" is Cisco, which I interpret as -expensive- and probably a well funded organized effort.

As is typical of these events, a reverse lookup on 37.75.215.95 shows the IP isn't registered anywhere recognizable.

I wish Asterisk could take these events and after a failed attempt, automatically block the requester. This feature should be countered with being able to unblock a single IP, or never block a specific IP (i.e. if it's me trying to get my setup running I need to be able to say, this is mine, don't block it while I continue to make mistakes).

Nice thread. There is obviously a lot of pain over this subject in the Asterisk community. Count me as one of those experiencing pain.

[david55]

The Cisco in the L2 header refers to your own router!

The IP address comes back to a company called Orange Palestine Group Co, in Gaza.

[craigarno]

Thanks for the additional info. I don't knowingly own any Cisco equipment unless it's cleverly disguised as a Comcast cable modem (the only equipment between the "Dst" device and the rest of the world). The dump below also says the Cisco device is the "Src" leading me to believe it belongs to the "Src IP" 37.75.215.95 below. AsustekC-"Dst" is my onsite equipment which matches the MAC address on the public side of my server.

Since my posting 3 more of these "drive-by's" cluttered up the console (none get through, yet). The result of all this garbage showing on the console with no way to block or suppress is I'm getting desensitized to events showing up on the console. Mine is a "tiny" installation with only about 8 phones and I'm spread too thin doing everything else I need to be doing other than babysitting Asterisk security. Like I said, it would be nice if this particular event could be addressed in Asterisk code since whatever is causing these events is rapidly escalating in intensity. I didn't know about the "peer vs friend" difference mentioned in this thread. My Asterisk SIP example shows "friend". I changed all my devices to "peer" and they still seem to work. So I learned something new about Asterisk today.

Thanks,
Craig

[david55]

I believe some cable operators present a bridge, rather than a router interface, so the Cisco may be the router at Comcast, but it certainly will not be on the far side of the internet.

Before interpreting Wireshark output you really need to know the difference between layer 2 and layer 3 addresses. Only the latter have any meaning on the internet.

The "Cisco" itself is the result of Wireshark interpreting the prefix of the MAC address to get the manufacturer code.

[craigarno]

You are right. The Src MAC address belongs to local equipment, either a Comcast modem, or a Comcast gateway device. I proved this by capturing unfiltered packets from many different IP sources, and all have the same Src MAC address. I also logged into another Linux system across town and "ifconfig" showed me the machines MAC address, which doesn't show anywhere in captured data exchanged with that machine.

I tracked down 4 more more IP's coinciding with yesterday's Asterisk Console messages. For what it's worth, all 4 came from the Gaza/Jerusalem area. There were many more attempts than 4, but I was only around and had wireshark running for 4 of these events. They arrive in short high speed bursts, too short to allow for starting wireshark if it isn't already running and capturing.

At one time I carefully read and implemented the security information found in the Asterisk distribution file README-SERIOUSLY.bestpractices.txt. So far I've not detected any successful unauthorized use of my system. This said, I feel it's only a matter of time at the current rate of escalation. Asterisk users are under attack.

[Discovered the following (incorporating into Asterisk) isn't a good idea, as uncovered in following messages]
I still feel strongly that a new feature to place any failed register/place call attempt with my system warrants the IP (or range of IP's) be placed on a "naughty" list (local and/or RBL) and blocked for days, or forever is highly desirable. This feature will also need the ability to ignore specific "good" IP's/ranges during configuration/development with new equipment. Attacks are becoming common, regular, and increasing in frequency. Tools beyond "best practices" are needed to assist Asterisk users to manage these issues. One successful break-in will cost real money from unauthorized misuse/abuse of paid for telephony services and loss of network bandwidth/functionality.

Thanks for reading.

[navaismo]

This feature will also need the ability to ignore specific "good" IP's/ranges during configuration/development with new equipment. Attacks are becoming common, regular, and increasing in frequency. Tools beyond "best practices" are needed to assist Asterisk users to manage these issues. One successful break-in will cost real money from unauthorized misuse/abuse of paid for telephony services and loss of network bandwidth/functionality.

Thanks for reading.

Asterisk is a PBX, if you are concerned about the security you need to look at another place or software. Maybe the people always confuse the fact that asterisk is a PBX software, and want to do a lot of things inside asterisk itself.

If you want to block IPs or attacks use the normal logs of asterisk plus iptables, blockhosts or fail2ban or whatever. Seriously people need to start complain at their installations holes instead of a PBX.

I use sip peers with type=friend, I have opened ports to my pbx, I allow guest to do calls and I have the blockhosts tool. And I don't loose money.

[craigarno]

Asterisk is a PBX, if you are concerned about the security you need to look at another place or software. Maybe the people always confuse the fact that asterisk is a PBX software, and want to do a lot of things inside asterisk itself.

A difference of philosophy from my statement which I'll accept if I can find a solution. I like this as it appears to fit the general philosophy of Unix (and Linux).

If you want to block IPs or attacks use the normal logs of asterisk plus iptables, blockhosts or fail2ban or whatever. Seriously people need to start complain at their installations holes instead of a PBX.

Apparently you missed the point of this thread... Asterisk logs (system or console) don't contain information needed to block these attempted intrusions by any external program. The connecting IP isn't exposed in Asterisk log message. The problem described in this thread exists and is real.

I use sip peers with type=friend, I have opened ports to my pbx, I allow guest to do calls and I have the blockhosts tool. And I don't loose money.

I suspect your "guests" are not random unknown internet users trying to place free calls to Israel through your system. In other words your "guests" are vetted in some other way and are known quantities and/or granted very limited capabilities before being granted access to your system and bear no resemblance to the discussion here. i.e. irrelevant and argumentative.

I also allow "guests" to use my system to place calls... not relevant to this discussion.

[navaismo]

Yes I have many attacks from Egypt, Gaza, Israel and so on. And yes I use asterisk logs to block them but again people always complain instead do the job.

I'm sick of this posts where users have the source code to do what they want but instead of that just came and complain and wait for others to do the job.

Ok I'm out of the equation...

[david55]

Apparently you missed the point of this thread... Asterisk logs (system or console) don't contain information needed to block these attempted intrusions by any external program. The connecting IP isn't exposed in Asterisk log message. The problem described in this thread exists and is real.

Quite a few people complain because the normal logs don't provide this information, when, with current versions, they should actually be using the security logs.

The normal logs assume that failed calls are the result of something you have done wrong, not the result of hostile action, so the information they provide is aimed at finding and fixing your errors, not at blocking attackers.

[craigarno]

Quite a few people complain because the normal logs don't provide this information, when, with current versions, they should actually be using the security logs.

The normal logs assume that failed calls are the result of something you have done wrong, not the result of hostile action, so the information they provide is aimed at finding and fixing your errors, not at blocking attackers.

David55, thank you for explaining some of the philosophy behind Asterisk Logging. I'm looking for a needle in a haystack (Asterisk is capable and complex, and I don't yet know enough to solve this problem).

The approach I'm currently adopting to solve this problem is:

1. Try to provide sufficient external logging information to identify the source of attack (following the "security logs" thread you identified)

2. Use sufficient external logging information from #1 with an external program like Fail2ban (philosophy identified earlier by navaismo)

Google helped me find this thread using the original console error message. I used "Search" to discover more of what you meant by "security logs". This lead me to /etc/asterisk/logger.conf. I see these lines already in the file:

Code: Select all

console => notice,warning,error
messages => notice,warning,error

Since I'm running Asterisk 11.2.1 I added the new *11-"security" keyword to "console" and "messages".
pluto*CLI> logger reload
== Parsing '/etc/asterisk/logger.conf': Found
Asterisk Queue Logger restarted

New "security" informational messages are showing in /var/log/asterisk/messages. A quick glance at prior "NOTICES" suggests these events happen about 6x in one second at 30, 45, 50, and 60 minute intervals. So it shouldn't be too long until the next attempts.

Thank you for your direction so far. If you can think of anything else to add to this direction or another, please share. Otherwise, when I find a solution, I'll post it here for all to see and adopt as desired.

[craigarno]

FYI, the new Asterisk 11 "security" log feature does expose the remote IP in log files:

[Mar 30 08:21:53] NOTICE[14760][C-000017e4]: chan_sip.c:25081 handle_request_invite: Sending fake auth rejection for device 501<sip:501@50.132.123.456>;tag=ba5e8ad1
[Mar 30 08:21:53] SECURITY[14743]: res_security_log.c:134 security_event_cb: SecurityEvent="InvalidAccountID",EventTV="1364656913-935416",Severity="Error",Service="SIP",EventVersion="1",AccountID="011972592267352",SessionID="0x7f7cd8710818",
LocalAddress="IPV4/UDP/50.132.123.456/5060",RemoteAddress="IPV4/UDP/166.78.61.131/5078"

This call could have cost me $0.46/minute ($27.60/hr) per outgoing line if it had been successful. i.e. $55.20/hr if two outgoing lines were used. Worst case if I didn't catch it, $1,324.80/day. This particular exploit attempt appears to be originating from Shanghai China placing a call to Israel (972). Fortunately with this set of conditions, if my system had accepted the call request my Dial Plan would have routed this call to "congestion/busy".

[ateja]

For internet connections a firewall is used to protect any kind of attacks - not the applications themselves.

So if you consider Asterisk as a PBX application, then the security should be provided by an other device: not a firewall - but an SBC (Session Border Controller) which can be considered as a "Voice Firewall". The SBC should protect against any type of SIP based attacks against Asterisk or any other brand of SIP server or PBX.

And the SBC should be in parallel, not is series to a "data" FW , so that SIP and RTP packets do not impact the data firewall performance.

[david55]

Defence in depth is always a good strategy.

Most Asterisk users with external access to their Asterisk system are likely to be using a consumer grade router, with built in firewall. They will not have a discrete firewall box and almost certainly could never justify the cost of an SBC.

How does the SBC learn which addresses are hostile? fail2ban is an adaptive filter than relies on the application to tell it when it is under attack. If you have a very small list of valid addresses, you don't need fail2ban.

[kerenaf]

I choose asterisk 1.8 for a new set up as well. I'm trying to block some IPs but I can no longer do that. Maybe because they have changed the code.