On 7/1/08, Steve Totaro <[EMAIL PROTECTED]> wrote: > > > "NOT sent from my iPhone or Blackberry" very funny, you could add the > typed with my thumbs line too. :)
I know, although it looks like I'll be waiting in line in a couple of weeks for iPhone 2.0/3G... I just need to remember to update my prefs not to include that in the sig line! > As far as your DoS script, do you have a general idea on how the > conept would work? Would you just drop the packets from the offending > IPs? Sort of... I would make it configurable to allow for dropping, rejecting (using ICMP unreachable for UDP, TCP RST for TCP), and logging. Although I tend to not like anything other than a silent drop for what is "attack" traffic. I'm not going to be the sucker that's going to saturate my upstream bandwidth by actually responding to DoS traffic. DROP by default, I say. Same thing goes for logging... Using disk I/O and space for attack traffic only makes sense if you've got a properly tuned and dimensioned configuration and/or you're running on a separate box. The hashlimit extension already provides for a /proc interface that (along with standard iptables accounting) could provide for enough information without using something like the LOG target. Ideally you could get really fancy and report the source of these attacks and block them at your upstream (via BGP blackhole or some other means). As long as we remember that any large enough, sophisticated enough DoS/DDoS WILL TAKE YOU OUT unless you have ample resources to deal with it. Even then if one of the larger botnets comes after you, good luck! ;) > For security, how about an authentication retry setting in the sip > configuration? After X amounts of failed auth or registration > attempts, block IP for Y amount of time. It would seem fairly easy to > do using realtime with DB entries for IP blocks and expiration. Then > a quick query of the same tables would allow an admin to put in > permanent rules on a firewall or ACL and also contact that ISP's abuse > dept. My main concern with implementing these protections in Asterisk is the expense of starting the thread to deal with the (SIP) traffic in the first place. Although I'm not aware of the specifics, Asterisk reserves a bit of resources for each open SIP channel. Ideally I'd intercept attack traffic in the kernel (or better yet in the kernel on a different machine) before it ever got a chance to use any Asterisk resources in userland. Adding any realtime queries or other DB foo would only serve to amplify the effects of the attack (exceed max number of connections in MySQL, die). Of course the other benefit with a generic Linux solution is the same protections (script) would work for any other SIP application or network device. -- Kristian Kielhofner NOT sent from my iPhone or Blackberry _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
