Concerns about wording of man blackhole

[Chuck Swiger]

Fabian Keil wrote:
> |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?

Returning a RST tells the scanner that the port is definitely closed.
Returning nothing gives less information.

> 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).

Yes; in other words, nmap is unable to tell whether the port is being filtered
or is actually closed.

>|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.

nmap is extremely well written, and can scan un-cooperative hosts better than
most other programs will.  Anything which uses a protocol-compliant TCP/IP stack
will retry dropped connections several times if no answer is forthcoming, and
will even do things like try to make a connection without enabling any TCP or IP
options normally set by default.

These reconnection attempts will greatly slow down attempts to scan ports rapidly.

> Is there a known DOS vulnerability in FreeBSD
> which can be exploited by trying to connect to a closed port? 

Sending highly fragmented packets ("the Rose attack?") used to be quite
effective against FreeBSD, although Andre Opperman or someone has improved the
way FreeBSD handles fragment reassembly to be more efficient since then.

> 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. 

Network bandwidth is not the only finite resource used in processing network
traffic: exhausting memory of making the OS consume excessive amounts of CPU are
also DOS mechanisms.

> |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.

Some people are easily confused.  :-)

> 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.

Something using the OS to do TCP/IP is going to be slowed down by roughly an
order of magnitude, which includes many malware programs like worms.

[ ... ]
> 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".

This is right.

> 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?

It's very easy to recognize nmap connections requests due to the unique TCP
options it sets ("WNMTE").  It's not hard to identify generic port-scanning if
you keep a histogram of incoming SYN's per remote host and notice when it hits
more than 10 or 100 distinct ports.

-- 
-Chuck