[asterisk-users] Under heavy attack

Sun Oct 31 12:58:28 CDT 2010

On Sun, Oct 31, 2010 at 1:39 PM, Joel Maslak <jmaslak at antelope.net> wrote:
> To guess an 8 character (which is short) password that consists of random upper case, lower case, numbers, and 10 symbols (there are more you can use if you want), the average number of passwords that you would have to try to get in is:
>
> (72^8) / 2 = 361,102,068,154,368 guesses
>
> Over a 10 mb/s ethernet link, assuming no latency, if it takes 100 bytes (it actually takes more), with each byte being 8 bits, of traffic sent by the attacker to Asterisk per password guessed, and the attacker knows you use 8 character passwords, then someone would need to do this for 28,888,165,452 seconds, or over 908 years of continuous guessing while saturating a 10 mb/s ethernet link.  If the attacker is unlucky, it might take twice as long.  It would be "only" 9 years if you could fill a 1 gigabit link.  If this is too short, add one character (9 total) and it will now take 72 times longer.  Two characters, and 5,184 times.

So don't block they IP/s but let them choke your bandwidth.

>
> (math is: ((361,102,068,154,368 * 100bytes) * 8bits) / 10,000,000 bit/s) = 28,888,165,452 seconds)
>
> This assumes the attacker knows the peer name (I'm assuming everyone has set their asterisk to not let the attacker know if an peer name is valid).
>
> It's actually quicker to crack modern encryption algorithms than to guess good passwords.
>
> If you have passwords that are shorter, contain less characters, or are obvious (such as matching extension numbers), then it could take less time.  That's why good passwords are important.  Good passwords should be truly random, contain a lot of characters, and include as many different classes of character as possible.  If you do easy passwords, you'll probably get hacked with or without blocking attackers, if you allow SIP registrations from the internet.

Agreed to certain extend as more sophisticated attacks will not do a
simple brute force starting at 0 and ending at z or !.

>
> I don't think blocking attackers is bad, just not something that actually improves security against fraud.  I don't do it - the risk of blocking legitimate users is too high, but others would make different choices, which is fine.  I just think it's a false sense of security if you think it makes a difference in preventing fraud.  Good passwords do prevent fraud.  Monitoring contains fraud.

While in design you might be right that it doesn't improve security,
it is something that should be implemented as a number one step for
security as it blocks the attacks. It's actually better than good
passwords. In fact one could use weak passwords if they use fail2ban,
although I wouldn't recommend it.
The risk of blocking legit user is almost non existent and should
never be the reason to allow attacks to continue against an
unprotected machine.

A good example, a previous poster said that a call took a few days and
was therefore not detected by a monitoring system. To which you
replied that you will be adding more detectors. While fraud - and this
specific type of fraud - could have come from a legit user (by legit I
mean with a legit username/pass) which means that fail2ban would have
not helped and what you have in place is a must, and with your new
rules will be detected. If however the attack would have been from a
compromised username/pass fail2ban would have detected it before you
added your new detectors. BECAUSE it could block legit users, in other
words because its way to broad blocking technique.

>
> On Oct 31, 2010, at 10:56 AM, C F <shmaltz at gmail.com> wrote:
>
>> Like I said before RUBBISH.
>> One should just ban/block IPs that are attacking you and not let them
>> connect at all. Not just protect against them with fancy passwords.
>> BTW, even your fancy passwords are breakable, can't wait for the day
>> that you'll wake up and smell the coffee.
>>
>> On Sun, Oct 31, 2010 at 11:26 AM, Joel Maslak <jmaslak at antelope.net> wrote:
>>> On Sun, Oct 31, 2010 at 2:40 AM, Tzafrir Cohen <tzafrir.cohen at xorcom.com>
>>> wrote:
>>>>
>>>> On Sat, Oct 30, 2010 at 07:33:23PM -0600, Joel Maslak wrote:
>>>>
>>>>> The CPU usage is trivial to deny them.  As is the bandwidth usage, if
>>>>> you are not sitting on a slowish broadband connection.
>>>>
>>>> s/slow/assymetric/
>>>
>>>
>>> A 1mb/s uplink is slow nowadays.  I suspect a symetrical 1mb/s SDSL line
>>> would also be having trouble with lots of registrations.
>>>
>>> But regardless, that's why I don't use ADSL for call paths, unless the ADSL
>>> is 100% within a corporate network (terminates on an ATM line in some
>>> corporate office, not in a public provider) - to easy for bad guys to send
>>> enough traffic at you to disrupt your calls.
>>>
>>
>> RUBBISH RUBBISH RUBBISH and RUBBISH again. If you have someone
>> attacking you just block him.
>>
>>> If you did have fast enough downlink to not be a victim of this, then you
>>> just need QoS - VoIP signalling (registration/registration-fail messages)
>>> should always be a lower priority than the VoIP media stream - and it's
>>> possible even on ADSL internet connections to control what you send to your
>>> provider and in what order you send it.  Media packets should always be sent
>>> before signaling on that uplink.  Even fair queuing (so long as your router
>>> recognizes the UDP traffic flows as flows) would help (and would let your
>>> legitimate users register quickly even during an attack).
>>
>> Cute idea and should be done maybe for other reasons but nothing to do
>> with attacks, if you are being attacked block the IP.
>>
>>>
>>>
>>>>
>>>>> It also seems that the only way to make blocking effective is to
>>>>> block everything by default except known endpoints.  Blocking the
>>>>> door knickers doesn't protect against a bad guy finding (not through
>>>>> brute force) valid credentials.
>>>>
>>>> Unless you have people on the road.
>>>
>>> Agreed.  But I would host that in a datacenter with adequate bandwidth, not
>>> on the end of an ADSL or other connection that is easy to DOS.
>>
>> Why is a datacenter harder to DOS? The fact that there is more
>> bandwidth doesn't in any way make it harder to DOS. BTW, most
>> datacenter in the US do charge based on 95th%
>>
>>>
>>> If these are mobile users, I hope they never use any public networks
>>> (hotels, starbucks) where other subscribers can do things like ARP attacks
>>> to do MITM (and steal your calls; it might not be happening today, but it
>>> will be happening soon - as the social networking attacks demonstrate).  If
>>> you do have truly roaming users, I hope you use HTTPS (with validation of
>>> certs turned on) or a VPN (likely not an option of connecting to an ADSL
>>> site, due to bandwidth concerns).
>>>
>>>
>>>>
>>>> Or unless you have people who want to actually use the peer-to-peer
>>>> nature of SIP and call your SIP address.
>>>
>>> Once again, I'd use a border gateway at a datacenter or other location with
>>> significant bandwidth (not an ADSL line).  Even for a small shop.
>>>
>>>
>>>>
>>>> I suspect even munin would provide you such options. Not to mention any
>>>> more capable monitor.
>>>
>>> I already have a monitor (tied into nagios, which pages me if my fraud
>>> thresholds are exceeded), but I feel that is probably beyond the abilities
>>> of most of the people experiencing call fraud.  The people who know what
>>> they are doing with Unix and Asterisk are generally not the victims of
>>> this.  It would be nice if there was something built into Asterisk to alert
>>> on fraud - something that an end user with little Asterisk (or Unix)
>>> experience could utilize to be alerted to call fraud, which is easily
>>> detectable almost 100% of the time (too many calls for the organization ==
>>> call fraud).  And that is really what this is about - keeping someone from
>>> getting a $30,000 phone bill.  It certainly should be the part of any
>>> commercial offering.
>>>
>>> I stand by my statements.  Blocking people who were already denied access
>>> will not stop call fraud on systems with secure authentication.  You need to
>>> worry about the guy that has the trojan on the computer with the soft phone
>>> - the hacker who now has legit credentials (and will never be flagged by
>>> fail2ban when he uses them).  It's the bad guy you don't know about, not the
>>> bad guy you stopped, that is a danger.  As for bandwidth issues, I would
>>> never use an ADSL-based internet connection for VoIP - too easy for the bad
>>> guy to make a mess of things (or even just a misconfigured endpoint).  But
>>> if I did, I'd agree that some sort of fail2ban-like system would be helpful
>>> if you couldn't implement QoS.
>>
>> RUBBISH again, what is true is that fail2ban should be implemented ALL
>> the time, and something like QoS is helpful. You are living in some
>> cocoon wake up buddy.
>>
>>>
>>> People can take or leave my advice, but it is sound.  Practice security
>>> theater or actual security.
>>
>> No its NOT, like I said you live in a cocoon.
>>
>>>
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>>               http://www.asterisk.org/hello
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>               http://www.asterisk.org/hello
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>