I arrived to work this morning to find that the Heartbleed Bug happened.
This is one of the biggest security issues to crop up in a long time – allowing the data normally protected by TLS/SSL to be compromised. This is the kind of data that normally passes securely between clients and protected websites, email services, instant messaging, etc.
Upgrade all your systems now. This is where my well planned day went.
Be sure to restart all services that use OpenSSL (or reboot your servers). A useful command [source] for this post-upgrade is:
grep -l 'libssl.*deleted' /proc/*/maps | tr -cd 0-9\\n | xargs -r ps u
A useful Python script for testing your web servers can be found in this Gist. NB: it’s not just web servers affected – any services with SSL/TLS may be affected.
On our own Asterisk PBX server for our office and on some customer boxes with open SIP ports, we have seen a dramatic rise in brute force SIP attacks.
They all follow a very common pattern – just over 41,000 login attempts on common extensions such as 200, 201, 202, etc. We were even asked to provide some consultancy about two weeks ago for a company using an Asterisk PBX who saw strange (irregular) calls to African countries.
They were one example of such a brute force attack succeeding because of a common mistake:
- an open SIP port with:
- common extensions with:
- a bad password.
(1) is often unavoidable. (2) can be mitigated by not using the predictable three of four digit extension as the username. (3) is inexcusable. We’ve even seen entries such as extension 201, username 201, password 201. The password should always be a random string mixing alphanumeric characters. A good recipe for generating these passwords is to use
openssl as follows:
Users should never be allowed to choose their own and dictionary words should not be chosen. The brute force attack tried >41k common passwords.
Preventing or Mitigating These Attacks
You can mitigate against these attacks by putting external SIP users into dedicated contexts which limit the kinds of calls they can make (internal only, local and national, etc); ask for a PIN for international calls; limit time and cost; etc.
However, the above might be a lot of work when simply blocking users after a number of failed attempts can be much easier and more effective. Fail2ban is a tool which can scan log files like
/var/log/asterisk/full and firewall IP addresses that makes too many failed authentication attempts.
See VoIP-Info.org for generic instructions or below for a quick recipe to get it running on Debian Lenny.
Quick Install for Fail2ban with Asterisk SIP on Debian Lenny
- Create a file called
/etc/fail2ban/filter.d/asterisk.conf with the following (thanks to this page):
- Put the following in
/etc/asterisk/logger.conf such that the date format under
- Also in
/etc/asterisk/logger.conf, ensure full logging is enable with a line such as the following under
full => notice,warning,error,debug,verbose
- Resart / reload Asterisk
- Start Fail2ban:
/etc/init.d/fail2ban startand check:
- Fail2ban’s log at
INFO Jail 'asterisk-iptables' started
- The output of
iptables --list -vfor something like:
Chain fail2ban-ASTERISK (1 references)
pkts bytes target prot opt in out source destination
227 28683 RETURN all -- any any anywhere anywhere
You should now receive emails (assuming you replaced the example addresses above with your own and your MTA is correctly configured) when Fail2ban starts or stops and when a host is blocked.