Christopher, IP filtering is something that needs to be legally mandated and put in place at both ends. Any tier-2/3 provider should be held accountable for any fraud's that they enable their customers to commit, since there is no other technical point of responsibility possible. As to spoofed IP's that also is an issue, and the failure of the ISP's to put in place an infrastructure where they could enact better controls is part in parcel to their public denial of responsibility for what their customers do. But I think that those days are rapidly coming to a close, and the Network Providers will be called to task. As to TCP/IP and the inherent design flaws that allow people to spoof it, those to are much the responsibility of the "networking community" as a whole as well and need to be addressed therein. You nor any of the ISP's may like this but the facts of the matter are pretty clean and easily discerned and they all point to the Governance Model for developing and releasing protocols whole cloth on the Internet, no matter what they enable people to do. Its time to take a close accounting of what this "Internet" thing really is and put some stronger legislation in place. Todd Glassey ----- Original Message ----- From: "Christopher L. Morrow" <chris@UU.NET> To: "Stewart, William C (Bill), RTLSL" <billstewart@att.com> Cc: <nanog@trapdoor.merit.edu> Sent: Friday, January 17, 2003 6:29 PM Subject: Re: FW: Re: Is there a line of defense against Distributed Reflective attacks?
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: 'nanog-post@trapdoor.merit.edu' Subject: Re: Is there a line of defense against Distributed Reflective attacks?
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
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
hosts.) 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 :)