mailing list archives
Re: What do you want your ISP to block today?
From: Iljitsch van Beijnum <iljitsch () muada com>
Date: Sat, 30 Aug 2003 12:39:09 +0200
On zaterdag, aug 30, 2003, at 10:57 Europe/Amsterdam, Ray wrote:
So? SMTP uses TCP, TCP generates incoming ACKs for outgoing data, so
Ah, so you're only looking to stop non-TCP attacks. How long do you
before the majority of DOS are TCP based? SYN floods result in ACKs,
just also result in the server being useless. If an ACK is all you
you won't catch much of anything.
A SYN flood will either stay within the resource limits of the (network
to the) target host, or it won't, and either the source addresses are
legitimate, or they aren't. Only in one of the four combined cases
there will be return traffic for most packets. So this should have
beneficial effects most of the time. Also, when the target host
implements filtering there won't be return traffic so then it should
work even better.
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 did a little test using Quicktime and I see 10 packets per second
return traffic. But the port numbers don't match the traffic flowing in
the other direction...
The amount of return traffic isn't important, as long as there is
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.
if I know ping is working, that doesn't mean I know HTTP or SSH or RTSP
or SMTP are getting through.
So what's the problem? You open an HTTP, SSH, RTSP or SMTP session and
see if you get a response. If you do, no problems. If you don't, the
"suspicious traffic going on" counter increases. If you keep hammering
on a non responsive server then after a while something is going to
happen to your port. I think rate limiting outgoing traffic to very low
levels (5 kbps or so) is probably the best automated way to handle this.
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.
Hm, good point. Maybe it's easier to set the thresholds such that some
limited port scanning doesn't trigger any action. It's not like any of
this is going to make targeted portscanning completely impossible
anyway, it will mostly make sweeping the net for vulnerable systems too
slow to be useful.