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?
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 Ah, so you're only looking to stop non-TCP attacks. How long do you thinkA 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. 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...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. 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. EvenSo 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. 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.Sure, and spoofing the special "return traffic" will be obvious only to the other end, not the transits in the middle.
|