On Sun, Oct 31, 2010 at 2:40 AM, Tzafrir Cohen <span dir="ltr"><<a href="mailto:tzafrir.cohen@xorcom.com">tzafrir.cohen@xorcom.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Sat, Oct 30, 2010 at 07:33:23PM -0600, Joel Maslak wrote:<br>
<br>
> The CPU usage is trivial to deny them. As is the bandwidth usage, if<br>
> you are not sitting on a slowish broadband connection.<br>
<br>
</div>s/slow/assymetric/<br>
<div class="im"></div></blockquote><div><br><br>A 1mb/s uplink is slow nowadays. I suspect a symetrical 1mb/s SDSL line would also be having trouble with lots of registrations.<br><br>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.<br>
<br>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).<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> It also seems that the only way to make blocking effective is to<br>
> block everything by default except known endpoints. Blocking the<br>
> door knickers doesn't protect against a bad guy finding (not through<br>
> brute force) valid credentials.<br>
<br>
</div>Unless you have people on the road.<br>
</blockquote><div><br>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.<br><br>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).<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Or unless you have people who want to actually use the peer-to-peer<br>
nature of SIP and call your SIP address.<br>
<div class="im"></div></blockquote><div><br>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.<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I suspect even munin would provide you such options. Not to mention any<br>
more capable monitor.<br></blockquote></div><br>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.<br>
<br>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.<br>
<br>People can take or leave my advice, but it is sound. Practice security theater or actual security.<br>