I have the D-Link DI-604 Router. Nice thing. But grc.com shieldsup tells me that Port 113 is blocked, blowing its otherwise full-stealth cover...:-(
I was looking on their description of Port 113 and found the following:
The good news is . . . it is possible to configure NAT routers to return them to full stealth. The trick is to use the router's own "port forwarding" configuration options to forward just port 113 into the wild blue yonder. Just tell the router to forward port 113 packets to a completely non-existent IP address, one way up at the end of your router's internal address range. The router will then NOT return a port closed status. It will simply forward the port 113 packet "nowhere" . . . and your network will be returned to full stealth status.
I'm not an english native speaker: can you translate this to me into better english:
"The trick is to use the router's own "port forwarding" configuration options to forward just port 113 into the wild blue yonder. Just tell the router to forward port 113 packets to a completely non-existent IP address, one way up at the end of your router's internal address range."
wild blue yonder.??? one way up at the end of...???
While Wolfgang, Lars and Greg are technically correct I do believe that a Stealth setting appears to have some usefuleness. I have gathered this information from many sources for the last year and this is what I can conclude.
Having a "Stealth" setting can slow down port scanners(the bad guys) looking for open ports to exploit. A closed port will respond quickly letting a port scanner know that there is something there which they might come back later to try and exploit while a Stealth port will delay response hopefully sending port scanning software on to an easier target. I know these other guys who have much more technical saavy than I will balk at this but so be it. I think it might have been Steve Gibson that coined the phrase "Stealth" over on GRC. What those other guys talk about is that a stealth response is not a correct response that is supposed to occur in networking. A true response would be a packet sent out asking "Are you there" and the responses are either "Yes I am here but not accepting"(a Closed response) or "No one is here by that name"(a response from a system that does not exist or is off. A stealth response is no response at all thus letting someone who is looking that there is something there but it isn't answering or told not to answer. So you see that stealth is not really stealth at all. I know the language is not very technical but that is it in a nutshell.
Now how to achieve a stealth response on a router? I don't use D-Link but the procedures should be very similar. Go to the page on the routers web management pages for forwarding and forward TCP port 113 to an unused IP address. Preferably one not in the DHCP range of the LAN side being used. Be advised that a stealth response on port 113 could break your email though(as Greg suggested).
Thank you. While I agree that stealth is silly, some people think it is important, and the guy deserved an answer, not a philosophy. I don't have a router, so I couldn't answer the question. With any luck, a D-Link owner will jump in.
"Johnny" wrote in news: firstname.lastname@example.org:
Look at the address range that the DHCP server in the D-Link router can assign. Mine can assign 192.168.0.x where x ranges from 100 to 199 (although it could range from 1 to 254). Notice that the first 3 octets are fixed (i.e., you cannot change them) which means it cannot assign many IP addresses, like 192.168.12.89. So select an IP address that cannot be assigned by the DHCP server in your NAT router. I use
192.168.255.254. Then I use Advanced -> Virtual Server to define one at this unassignable IP address. It is unimportant what port you specify for that virtual server host because it doesn't exist, anyway, so I just reuse 113.
Basically this is used to open a port to a host through the router's firewall but you are pointing it to a host that can never exist because the DHCP server in the NAT router will never be able to assign that IP address. So any ancient mail server that still uses the auth/ident protocol via port 113 will send it to your router which routes it to a host that doesn't exist so there will never be a response to it. When you next run GRC's stealth test you will then see port 113 never gets responded to (as opposed to immediately returning a status of closed which also declares that something exists to announce that status).
Not responding to a connection attempt is different than returning a status of closed. One doesn't reveal that there is anything at the other end. The other obviously must require something to exist to report back the closed status. Sure the hacker might go away if they find all the attempted ports are closed but they'll still know you exist. No response means the hacker won't know if your network doesn't exist or if it is powered down. I'd rather leave them in the dark and possible avoid later intrusion attempts. For those that argue that stealthing a port (by not responding to a connect attempt) is no better protection than immediately and actively reporting a closed status on the port, I argue that if stealthing doesn't hurt and might help then there's no point not to do it.
On Mon, 26 Jul 2004 19:45:12 -0400, "Crash" Dummy spoketh
One solution could be to forward port 113 to either: a) A computer with a desktop firewall that "stealths" the port, or b) to a non-existing IP address on the LAN.
I think the point that some of us are trying to make is that there's little point in chasing the pie in the sky. Jbob is correct; a "stealth" device will slow down port scanning, as the scanner will have to wait for a timeout rather than just getting a quick "we're closed" response and move on. It does not, however, make the target less visible as implied by the mo inker...
Lars M. Hansen
Remove "bad" from my e-mail address to contact me. "If you try to fail, and succeed, which have you done?"
Lars M. Hansen ( email@example.com) wrote: : On Mon, 26 Jul 2004 19:45:12 -0400, "Crash" Dummy spoketh
: >>Now how to achieve a stealth response on a router? I don't use D-Link but : >>the procedures should be very similar. Go to the page on the routers web : >>management pages for forwarding and forward TCP port 113 to an unused IP : >>address. Preferably one not in the DHCP range of the LAN side being used. : >
: >Thank you. While I agree that stealth is silly, some people think it is : >important, and the guy deserved an answer, not a philosophy. I don't have a : >router, so I couldn't answer the question. With any luck, a D-Link owner will : >jump in.
: One solution could be to forward port 113 to either: : a) A computer with a desktop firewall that "stealths" the port, or : b) to a non-existing IP address on the LAN.
: I think the point that some of us are trying to make is that there's : little point in chasing the pie in the sky. Jbob is correct; a "stealth" : device will slow down port scanning, as the scanner will have to wait : for a timeout rather than just getting a quick "we're closed" response : and move on. It does not, however, make the target less visible as : implied by the mo inker...
And thinking about it also. For the small user in which 'stealth' seems to be important for some people it really does not add that much. The time cost will be minimal.
Now, for larger enterprise level systems, the difference between rejection and drop can be significant. If you simply drop the packet, your do not have to construct the rejection packet and, when dealing in 100MB to 1GB, this does become a useful reduction in the code path for new streams. From a security standpoint, there is *no difference* in the information returned from a 'closed' port vs a 'stealthed' port. Anyone who is really interested knows that a machine does exist on a particular IP and that port is not open for business even if the port is stealthed.
The general recommendation for Checkpoint is to use drop in a rejection rule rather than reject. It is faster. [Even faster is to not log the event]. The recommended practice now for microsoft-ds and RPC as well as sql is to drop without logging since there is so much of this traffic it will impact the performance of your enforcement module.
As the others have told you, "Stealth" doesn't have anything to do with security, it's only marketing hype (and I've just read one article where somebody complained that the XP SP2 firewall doesn't block ARP- requests...).
Port 113 isn't "stealthed" for a simple and good reason: Many servers, especially FTP, IRC and SMTP-servers, send an IDENT-request to your PCs port 113 when you try to connect to them. It's the equivalent of you knocking at a door and them asking "Who's there?".
If you drop that request ("Stealth your machine"), that request gets lost. So the server will wait for a reply until hitting a timeout, and will only let you proceed once it has found out that you aren't willing or able to reply (and normally, timeout can be between 30 seconds and 2 minutes...).
If port 113 is closed instead of "stealthed", your machine will immediately reply with "Port 113? What's that supposed to do?", so the server will immediately know that you don't use the IDENT protocoll and act accordingly.
The only usefulness I've ever seen is reducing the possibility of operating system fingerprinting - it's hard to identify a system that doesn't respond. It's still vulnerable to non-standard packet attacks (oversize, mangled, etc.), security holes in the operating system, and configuration blunders.
Hate to tell you this, but NO port scanners send a packet and then wait for the response any more - the better ones may send thousands of probes IN PARALLEL limited only by the attacker's bandwidth and the amount of RAM in his computer. Even the common worms run parallel attacks.
Knowledge is often more useful than assumptions based on misinformation.
HUH??? Maybe you want to rephrase that. The "host unreachable" response comes from the router upstream - not out of thin air.
See if you can follow this. (NOTE: IPs munged to protect the lusers.) First, a trace to a working web server:
21 XXX.XXX.0.142 (XXX.XXX.0.142) 360.166 ms 319.288 ms 429.845 ms
22 yamaha.tpi.XXX (XXX.XXX.121.194) 329.807 ms 309.331 ms 309.864 ms
23 www.tpnet.XXX (XXX.XXX.121.237) 329.744 ms 329.413 ms 299.859 ms [compton ~]$
The trace ends at the web site, without an error indication. Next, a trace to a non-existent or dead host:
14 slkcic02.eli.XXX (XXX.XXX.52.53) 360.166 ms 319.288 ms 429.845 ms
15 XXX.XXX.218.10 (XXX.XXX.218.10) 402.974 ms 390.329 ms 440.299 ms
16 XXX.XXX.219.251 (XXX.XXX.219.251) 412.118 ms !h [compton ~]$
The '!h' indicate that the listed host (some kind of router, maybe a Cyclades) sent back an ICMP Type 3 Code 1 (Host Unreachable) error.
lists most of the other types/codes, but see also RFC0792.
And the trace to a stealthed web server:
14 r-rm6-vl19.opb.interbusiness.XXX (XXX.XXX.5.14) 309.55 ms 351.245 mx
15 XXX.XXX.81.42 (XXX.XXX.81.42) 300.842 ms 239.133 ms 239.409 ms
16 * **
17 ** *
18 * **
19 ** *
20 * * *
By using a different tool that users don't think about, I know that host 16 is a Cisco 7000 series router, host 17 is a firewall of some kind, and the web server is host 18.
Your headers suggest you are using windoze - probably XP, which means you are using the b0rken version of "tracerout" (a very crippled version of the original Unix "traceroute"). That only uses a ping (ICMP echo) that many hosts drop, so if you try this, you may see even stranger things. Broken tools = poor results.
You got it. "I'm standing right in front of you in plain sight, but you can't see me because I'm keeping my mouth closed." Yeah, right.
That _may_ take care of TCP port 113 - but what about the _other_ 65533 valid TCP ports (and the 65534 valid UDP ports, and the other 133 protocols _besides_ TCP and UDP).
But make sure it's one the same network - you don't want the router trying to send an ICMP Type 5 error.
Among other things. This is in spite of the third paragraph of Section