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 <jmas...@antelope.net> wrote: > On Sun, Oct 31, 2010 at 2:40 AM, Tzafrir Cohen <tzafrir.co...@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
