|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: DOS?
On Sat, 25 Jan 2003, Christopher L. Morrow wrote: > > wants to log for a while and then counts hits against the cache until it > only for identical packets... so source A:123 -> Dest B:80 x500000 packets > gets logged 'once'. One log for the first packet and update logs at 5 min > intervals (which may be setable in some ios command, which may only exist > in S-train code). If the attack is randomized, sources, destinations, or > ports... there is effecively a new 'flow' for each packet and thus a new > log message for each... (again, in S-train code or 12.0(21)+ code this is > rate-limited to the RP and thus to the logs... somewhat atleast) It seems the flow recognition isn't that strict but I might just have been lucky. > > actually logs. This should work very well, and it does as per my tests > > on a heavily loaded 4500 router. So why would one type of IOS do this > > right and another version that isn't immediately recognizable by the > > version number as inferior do it wrong? > S-train code has specific features that don't get propogated to other > trains because they aren't 'required' there or aren't applicable, or not > asked for. Lovely when others decide what you require. > > I think today's events show that CPU-based routers have no business > > handling anything more than 1 x 100 Mbps in and 1 x 100 Mbps out. If a > > box has 40 FE interfaces or 4 GE interfaces, at some point you'll see 4 > > Gbps coming in so the box must be able to handle it to some usable > > degree. > that may be, but CPE isn't normally vendor J for t1/t3/oc3 customers... CPE for T1 would be 2500, T3 3600, OC3 7200 or some such. All are fine for day-to-day stuff but don't pack enough power to handle today's events at line rate. But the difference is small enough that it can be remedied by simply using faster CPUs. Those were available at the time the boxes were introduced, but I assume a faster CPU would have increased the cost price too much. > never mind dsl/dial/cable customers, eh? Those are slow enough to be done in software easily. > The vast majority is cpu based > equipment. Whether or not that's a good thing is immaterial, no one is > going to upgrade all ruouting gear overnight :( (or in 2 years as we've > seen) People are buying GE equipment left right and center too. It doesn't make much sense to have more computing power in the ethernet chip (GE over UTP takes a lot of processing power) than in the chip doing the routing. Maybe its possible to find some middle ground, for instance by doing some basic flow recognition and rate limiting in hardware but the actual routing in software. That way, you can build a GE CPE router that can do 100 kpps which is enough for regular traffic but still have some protection when there is a 1.4 Mpps DoS attack which would otherwise have killed the CPU. > > That's why I want the logging: to see which customer is spewing out the > > garbage. (-: > well, then.. log vs log-input :) cause log-input is more processing and > thus more pain. (and if its 'inbound' on interfaces the 'log-input' is > kinda pointless, eh? Good point. The reason it's there is that I didn't know what I was dealing with when I enabled this logging and I wanted to see the MAC addresses in case the source IP addresses were spoofed.
|