Concerns about wording of man blackhole

[Fabian Keil]

I have problems with parts of the blackhole man page on RELENG_6.

|Normal behaviour, when a TCP SYN segment is received on a port where
|there is no socket accepting connections, is for the system to return a
|RST segment, and drop the connection.  The connecting system will see
|this as a ``Connection refused''.  By setting the TCP blackhole MIB to a
|numeric value of one, the incoming SYN segment is merely dropped, and no
|RST is sent, making the system appear as a blackhole.  By setting the MIB
|value to two, any segment arriving on a closed port is dropped without
|returning a RST.  This provides some degree of protection against stealth
|port scans.

In which way does this protect against stealth port scans?
If the port is open it will be shown as open, if it's closed
it will be shown as filtered (at least in nmap).

A closed port doesn't need protection, and an open port
doesn't get any protection by setting the TCP blackhole MIB.

|The blackhole behaviour is useful to slow down anyone who is port scan-
|ning a system, attempting to detect vulnerable services on a system.  It
|could potentially also slow down someone who is attempting a denial of
|service attack.

I don't understand why the "blackhole behaviour" would slow down
a DOS attempt. Is there a known DOS vulnerability in FreeBSD
which can be exploited by trying to connect to a closed port? 

I can only think of filling up the connection with useless traffic,
but this is possible with every OS and turning the attacked system
into a so called blackhole wouldn't make a difference unless the
uplink is slower than the downlink and the attacker really floods
closed ports instead of open ones. 

|WARNING
|The TCP and UDP blackhole features should not be regarded as a replace-
|ment for ipfw(8) as a tool for firewalling a system.  In order to create
|a highly secure system, ipfw(8) should be used for protection, not the
|blackhole feature.
|
|This mechanism is not a substitute for securing a system.  It should be
|used together with other security mechanisms.

I don't understand how anyone could see the "blackhole features" as a
replacement for a firewall. I even think the warning is misleading
because it gives the idea the "blackhole feature" would somehow
increase the systems security a little bit, but just not enough. 

AFAICS the only thing it does is to decrease traceroute's
usefulness and to turn closed ports into filtered ports which
slows some kinds of port scans down for a few seconds.

Like moving standard ports no non-standard numbers it doesn't
hurt, but it doesn't increase security either.

I think the warning should rather note that the name "blackhole"
is misleading and that if dropping is desired it should
be implemented in the firewall if possible.

A system running with the "blackhole" variables set and with no
ports open still responds to ICMP echo requests. Even if it
wouldn't, the attacker would still know the system is up,
otherwise he would get an error message by the last router
before the "blackhole".

|SEE ALSO
|ip(4), tcp(4), udp(4), ipfw(8), sysctl(8)

pf(8) should be mentioned as well.

If you want to make port scanning harder, you can use it's
os fingerprint capabilities to lock nmap out. Of course
this doesn't make the system more secure and it probably
won't take long until nmap disguises itself, but for nmap 4.0
it works.

Any thoughts?

Fabian
-- 
http://www.fabiankeil.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-doc/attachments/20060213/3bf9b54b/attachment.sig>