[Dshield] firewall policy recomendations

Clint Byrum cbyrum at erp.com
Fri May 31 16:37:59 GMT 2002


On Fri, 2002-05-31 at 08:52, Stephane Grobety wrote:
> RW> Exactly.  Zero response = zero consumed resources (i.e., a drop).  Sending a
> RW> packet back = resource consumption, big or small.
> 
> You're forgetting that the TCP stack will automatically retry several
> time a timedout SYN. It it retries 3 times, you'll have two more
> packet traveling through the cable that is you send back a negative

Ahh, but with dropping, you're getting 3 SYN's seperated by some time.
Also, they're all coming on the "downstream" side of things. By sending
back a negative response, you are hitting your upstream. For Many(most?)
ADSL users, there is a *huge* difference in up vs. down.

You're probably right when talking about total bytes though. Look at
this tcpdump log:

09:21:07.327160 172.16.128.20.32796 > 172.16.128.23.999: S [tcp sum ok]
641541068:641541068(0) win 5840 <mss 1460,sackOK,timestamp 82301
0,nop,wscale 0> (DF) [tos 0x10]  (ttl 64, id 25265, len 60)
09:21:07.327454 172.16.128.23.999 > 172.16.128.20.32796: R [tcp sum ok]
0:0(0) ack 641541069 win 0 (DF) [tos 0x10]  (ttl 255, id 0, len 40)

The first packet is a SYN to port 999. The second is the RST. The SYN is
60 bytes long. The RST is only 40. So, a net of 100 bytes, vs a
potential 180.

There is another problem in this theory. Most scanners are not using
connect(). They're using some variation of the technique used by nmap in
its "stealth" scan. This means you'll probably only see one SYN to each
port.

This brings up another point. By not responding, you're not giving
nmap/queso/etc. anything to work with in determining your OS type.

And when talking about UDP ... who knows what you're going to be seeing.

> answer. Also, if you're using a remote syslog, you'll be having
> several more UDP packet generated. Also add the space for the log
> entries and the additional CPU to handle each SYN going through the
> filter.
> 
> RW> So if your main concern
> RW> is resource consumption, make it a big fat zero and your concerns are
> RW> resolved on the spot...
> 
> Not if you are being picky. You're probably not saving any resources
> by simply dropping the packet.
> 

Ultimately, you're probably right about *that*. However, seeing as there
is a greater security benefit to ignoring, vs. responding, you must
figure that resource in to things. I, however, can't even begin to
estimate what impact this has on one's overall resources. Anyone from
Lloyds of London reading? Those guys could probably figure it out. ;-)

> RW> In addition to having the side benefit of having the
> RW> other end sit there and twiddle its thumbs waiting for a timeout, one port
> RW> at a time, one IP address at a time.
> 
> That, however, is perfectly true. Although today's network scanners
> are heavily parallel, reducing the impact on the attacker, it does
> force him to use more resources to scan your IP/port range.
>

Unfortunately, with regards to this.. its not like the average attacker
is short on resources. I've run into complete moron "script kiddies"
that were in complete control of 300+ machines all over the net.
 
-- 

------------------------------
Clint Byrum
ERP.COM 




More information about the list mailing list