Re: Stealth vs. Blocked
From: SysAdm (email@example.com)
- Next message: Whoever: "Re: Stealth vs. Blocked"
- Previous message: Jim Watt: "Re: Port 80 Open"
- In reply to: JR: "Stealth vs. Blocked"
- Next in thread: JR: "Re: Stealth vs. Blocked"
- Reply: JR: "Re: Stealth vs. Blocked"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "SysAdm" <firstname.lastname@example.org> Date: Fri, 31 Jan 2003 18:19:45 +0000 (UTC)
"JR" <email@example.com> wrote in message
> I have recently seen a lot of discussion involving the pros and cons of
> "stealthed" vs "blocked" ports.
> I have always been in favor of being blocked AND stealthed as opposed to
> just blocked, but I'm always open to new ways of thinking.
> Just for the hell of it, I went out on a standard XP box and pinged a main
> firewall that is "stealthed" (does not respond to ICMP), and promptly
> the good ol' "Request timed out"
> Then I powered down the cable modem to the main firewall, pinged it again,
> and once more rec'd "Request timed out"
> Script kiddies often tend to start their days with ping scans.
> Seriously, how do I know, with the above scenario, if a host/firewall is
> or down? I must be missing something.
ICMP as a protocol provides more than just echo reply and echo request. So
if a device does not respond to echo requests, this does not mean an ardent
hacker will give up.
Stealth, does not just apply to ICMP.
With the use of a fingerprinting tool such as NMAP, you can determine remote
OS and potentially patch levels, just by the return (or not) of packets.
This is exactly the reasoning behind things like FIN scans, If the tcpip
interaction provided by a service which sits on a tcp port is written to RFC
specs, you should expect an out-of-band FIN packet to be silently discarded.
This is but one example of intelligence collection, which is the first part
of any (real) hacking prognosis.