So as is unfortunately typical, some of the quotes I made of course been taken out of proportion. My quote 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; 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? 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.)
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.
I've got quite a bit of generator-building experience at this point for home duty. I think plenty has been said on how NOT to wire up your house, so I'll leave that alone.
Since this is/., I assume that the typical sissy-pants off-the-shelf generator is not nearly interesting enough, so I'll make a few suggestions that are less (or more) practical, depending on your viewpoint below.
There are few home generators which are built for long-term use. That may be fine - maybe you don't need long-term use. Even the Generac or Onan units are typically not "primary" systems, though they may be very good for a few days or even a few weeks. The portable units are good for a day or two at the most - they have a very different engineering mindset that went into their construction, and should be used only for temporary emergencies. If you get more than a few days on one of those, consider yourself lucky and figure out what you're going to do for real next time.
I've got a few diesel-powered generators at home (and a few gas-powered ones, and a steam engine that eventually will be producing electrons) and these oil engines are the best solution for long-term power. Slow, but robust and low-maintenance, with few parts and easily understood by anyone with basic mechanical capabilities. Changfa is a good name for the higher speed engines (3600rpm) and Lister CS engines are still being made in India for import, though Canadians can find them while US residents are restricted by EPA import laws now.
If I lived somewhere that had oil or gas underneath the property, I'd probably get an Arrow engine, which runs on "waste gas". These are slow engines, but put out a respectable 15 or so horsepower for the smaller ones, and they'll run for decades with minor maintenance and care. They're not that expensive at auction or surplus from oilfield companies.
For any of these, you'll need to build your own base, get a generator head, and wire everything up. But it's a fun project.
Digium posted an "official" reply here:
http://blogs.digium.com/2008/12/06/sip-security-and-asterisk/
There was a bug in Asterisk that allowed unauthenticated callers to access the guest context, but in order for that to be a threat one would have to configure the dialplan such that guests were able to dial out on whatever PSTN trunk (SIP or analog/digital trunk) was attached to the system. Unlikely a huge threat, and that bug was fixed 9 months ago for 1.2 and 1.4, and doesn't exist for 1.6.
More likely is that this is a password guessing attack, so there is some confusion as to how this is an "Asterisk bug" and not just a matter of poor password choices.
There exists already an experimental numerical, IP-based numbering/directory system which has more promise (IMHO) than a new top level domain. Check out http://www.freenum.org/ - there are about 100 organizations that have numbers in the range and who are actively using the system, such as MIT, Internet2, Columbia, Free World Dialup, and many more.
ISN (ITAD Subscriber Number) endpoint identification avoids namespace conflicts by using unique numeric suffixes for firms, much like domain names. These are allocated by IANA at the moment. An example ISN would be "1234*256" which would translate via an ENUM-like method into extension 1234 at organization 256, which evaluates into "sip:1234@204.91.156.10" but could also contain instant messaging NAPTRs, E.164 endpoints (fully qualified telephone numbers), email addresses, etc.
Creating a.tel hierarchy defeats the purpose of NAPTR and SRV records. Use your existing domain name if you or your interested dialers have the ability! ISN is only a stopgap for devices which are number-pad constrained (telephone handsets.) Creating a catch-all for telephony domain names seems like we're going in the wrong direction. Everyone has an email address, right? So if the assumption is that the "dialing party" has the ability to enter in some type of domain name, then why aren't we using the email address of the recipient to "dial" a number? This whole.tel suffix is counter-intutive - perhaps someone can explain it better to me in a way that doesn't involve how the explainer can reap a profit by being a domain registrar.
Slashdot Mirror
So as is unfortunately typical, some of the quotes I made of course been taken out of proportion. My quote 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; 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? 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.)
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.
http://blogs.digium.com/2009/03/28/sip-security/
http://blogs.digium.com/2008/12/06/sip-security-and-asterisk/
John Todd - jtodd@digium.com
Digium, Inc.
Asterisk Open Source Community Director
I've got quite a bit of generator-building experience at this point for home duty. I think plenty has been said on how NOT to wire up your house, so I'll leave that alone.
Since this is /., I assume that the typical sissy-pants off-the-shelf generator is not nearly interesting enough, so I'll make a few suggestions that are less (or more) practical, depending on your viewpoint below.
There are few home generators which are built for long-term use. That may be fine - maybe you don't need long-term use. Even the Generac or Onan units are typically not "primary" systems, though they may be very good for a few days or even a few weeks. The portable units are good for a day or two at the most - they have a very different engineering mindset that went into their construction, and should be used only for temporary emergencies. If you get more than a few days on one of those, consider yourself lucky and figure out what you're going to do for real next time.
I've got a few diesel-powered generators at home (and a few gas-powered ones, and a steam engine that eventually will be producing electrons) and these oil engines are the best solution for long-term power. Slow, but robust and low-maintenance, with few parts and easily understood by anyone with basic mechanical capabilities. Changfa is a good name for the higher speed engines (3600rpm) and Lister CS engines are still being made in India for import, though Canadians can find them while US residents are restricted by EPA import laws now.
If I lived somewhere that had oil or gas underneath the property, I'd probably get an Arrow engine, which runs on "waste gas". These are slow engines, but put out a respectable 15 or so horsepower for the smaller ones, and they'll run for decades with minor maintenance and care. They're not that expensive at auction or surplus from oilfield companies.
For any of these, you'll need to build your own base, get a generator head, and wire everything up. But it's a fun project.
More links:
http://www.listerengines.com/
http://www.loligo.com/projects/changfa/
http://www.loligo.com/projects/lister/
http://www.f1-rocketboy.com/lister.html
FBI updates the release and says yes, it's just a re-hash of an old security notice that went out in March.
http://www.ic3.gov/media/2008/081205-2.aspx
See the Asterisk [UPDATE] here:
http://blogs.digium.com/2008/12/06/sip-security-and-asterisk/
Digium posted an "official" reply here:
http://blogs.digium.com/2008/12/06/sip-security-and-asterisk/
There was a bug in Asterisk that allowed unauthenticated callers to access the guest context, but in order for that to be a threat one would have to configure the dialplan such that guests were able to dial out on whatever PSTN trunk (SIP or analog/digital trunk) was attached to the system. Unlikely a huge threat, and that bug was fixed 9 months ago for 1.2 and 1.4, and doesn't exist for 1.6.
More likely is that this is a password guessing attack, so there is some confusion as to how this is an "Asterisk bug" and not just a matter of poor password choices.
There exists already an experimental numerical, IP-based numbering/directory system which has more promise (IMHO) than a new top level domain. Check out http://www.freenum.org/ - there are about 100 organizations that have numbers in the range and who are actively using the system, such as MIT, Internet2, Columbia, Free World Dialup, and many more.
.tel hierarchy defeats the purpose of NAPTR and SRV records. Use your existing domain name if you or your interested dialers have the ability! ISN is only a stopgap for devices which are number-pad constrained (telephone handsets.) Creating a catch-all for telephony domain names seems like we're going in the wrong direction. Everyone has an email address, right? So if the assumption is that the "dialing party" has the ability to enter in some type of domain name, then why aren't we using the email address of the recipient to "dial" a number? This whole .tel suffix is counter-intutive - perhaps someone can explain it better to me in a way that doesn't involve how the explainer can reap a profit by being a domain registrar.
ISN (ITAD Subscriber Number) endpoint identification avoids namespace conflicts by using unique numeric suffixes for firms, much like domain names. These are allocated by IANA at the moment. An example ISN would be "1234*256" which would translate via an ENUM-like method into extension 1234 at organization 256, which evaluates into "sip:1234@204.91.156.10" but could also contain instant messaging NAPTRs, E.164 endpoints (fully qualified telephone numbers), email addresses, etc.
Creating a