Category Archives: Ramblings

Asterisk 11 (FreePBX distribution) fail2ban configuration using the security log.

13 Replies

I’ve been experimenting with Asterisk again, using the FreePBX distro (2.11.0.4).

I have noticed that I get a lot of entries in the Asterisk log that look like this:

[2013-07-06 05:11:06] NOTICE[4106][C-0000001f] chan_sip.c: Failed to authenticate device 555<sip:555@aaa.bb.ccc.dd>;tag=e9a98a30
[2013-07-06 05:11:08] NOTICE[4106][C-00000020] chan_sip.c: Failed to authenticate device 555<sip:555@aaa.bb.ccc.dd>;tag=eebd8857
[2013-07-06 05:11:12] NOTICE[4106][C-00000021] chan_sip.c: Failed to authenticate device 555<sip:555@aaa.bb.ccc.dd>;tag=243f3815
[2013-07-06 07:19:42] NOTICE[4106][C-00000022] chan_sip.c: Failed to authenticate device 5555<sip:5555@aaa.bb.ccc.dd>;tag=a049427e
[2013-07-06 07:19:45] NOTICE[4106][C-00000023] chan_sip.c: Failed to authenticate device 5555<sip:5555@7aaa.bb.ccc.dd>;tag=c3c7f81b
[2013-07-06 07:19:48] NOTICE[4106][C-00000024] chan_sip.c: Failed to authenticate device 5555<sip:5555@aaa.bb.ccc.dd>;tag=6be78a0b
[2013-07-06 07:19:49] NOTICE[4106][C-00000025] chan_sip.c: Failed to authenticate device 5555<sip:5555@aaa.bb.ccc.dd>;tag=1979ada5

Where, of course, aaa.bb.ccc.dd is the address of my SIP server. Unfortunately, while FreePBX contains a fail2ban module, asterisk doesn’t provide enough information in the log file to act upon these messages.

The way I have got around this involves making some custom modifications to the Asterisk configuration.

Firstly, we need to enable Asterisk (v11) security logging feature:

Edit, /etc/asterisk/logger_logfiles_custom.conf and add the following:

fail2ban2       => security,notice,warning,error

This will create an additional log file, called /var/log/asterisk/fail2ban2

Now we need to edit the fail2ban configuration in /etc/fail2ban to process the security logged items. FreePBX configuration is in jail.local, so we will add ours to jail.conf:

[asterisk11-iptables]
 enabled  = true
 filter   = asterisk11
 action   = iptables-allports[name=SIP, protocol=all]
 sendmail-whois[name=SIP, dest=alerts@example.com, sender=pbx@example.com]
 logpath  = /var/log/asterisk/fail2ban2

Finally, we create a simple regex to get the IP address that we want to ban, and put it in the /etc/fail2/ban/filter.d/asterisk11.conf

# Fail2Ban configuration file 
# 
# 
# $Revision: 250 $ 
#
[INCLUDES]
# Read common prefixes. If any customizations available -- read them from 
# common.local 
#before = common.conf
[Definition]
#_daemon = asterisk
# Option:  failregex 
# Notes.:  regex to match the password failures messages in the logfile. The 
#          host must be matched by a group named "host". The tag "<HOST>" can 
#          be used for standard IP/hostname matching and is only an alias for 
#          (?:::f{4,6}:)?(?P<host>\S+) 
# Values:  TEXT 
# 
failregex = SECURITY.* SecurityEvent=\"InvalidPassword\".*RemoteAddress=\"IPV4/UDP/<HOST>/
#VERBOSE.* logger.c: -- .*IP/<HOST>-.* Playing 'ss-noservice' \(language '.*'\)
# Option:  ignoreregex 
# Notes.:  regex to ignore. If this regex matches, the line is ignored. 
# Values:  TEXT 
# ignoreregex =

That’s it, we now intercept messages like this one from the security log, and manage to ban these device attempts:

[2013-07-06 07:19:42] SECURITY[4078] res_security_log.c: SecurityEvent="InvalidPassword",EventTV="1373091582935268",Severity="Error",Service="SIP",EventVersion="2",AccountID="00972597103443",SessionID="0x7fa42c001ac8",LocalAddress="IPV4/UDP/aaa.bb.ccc.dd/5060",RemoteAddress="IPV4/UDP/37.8.1.89/5071",Challenge="61074795",ReceivedChallenge="61074795",ReceivedHash="b469462e8e7de800b54eb50ffe46de86"

Google’s Streetview Wardriving Accusations

Leave a Reply

In the news today, some rather sensationalist articles about what Google was collecting via WiFi on their Streetview tours.
Firstly, it needs to be pointed out, the information gathered:

  • Was unencrypted WiFi – If you run an unencrypted WiFi Home or Business network then really you are taking the risk – and you should be a lot more worried about Joe and Mary’s teenage son next door rather than the 3 seconds worth of network traffic that a Google streetview car would have picked up as it passed your house.
  • The Daily Mail (Fail) article suggests that they harvested information ‘from home computers and laptops’ as they passed by. This is simply untrue, they harvested information from the radio waves, just as you harvest information from all manner of radio frequencies when you retune your AM radio. Google’s only crime here is analysing what they heard. It should be pointed out that at no point did any interaction between data stored on a computer make its way to Google’s streetview car unless you transmitted it to them.
  • That being said – if the street view car was passing by at the time, and, you were clicking send on an email or hitting enter on a instant message, and, you’re stupid enough to not use encryption at a protocol level for any of those services, then and only then would Google have harvested some information. Perhaps a sentence in a IM conversation or a few paragraphs of your email or perhaps the URL and a quarter of a web page you happened to be browsing at the time.

There are enough conditionals there to make it seem to me that Google simply under-estimated the stupidity of our nation to protect our home computer assets. I believe their main aim in sniffing wireless traffic was to obtain BSSID information (a globally unique identifier for Wireless Access Points) to correllate it to GPS information which would allow Android phones to be able to get accurate geolocation information without necessarily having a GPS lock on the phone.

There is an opensource tool which does this very thing (called Kismet), and it saves tcpdump information to file of the sniffed wireless networks. One parameter of tcpdump is the snaplen, specified with the ‘-s’ parameter. This parameter specifies how much of the packet to save to disk. To get reliable BSSID information this probably needs to be set to around 32-bytes, just enough to get the necessary headers from the BSSID beacon frames (which by the way, you can configure to turn off as well, and would be recommended as part of an overall secure setup). I truly think that the engineer coded this parameter with zero ‘-s 0’, saw that he got the BSSID information with this parameter and left it at that. Unfortunately the ‘-s 0’ parameter value has a special meaning, and captures the entire packet.

The Daily Mail article has so many inaccuracies in it that I would expect it to be edited later. It is sensationalist, and blatently incorrect from a technical sense.