Re: DNS issues various
On Thu, 24 Oct 2002 [EMAIL PROTECTED] wrote: On Thu, 24 Oct 2002 18:01:44 -, Kelly J. Cooper [EMAIL PROTECTED] said: So, seven years of hardening hosts against SYN attacks. Five years of trying to get people to turn off the forwarding of broadcast packets. Three years of botnets generating meg upon meg of crap-bandwidth. Where are the super-geniuses? You know, most bars have bouncers at the door that check IDs. Sure, they're not perfect, but the bartender can usually be pretty sure the guy ordering a beer is over 21. The average bar isn't run by a soooper-genius. But it's still considered fashionable to let packets roam your network without an ID check at the door. Yeah and how's that working so far? soooper-genius solutions aren't going to help any when there's a lot of address space that's managed by Homer Simpson But there will always be address space managed by Homer Simpson. And that's part of my point - we can't fix everybody's networks. There will always be broken/misconfigured networks run by the willfully ignorant. We've been in an arms race for years. They come up with something, we come up with a response, they come up with something else, we scramble to find router OS code that doesn't crash, etc. It's just back and forth, back and forth. All I'm advocating is breaking out of that pattern. Kelly J. -- Kelly J. Cooper- Security Engineer, CISSP GENUITY- Main # - 800-632-7638 Woburn, MA 01801 - http://www.genuity.net
Re: DNS issues various
On Thu, 24 Oct 2002, Richard Forno wrote: I'd posit it's impossible to PREVENT a DDOS attack -- as such, as we did when they first manifested themselves in 1999, we need to develop response plans capable of meeting the onslaught and mitigating its impact so that things continue to function, even if they're degraded somewhat. 1999?! Doesn't anybody remember the massive SYN attack against Panix in 1995? Or that tfreak released smurf.c in July of 1997? (And was it fraggle or papasmurf that came the summer of the following year? Whichever one it was, the other came out within six months after that.) And those are just the ones I remember since I moved away from Rutgers and started working in the BBN NOC - I'm sure there were others even before that. (Not counting accidental operational incidents like the AS 7007 routing chaos in 1997 or the AS 8584 identitical issue a year later.) 1999 was just when Distributed DoS started getting a little airplay. We'd already had four fruitless years of dealing with DoS attacks by the time that happened. What would be wonderful is a radical change in the way we think about DoS attacks. It would be fabulous for someone (or a group of someones) to come up with a completely different way to approach the problem. I wish that I could be the person who does that, who sparks that change, but in the seven years I've been thinking about it, nothing's come to mind. So, seven years of hardening hosts against SYN attacks. Five years of trying to get people to turn off the forwarding of broadcast packets. Three years of botnets generating meg upon meg of crap-bandwidth. Where are the super-geniuses? Kelly J. -- Kelly J. Cooper- Security Engineer, CISSP GENUITY- Main # - 800-632-7638 Woburn, MA 01801 - http://www.genuity.net
Re: what's that smell?
Nope. As previously established, there are ISPs out there using RFC1918 networks in their infrastructure. Also, egress filtering is NOT easy, so even those ISPs doing it may not be able to do it universally. Plus, lots of attacks these days are mixing spoofed and legit traffic, or doing limited spoofing (i.e. picking random addresses on the LAN where they originate to make it past filters). Kelly J. On Tue, 8 Oct 2002, Iljitsch van Beijnum wrote: On Tue, 8 Oct 2002, Chris Wedgwood wrote: FWIW, almost nobody filters rfc1918 packets outbound and a good percentage of ISP customers bleed these something terrible Actually, that's a good thing. This makes it trivial to detect which peers aren't doing egress filtering. If people just filtered RFC 1918 space, everything would just look better, but the underlying problem wouldn't be solved: it would still be possible to launch very hard to trace or stop denial of service attacks from those networks.
Re: UUNET instability?
On Apr 25, 5:34pm, blitz wrote: Subject: Re: UUNET instability? * *At 16:59 4/25/02 -0400, you wrote: * *On Fri, 26 Apr 2002, Lionel wrote: * * * A butterfly in outter mongolia flapped its wings will probably be cited * before long... * * telnet bofh.engr.wisc.edu 666 * *The Archive of BOFH is here: * *http://bofh.ntk.net/Bastard.html Or you can buy the books: http://www.plan9.org Kelly J. (not affiliated, just a fan) -- Kelly J. Cooper- Security Engineer, CISSP GENUITY- Main # - 800-632-7638 3 Van de Graaff Drive - Fax - 781-262-2744 Burlington, MA 01803 - http://www.genuity.net
Re: How to get better security people
On Mar 26, 2:15pm, Sean Donelan wrote: Subject: Re: How to get better security people * *On Tue, 26 Mar 2002, Tony Wasson wrote: * If I was looking for top security talent, what would I ask for whether * I was hiring directly or outsourcing? * * I agree with Steve Wilcox, incidents are important. I would ask for a * description of the 3 most interesting incidents they've ever worked on, and * what they contributed. * *I'm sorry, but that's confidential information and I can't disclose it. * *Would you hire a security person, who will likely be involved in the *most embarrassing slip ups your company makes, if he tells people about *interesting incidents at previous employers. * *Maybe, it depends on what he says. Long ago and downstairs, when I used to interview people for Operations Security, I asked each candidate whether s/he had ever handled a Denial of Service attack or an intrusion, and if so, could they describe in general terms how they handled it? I would specifically ask them to NOT provide any identifying info, just the process (and an explication of the attack) so I could gauge their understanding of the situation. I also had a short list of other questions that I used to try and get a feel for the person's security minded-ness (my term, I invented it a'ight?). Because when it comes to ISP security, there's a very limited pool of talent so candidates are unlikely to come in with the right skillset native. But if the person comes in and s/he is someone who thinks about scenarios and contingency plans and has a working knowledge of networking/computing, then I can teach him/her everything else. Kelly J. -- Kelly J. Cooper- Security Engineer, CISSP GENUITY- Main # - 800-632-7638 3 Van de Graaff Drive - Fax - 781-262-2744 Burlington, MA 01803 - http://www.genuity.net
Re: Telco's write best practices for packet switching networks
Sean, On Mar 6, 7:56am, Sean Donelan wrote: Subject: Telco's write best practices for packet switching networks * *After the SNMP excitement I asked if anyone had suggestions on how *to architect or design a backbone network to be less suspectible to *problems. It turns out the telephone industry has written a set of *best practices for the Internet. Uh huh... The report is 122 pages long and contains a review of how they took existing Best Practices, collected mostly from the previous NRIC, and refined them (based on criteria outlined on p.22). Then performed a SURVEY of what people thought about the 256 BP recommendations they had, covering Service Providers of multiple services and equipment suppliers, all somehow related to telecommunications. The BPs themselves range from: 5-501 Network Operators should report problems discovered from their testing to the Equipment Supplier whose equipment was found to be the cause of problem. ...to... 5-758 If 911 call completion is affected, test calls should be made by the Server Provider to the PSAP(s) to assess the impact. Once service is restored, the Service Provider should make multiple 911 test calls to ensure they complete properly. (See Appendix A) I don't think they were focusing on BPs for the Internet per se so much as believing that many BPs that work for PSTN should also work for the Internet. Whether or not they are correct is a (if not THE) challenging matter for debate. *Focus Group 2.A.2: Best Practices on Packet Switching. Karl Rauscher, *Lucent Technologies *http://www.nric.org/pubs/index.html * * Mr. Rauscher gave an example of the kind of information to be found * there. The best practice used in the example states that critical * packet network elements such as control elements, access in signaling * gateways and DNS servers, should have firewall protection such as * screening and filtering. One hundred percent of the respondents * indicated they were implementing this best practice. * *Cool, who has an OC-192 firewall on their control elements? What is *a control element, is that the same as a router or is that a signaling *gateway? Damned flat internet... can't tell if you're kidding or not. I'm guessing that you are, but just in case... Control elements are the router-like bits or computer-like bits that actually control management of the switch (i.e. you connect to that part in order to reconfigure, upgrade, etc. the element). Most ISPs have a comparable set-up wrt modems/terminal servers for managing their network elements - same dealy, but ISPs can choose between inband OOB whereas the telcos can't. (Or couldn't, til recently, when Net/Bell convergence started urging the market toward big damn fiber switches with in-band mgmt tools.) So - in the world of telco, the control elements are JUST OOB. Since you literally can't reach them inband, the OOB element mgmt can be done through modems or a separate network which is firewalled off from the rest of the Internet. That's what they're talking about in your excerpt. What I find interesting is that I've heard a lot of cage rattling to take the Internet in this direction, i.e. stop managing it in-band where all the kiddies and the terrorists can get at it and start managing it OOB. Hide it, shut it away, don't route it, etc. nevermind what a pain it is to manage TWO networks... nevermind how much flexibility you lose. (Sorry, my bias is showing.) And I'm hearing this from BOTH NetHeads AND BellHeads. Kelly J. -- Kelly J. Cooper- Security Engineer, CISSP GENUITY- Main # - 800-632-7638 3 Van de Graaff Drive - Fax - 781-262-2744 Burlington, MA 01803 - http://www.genuity.net
