Archived from groups: comp.security.firewalls (
More info?)
In the Usenet newsgroup comp.security.firewalls, in article
<MPG.1d82ecb0688400bc9896d5@news-server.nyc.rr.com>, louise wrote:
>I just did a test with Shields Up and all the tested ports came
>back "stealth"
Gibson's marketing babble. You can prove it yourself by using traceroute
(or the microsoft lame imitation TRACERT). This is a trace to a stealthed
host (I've deleted the hostname normally seen in the first column for
space and privacy reasons, and masked the first octet of the address to
avoid having fools attack this particular set of hosts):
14 (XXX.117.52.49) 329.807 ms 309.331 ms 309.864 ms
15 (XXX.181.218.10) 329.744 ms 329.413 ms 299.859 ms
16 * * *
17 * * *
I have another (similar) tool that tells me that hop 16 is some kind of
firewall that is NAT/Port-Forwarding to a host - hop 17 comes back with
an indication from a server, but with the address of hop 16.
Similar trace - host exists, and is reachable:
14 (XXX.117.52.49) 348.127 ms 327.441 ms 339.921 ms
15 (XXX.181.218.10) 350.116 ms 331.256 ms 333.981 ms
16 (XXX.87.184.55) 339.793 ms 529.427 ms 469.787 ms
Similar trace - host does not exist, or is turned off or disconnected
14 (XXX.117.52.49) 409.373 ms 329.452 ms 331.011 ms
15 (XXX.181.218.10) 419.833 ms !H
Here - the router at hop 15 tells me that it knows how to get "there" (or
I'd see a !N = Network Unreachable), but the host (!H) isn't there. Now
some toy routers/firewalls can be configured to mimic this response - the
only thing is that the ICMP Type 3 Code 1 (Host Unreachable) error comes
from the IP of the destination I'm tracing to - the host that "doesn't
exist". Some programmers are as st00pid as marketeers.
>except for port 113, which came back closed.
Which as the others have said is good. Ident/Auth (RFC1413) is used by
some services on the net (mail and IRC mainly), and stealthing the port
delays a connection you want - "Bullet, meet foot. Bang!"
>My impression is that having 113 closed is probably quite ok, but I
>wanted to get some opinions on this.
Having a port "closed" ends that connection attempt. A "stealth" port
causes the remote end to try again, and again - thinking that the packets
got dropped accidentally enroute. THIS DOES NOT SLOW DOWN PORT SCANS,
because port scans are run in parallel, rather than waiting for a response
before continuing.
Old guy