North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: FW: Re: Is there a line of defense against Distributed Reflectiveattacks?
- From: Christopher L. Morrow
- Date: Fri Jan 17 21:31:32 2003
On Fri, 17 Jan 2003, Stewart, William C (Bill), RTLSL wrote:
> -----Original Message-----
> From: Stewart, William C (Bill), RTLSL
> Sent: Friday, January 17, 2003 5:35 PM
> To: 'firstname.lastname@example.org'
> Subject: Re: Is there a line of defense against Distributed Reflective
> Many of these attacks can be mitigated by ISPs that do
> anti-spoofing filtering on input - only accepting packets from user ports
Sure, but this is a proven non-scalable solution. HOWEVER, filtering as
close to the end host is scalable and feasible... do it there, it makes
MUCH more sense to do it there.
> that have IP addresses that are registered for that port,
> and not accepting incoming packets from outside their network
> that claim to be from inside (except maybe from registered dual-homed hosts.)
> This cuts down on many opportunities for forgery,
> and means that SYN Flood attacks have a much more limited set of
> addresses they can forge (e.g. an attacker or zombie can only
> impersonate other ips sharing its /24 or /29,
> so it can't pretend to be its victim in a reflection or smurf attack.)
> That doesn't stop all reflection attacks; a zombie on a network
> that doesn't do anti-spoofing can send SYNs to a big server on a
> network that also doesn't anti-spoof, so the server will still SYN-ACK
its not the 'server' that needs 'anti-spoof' its the end host, the machine
in your livingroom that is on a cable modem for instance... the server in
this instance is a simple, innocent, machine doing its business.
> to the victim. This cuts out a lot of potential zombie/server pairs.
> If the server that's being used for reflection is someone the
> victim would often talk to, that's a problem
> (you'd rather not block connections to Yahoo),
> but if it's someone the victim doesn't care about talking to
> (like router23.example.net) you don't mind blocking it.
> (Also, why is router23.example.net SYNACKing somebody it doesn't know?)
This is an interesting point. The routers shouldn't really syn-ack (in
this example) bgp from 'unknown' places... unless you are a neighbor you
get squat, or that would be a nice feature, eh? :) For some folks, the
problems aren't confined to just bgp, telnet or ssh on routers are also
problemmatic, vty acl's are important :)
> But there are probably 20 million web servers or Kazaa or IM clients out there,
> and probably half of them are on networks that don't spoof-proof,
> so blocking those is much tougher than blocking the big ones.
> And next stop - reflection attacks using big domain servers...
Hmm, I'm not sure, again, that the spoof proof needs to be on the kazaa
server network, it needs to be on the network where the originating
attacke is, preferrably as close to that host as possible, like it's
default router... Now, the problems with 60million kazaa clients openning
the floodgates on you are a whole nother problem :)