I was reading a website about the difference between stealthed and closed ports.
http://www.grc.com/faq-shieldsup.htm
A closed port will echo a packet if closed. However, a stealthed port will not respond at all.
Is it recommended to stealth all the ports you don't use? If so, how do you go about doing so?
Some operating systems respond to connection requests (in the case of TCP) or unsolicited packets (in the case of UDP) with packets indicating that nothing is listening there. Some operating systems can be configured to drop incoming packets to ports where nothing is listening with no response.
To me, neither behaviour is better than the other. My take on it is simple: Don't run unnecessary programs that listen for incoming connections / packets. The programs you have to run should be configured as securely as possible.
Worrying about your box responding to port scans seems, to me, to be missing the point. In my opinion, Steve Gibson (who runs GRC.com) is a little bit nutty. (Is his "nanoprobes" page still up?) He seems to be fear-mongering in some of his writing.
Depends on what you're trying to do. Basically, if you don't reply with a packet saying the port is closed, you'll make life more difficult for legitimate users, but possibly also make life difficult for any attackers trying to break into the box. It won't prevent somebody scanning the box to find out what ports are open, but it might slow them down. And it might make it less likely somebody finds out your system exists in the first place.
Is it a system providing services on a well-known port to the world? (such as a web server) Then trying to "stealth" your ports won't do much. good.
Is it a system doing nothing anybody needs to know about? go for it.
You didn't say what OS, etc. you're running, so the answer to how varies. On Linux with iptables you do "-j DROP" instead of "-j REJECT", basically.
Is there a particular reason you want to stealth your ports? It won't make your computer invisible (as your open ports will still respond to a port scan), makes extra work for you, and breaks the rules of RFC 791 (TCP). Are you the subject of frequent port scans, or just buying into Steve Gibson's paranoia ;)
In any case, Steve Gibson answers that question on the page that you linked to:
http://www.grc.com/faq-shieldsup.htm#STEALTH
Q ShieldsUP! shows my ports as 'Closed' and not 'Stealth', but I want Stealth! How do I get 'Stealth'?
A 'Stealthed' ports are a, strictly speaking, a violation of proper TCP/IP rules of conduct. Proper conduct requires a closed port to respond with a message indicating that the open request was received, but has been denied. This lets the sending system know that its open request was received so that it doesn't need to keep retrying. But, of course, this "affirmative denial" also lets the sending system know that a system actually exists on the receiving end . . . which is what we want to avoid in the case of malicious hackers attempting to probe our systems.
I coined the term 'Stealth' when I developed this site's port probing technology to describe a closed port that chooses to remain completely hidden by sending nothing back to its attempted opener, preferring instead to appear not to exist at all.
Since 'Stealthing' is non-standard behavior for Internet systems, it is behavior which must be created and enforced by means of a firewall security system of some sort. The native TCP/IP interface software used by personal computers will ALWAYS reply that a port is closed. Therefore, some additional software or hardware, in the form of a 'stealth capable firewall' must be added to the computer system in order to squelch its "closed port" replies.
To get full stealth-mode status from your system, I highly recommend using the completely FREE ZoneAlarm 2 firewall from ZoneLabs, Inc. Visit their website at www.ZoneLabs.com to learn more about this excellent and free firewall, then download the latest version.
Configure a firewall to silently drop them instead of reply. Most firewalls have a way to do this. Last time I needed to I was using ipf from OpenBSD and it was "block drop" versus "block return".
It's a little hard to make sense of that page. Perhaps it was written by children or by someone selling a useless product. So let's start fresh.
Let's just discuss TCP for now.
When someone attempts to connect to a TCP port (sends a SYN packet) that you do not wish to allow a connection to, you have a few choices for your response:
1) Respond with a RST packet, if you're not listening on this port that's per the TCP protocol. Normally you'd call this a "closed" port. It would make sense to call this a "stealthed" port if you are running some service on it that allows connections from other sources.
2) Accept the connection and disconnect (RST or FIN) them immediately. TCP wrappers historically had this behavior for blocked connections.
3) Ignore the packet. This is pretty common. It would make sense to call this a "stealthed" port if you're running some service on it that allows connections from other sources.
4) Accept the connection and ignore further packets for that connection. This can annoy an attacker although probably doesn't add any real security.
5) Respond with a reasonable ICMP error. Usually done by routers (including firewalls), but not as commonly done by host-based "firewalls".
6) Respond with an unreasonable ICMP error. Just to annoy/confuse an attacker
7) Respond inconsistently and randomly. This can annoy an attacker but probably doesn't add any real security.
How you respond depends on what your goals are. If you want the machine to appear not to be a valid node, you should ignore the packet regardless of whether you have a service running (that allows connections from other sources) or not. But if you are going to respond to any traffic at all, this doesn't help hide your existence.
If you want to just disallow the connection, and aren't trying to hide that your IP address is an active one, your best bet may be to respond with an RST packet, whether you are listening on that port or not. This hides whether you have a service on that port that allows connections from some addresses, or whether no service is running on that port.
Choice #4 or #7 can frustrate someone running a port scanner, but can cause you occasional operational annoyances. It's not really all that useful for an address you're actually using, but can be entertaining for a honeypot.
Choice #2 is common because some popular filtering software (e.g. TCP Wrappers) requires the connection to be accepted to get the source address, in order to determine whether it should be allowed. This is based on historical OS limitations that might not be relevant in a new installation with modern operating systems.
Your choice will depend on your requirements. This includes whether you have any ports that you allow a connection to from every address, and whether you have any ports that you allow a connection to from some addresses.
If you are not allowing incoming connections from any source, you'd might as well drop any disallowed packets. This hides the existence of your machine, making random attackers less likely to believe that it is a valid address.
If you're allowing incoming connections from any source on some ports and from certain sources on other ports - a very common configuration - you have a few reasonable choices to pick between. If you send back a RST for ports you are not listening on at all, but behave differently for ports you are deliberately disallowing, you reveal what ports you are allowing connections to from select sources. I believe the better choice is to send back an RST regardless of whether you are not listening on that port at all or you are disallowing connections from the source.
This is exactly the kind of security question that should include a threat model, an explanation of what services you are providing to everyone vs select sources, and either a security policy or clarification that you want assistance in defining a security policy. Additional confusion is caused by the introduction of new terminology without a clear definition.
For client systems a software firewall configured correctly should make your ports "stealth" I just ran my personal box that is exposed to the internet against Sheilds Up and all my ports are listed as stealth.
When I configure a firewall I don't like to have closed ports passing information back through firewalls that an attacker could use to learn about my environment, but having Open ports that an attacker could exploit is much much worse.
