Fail2ban: False sense of security

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

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.

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). :astonished: 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

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.

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.

[quote=“craigarno”] 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.[/quote]
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.

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

[quote=“navaismo”]
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.[/quote]

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.

[quote=“navaismo”]
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.[/quote]

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.

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…

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.

[quote=“david55”]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.[/quote]

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:

[ol]

  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)
    [/ol]

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:

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.

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

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

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.

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.

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.