Asterisk and SIP Security Redux
jtodd October 29th, 2009
Another rash of FUD (Fear, Uncertainty, and Doubt) has swept into my mailbox in the last few days, as an interview that I gave on SIP security may have been misinterpreted by some to mean something other than my intention. My comment in the article was not that “Asterisk attacks are endemic”, but that SIP-based brute force attacks are endemic. Every SIP system that is open to the “public” Internet is seeing large numbers of brute-force attacks. Sites that have weak username and weak password control will be compromised – this is little different than email accounts being taken over by password-guessing systems and used for sending floods of email. The significant difference is that when someone takes over a SIP platform to make outbound calls, there is usually a direct monetary cost, which gets people’s attention very quickly. I hear reports of these types of attacks now all the time – it’s not unusual, and it’s not just Asterisk. We had a blog about this a year ago or so and a follow-up that discussed secure SIP practices with Asterisk; this is just a re-packaging of the same news a year later, when recently I unsurprisingly said that attacks are no longer even newsworthy because they’re so frequent (hence, the term “endemic”.) Apparently, not being newsworthy means… it’s newsworthy!
This has little to do with Asterisk other than it happens to be the most prevalent SIP-based platform on the Internet currently. It has everything to do with protocol attacks by script kiddies, or more professional attackers. Bad passwords = easy penetration. The upside on this is that it yet again gets the attention of administrators who might not otherwise know that their password of ‘1234′ might be guessed by criminal users.
The bug that was mentioned in the SlashDot summary of the article? Old news. Really, really old news. And really not even that much of a threat for most people the way they have their systems configured even if they haven’t upgraded.
Asterisk, Broadsoft, Cisco, Kamailio, OpenSER, FreeSwitch, Avaya – they’re all vulnerable to the brute force attacks if adequate network and username/password security is not implemented. There are ways to minimize, if not eliminate these threats with very standard security policies that should be familiar to any network administrator (ACLs, random passphrases, random client usernames, adequate exception logging, and limits on account usage, to name a few.) Here’s the blog I wrote on this a while back, which is somewhat Asterisk specific but contains useful pointers for pretty much any SIP system. I suspect that >99% of the penetration threat is mitigated with just the simple policy of strong username/password pair combinations – the tools that are being used by most black-hat types are just brute force attacks. Script kiddies take the easiest possible targets; common-sense methods remove you from that target range.
To update people on the current thinking about network-based mitigation: After quite a bit of debate in the development community, it was generally agreed that within Asterisk is not the appropriate place to do proactive “defense” mechanisms that block network ports or certain users. There are extremely sophisticated systems (free and non-free) that will take log output from a network-based application such as Asterisk, and then provide IP-layer blocking and alerting. They do it much better and faster than Asterisk could hope to. What has been recently implemented in Asterisk is a framework to report security events upstream to such programs, and the SIP stack is the first on the list to be instrumented. Digium has been working on this framework in conjunction with community members who have expressed interest in building more sophisticated third-party alerting and management tools around Asterisk and other SIP-based platforms.
Note that Asterisk already has basic Access Control List functionality for SIP and other IP protocols that Asterisk “talks” on, though it is statically configured in a very similar manner to the way that Apache or other network servers work.
Just as an aside, the Digium SwitchVox platform, which is our commercial re-packaging of Asterisk, has as an element of it’s GUI a tool that indicates the relative strength of passwords. We’d encourage any other re-packagers or users of Asterisk to implement a similar UI hint that forces good password behavior by users and local admins. It’s really not something that can be done in the core of Asterisk; it has to be done by whatever is the layered UI on top of Asterisk for configuration, or just by good policy. Good security policy is really the cornerstone of the whole solution. Asterisk is like any other infrastructure server program: it’s generally very secure as a core platform for an application service, PBX, or appliance, but that doesn’t absolve administrators from making sensible and secure policy decisions regarding how it is implemented. I hope in the future that there is a better understanding between application security and implementation security, but I suspect I’ll be writing this explanation again in another year.
JT (Open Source Community Director)