AW: [Dshield] firewall policy recomendations

Kenneth Porter shiva at sewingwitch.com
Fri May 31 13:25:55 GMT 2002


On Fri, 2002-05-31 at 01:08, Graham K. Dodd wrote:
> What is the effect on the firewall / network when you tie up a probers
> attack ?

A TCP connection starts with a SYN packet sent from client to server.
The server then sends an ACK packet back, and a final packet is sent
from client to server to complete the connection. Real data flows after
that.

If you don't send the ACK back in response to the SYN, the client just
waits until a timeout expires. This is typically several seconds.

If a scanner is written in a simple-minded single-threaded way, then the
prober is forced to wait for the timeout to expire before he can go on
to his next victim. It doesn't cost *you* anything but it does cost him
the extra time.

A multi-threaded scanner can have several probes in progress
simultaneously, so he isn't hurt much by the wait for one victim's
response. One could in principle have about 64k SYN's out waiting for
responses at once, as that's the number of source ports available for
the client side of the connection. Fortunately, most scanners don't do
this.

Additionally, a good scanner would tweak the ACK timeout to make a rapid
pass over the address space of interest, and start the real attack on
the fast-responders first.
 
> Some of us don't even have a partial T1 and run on a minimum budget so we
> don't want to waste our resources just to annoy hackers who obviously has
> lot's of time to waste anyway..........
> 
> BTW I'm not flaming Kenneth and his policies, I want to know whether I can
> adopt this sort of policy without affecting my companies "small, but very
> important" network.

No offense taken. If you're not familiar with how TCP works, I can see
why you might think that a "reverse DoS" might be expensive. But in fact
the drop policy costs you less than the reject policy, since the latter
requires that you consume upstream bandwidth to reply, and it encourages
the prober to take more interest in you and further use your resources.

BTW, you should also turn on "syn cookies" if your OS supports them.
(For Linux, this is a setting in /proc.) Without syn cookies, your TCP
stack can be tied up by a DoS'er hitting your system with a "syn flood",
which ties up kernel resources as the kernel waits for the 3rd packet of
the connection establishment handshake that will never come. A friend
demonstrated this to me with a syn flood app a few weeks ago, which shut
down my connection. I hadn't realized I'd not turned on syn cookies, and
this quickly revealed the oversight. I turned it on and a re-test of the
syn flood proved completely ineffective. My gateway just ignored the
bogus packets.




More information about the list mailing list