What do you want your ISP to block today?

Sat Aug 30 10:39:09 UTC 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.