North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: What do you want your ISP to block today?

  • From: Iljitsch van Beijnum
  • Date: Sat Aug 30 06:41:46 2003

On zaterdag, aug 30, 2003, at 10:57 Europe/Amsterdam, Ray 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.
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 _some_.

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.
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
through.

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.