>>>>> "sc" == Security Coordinator <securityat_private> writes: >> Do you think we should be reporting snmp scans to ISPs >> or just a waste of time? sc> Well, one way or another ISPs need to be fingered. I don't see sc> other people in the security community saying much, so maybe its sc> time someone started. ISPs ARE RESPONSIBLE for a lot of the sc> security problems on the net today. How could someone do SNMP sc> scans of a network unless ISPs let them get away with it? Actually sc> this is a bad example, there is legitimate SNMP traffic and it sc> would be hard for them to know, but then why is it we see so many sc> spoofed packets around? There should be ZERO of them on the sc> net. Every router knows what addresses to expect to be inside vs sc> outside. sc> I won't belabour the point, but YES, you should not just report it sc> to the ISP, you should let everyone know where attacks come sc> from. What we REALLY need is a database and system good enough to sc> understand the topology of the net and processes attack reports in sc> a sophisticated enough way that we can say things like "if this sc> router was filtering like thus, this would be impossible" and if sc> an ISP won't configure their equipment properly, then they can be sc> held liable. Please get a clue. They're free. We sell bandwidth. We sell unfiltered bandwidth. There are good reasons for doing so, and I'm willing to discuss them with you in another forum, perhaps off list. I am not responsible for the security of your systems. I am not responsible for the breakins that result from your poor security. I am not responsible for the spoofed packets that the script kiddies source from your systems. Have you ever tried filtering on a Cisco at OC-48 rates? It ain't pretty. How about maintaing access lists on a per-customer basis for on a router that terminates 3000 customers, when you cannot apply filters on a sub-interfaces? What about assymmetric routing, multi-homed customers, dynamic routing changes? Antispoof filtering is a good thing. I do it at home. But it is a technology that is not applicable to Internet backbones. It does not scale. It is something that should be done on the edges, as close to the stub networks as possible. The backbone is not a stub network. sc> Every router knows what addresses to expect to be inside vs sc> outside. Maybe on your routers. This is not true in general. For the vast majority of routers, there is no "inside" or "outside", just a bunch of interfaces, running really hot. I'm in Virginia. Does that make California "outside"? We try to help our customers out when they're in trouble. We try hard. But your statements above are flat out wrong. They were expressed in ignorance, and you should rectify that ignorance before making such sweeping statements again. As someone who actually works for a middling large ISP, in security, yes, you should report these scans. But only to the ISP that sells service to them. Don't report them to your ISP, unless it's a service impacting attack. Traceroute to them, identify the router above their network. Contact the people at the source network, they may well be unaware of the scan/attack. Most of these things originate from compromised systems, and the admins in charge are glad to be notified. If that yields no results, contact their ISP. Such scans are generally a violation of the AUP (acceptable use policy), and can be dealt with in that context. Mr. Security Coordinator, I suggest you change your gecos field to something more personal. If you would like to obtain service with the terms you specified above, I'm sure, if you shopped around long enough, you'd find an ISP willing to oblige you. Expect to pay a hefty premium for it though. ericb -- Eric Brandwine | It is hard to believe that a man is telling the truth UUNetwork Security | when you know that you would lie if you were in his ericbat_private | place. +1 703 886 6038 | - H. L. Mencken Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Fri Feb 22 2002 - 13:43:23 PST