Concerns about wording of man blackhole

[Chuck Swiger]

Fabian Keil wrote:
> I set Followup-To freebsd-questions.

OK.

[ ... ]
>>>>> 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.
>>> As open ports still show up as open I don't see the protection.
>>> If some port are open, the attacker can assume that all the
>>> "filtered" ports are closed.
>> Most people use a firewall because they are running services (and
>> thus have open ports) which they do not want the rest of the Internet
>> to be able to connect to.
> 
> What does this have to do with "blackhole".  

The "blackhole" sysctl makes it somewhat harder for an intruder to figure out
which ports are really closed versus which ports are being filtered, and
how/where that filtering is being done.

Firewalls are used to make open ports appear "filtered" to external connection
attempts.  Someone who assumes that all filtered ports are really closed is not
making a correct assumption.

>> If there exists someone who assumes all "filtered" ports are closed,
>> well, wouldn't that fact demonstrate that the blackhole mechanism
>> does help...?
>  
> Help with what? From the attacker's point of view it makes little
> difference if a port appears as filtered or closed.

A knowledgeable security analyst or a blackhat trying to crack the network would
certainly not assume "closed" and "filtered" are the same thing.

Many networks have been compromised by poorly configured proxies which let
skillful intruders leapfrog around the firewall by abusing the HTTP CONNECT
method, including some high-profile examples at the NYTimes and other big-name
companies.

Other techniques include using the IP option for explicit source routing and can
fool poorly designed firewall configurations into thinking the connection comes
from the firewall itself, or some other trusted IP.

[ ... ]
>>>> These reconnection attempts will greatly slow down attempts to scan
>>>> ports rapidly.
>>> Which shouldn't result in a DOS anyway. The reconnection attempts
>>> will even increase the inbound traffic.
>> Yes, but to ports that aren't actually open.
>>
>> It's relatively cheap and easy to process such packets by just
>> dropping them, compared with processing them in a userland daemon.
> 
> What userland daemon?

The canonical example is inetd, but any process which listen()s on a port and
accept()s incoming connections would qualify as a "userland daemon".

>> And I'd much rather have malicious traffic heading towards a closed
>> port than towards a critical service.
> 
> Sure, but "blackhole behaviour" alone doesn't prevent malicious traffic
> from reaching critical services.

True.  Like the manpage said, "blackhole" isn't a substitute for a firewall.

>> [ ... ]
>>> Again I don't see the gain. Eventually the port scan will be
>>> finished and open ports found.
>> If you can flip a sysctl which increases the time it takes for
>> Slammer or Nimda or some other worm to scan through all of the IP's
>> on your network, the admins there have more time to respond, and
>> there is a better chance that AV software will get updates to block
>> the malware before too many systems get infected.
> 
> If you already have the firewall to drop those unwanted connections
> you might as well just reset them.

Unfortunately, a firewall can only affect traffic which passes by it.  There are
plenty of cases where someone opens an attachment in a malicious email, which
infects their system and causes it to scan/probe LAN IPs.

Having a firewall won't do a thing to protect you from local scans.  Using
"blackhole" on internal machines can help this scenario somewhat.

-- 
-Chuck