mailing list archives
Re: What do you want your ISP to block today?
From: rayw () rayw net (Ray)
Date: Sat, 30 Aug 2003 01:57:06 -0700
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
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
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
Sure, and spoofing the special "return traffic" will be obvious only to
the other end, not the transits in the middle.
rayw () rayw net