Re: Blocked incoming ICMP, getting outgoing ICMP [3] Destination Unreachable
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


comp.security.firewalls archive

Re: Blocked incoming ICMP, getting outgoing ICMP [3] Destination Unreachable

From: Sebastian Gottschalk <seppi@seppig.de>
Date: Sat Feb 25 2006 - 23:50:18 CET

Moe Trin wrote:

> If you think that not responding to any Internet traffic is the way to
> go (Gibson's so-called "stealth mode"), you really need to look at the
> concept of traceroute again, to see why such action is a waste of your
> bandwidth.

IBTD. Blocking responses in some cases actually saves bandwith.

Think about all those Blaster-, Sasser- and SQHell-infected Windows
machines. They're sending you SYN requests on Port 135, 445 and 1434 -
they simply keep on sending 4 requests simulataniously and then take the
next target, not caring at all about a RST/ACK oder Port Unreachable.
And that doesn't just apply to malware, but also to certain P2P clients.

Or what about ports <1024 except of DNS, identd and wanted services? I'm
no server, and if anyone accidently believes I'm one they're so badly
wrong that I don't care sending them a notice. As the port scans and
other random bunch is a much bigger source, you can easily filter that
away without any problems.

But one should only blacklist bad examples as told above, as in general
responses do have their usage. Just take a look at eBay's load balancing
- when connecting, you're receiving certain TCP connections from certain
servers from all over the world. Respond to them, and they'll figure out
who got the fastest response and will redirect you there. Don't respond
and you'll be redirected to the default server, where all other "no
response" suckers are bundled, and which is slow for exactly that reason.
Received on Mon May 1 00:52:59 2006