On Sat, Aug 30, 2003 at 10:28:11AM +0200, Iljitsch van Beijnum wrote:
On zaterdag, aug 30, 2003, at 09:54 Europe/Amsterdam, Ray Wong wrote: So? SMTP uses TCP, TCP generates incoming ACKs for outgoing data, so no problems there.
Ah, so you're only looking to stop non-TCP attacks. How long do you think before the majority of DOS are TCP based? SYN floods result in ACKs, they just also result in the server being useless. If an ACK is all you need, you won't catch much of anything.
Christopher L. Morrow's mention of asymmetric routing for multihomed customers is more to the point, but if we can solve this for all those single homed dial, cable and ADSL end-users and not for multihomed networks, I'll be very happy.
Yes, I'd be happy too, but your original point wasn't terribly specific, and doesn't really address typical traffic patterns. Now that it's clear, how about a more obvious one: Streaming services are primarily assymetric, and plenty of them use UDP. There may be a little return traffic, but nothing you're going to predict. I suppose you can call for the end of UDP based streaming protocols. Good luck. It took long enough for people to get used to moving away from NFSv2.
attack. If someone sends traffic to very many destinations and in more than 50 or 75 % of the cases nothing comes back or just an ICMP port unreachable or TCP RST, 99% chance that this is a scan of some sort.
Sure, and I scan my systems from outside all the time. I'm looking for validation that my system has NOT started listening on ports I don't run services on. It's called external monitoring, and is rather useful in letting me get a good night's sleep.
So which do you prefer: nobody gets to scan your systems from the outside (including you) or everyone gets to scan your systems from the outside (including you).
So let's see, my choices are: 1) both cracker and I know if I've been cracked by cracker. 2) cracker knows I've been hacked, I have to wait until my server is now an active participant in screwing the rest of the internet, AND I then have to actively be inspecting the system to see where he's failed to cover his tracks well. Yes, the choice is wonderful. Obscurity has done so much to enhance reliability, security, you name it.
but I'd still need a way to verify my sites can be reached from other places.
They have something for that now. It's called "ping".
Yes, and ICMP echos are already consistent in being blocked (not). This line is relevant:
If you want to know how TCP is working to a destination, you have to use TCP to test it.
It's an example. I need to generate traffic to the various ports. Even if I know ping is working, that doesn't mean I know HTTP or SSH or RTSP or SMTP are getting through. Relying on ping to verify outside connectivity is great for providing a ping response server, but not many customers seem interested in paying for that.
As I mentioned above: this will not impact TCP at all because TCP generates return traffic. I'm sure there are one or two UDP applications out there that don't generate return traffic, but I don't know any. The only problem (except asymmetric routing when multihomed)
UDP generates return traffic, but there's nothing to predict any degree of symmetry. Indeed, likely different last mile, local congestion, et al virtually guarantee that I can't predict how much return traffic there will be. Look inside, and they all come down to 'push a bunch of UDP out. pray very hard that enough gets to the other side. hope that other side can tell us if not.' ICMP likewise may or may not result in return traffic. At any level, things are almost never completely tit-for-tat.
Scans by themselves certainly aren't inherently dangerous.
It should be possible to have a host generate special "return traffic" that makes sure that stuff that would otherwise be blocked is allowed through.
Sure, and spoofing the special "return traffic" will be obvious only to the other end, not the transits in the middle. -- Ray Wong rayw@rayw.net