On Sun, Oct 31, 2010 at 1:39 PM, Joel Maslak <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> On Sun, Oct 31, 2010 at 2:40 AM, Tzafrir Cohen <[email protected]> >>> 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 > -- _____________________________________________________________________ -- 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
