When is a port considered to be closed?

Hi

I have a question, and I strongly believe people here can explain this.

When is a port considered to be closed?

a) If OS is specifically configured to block it.
b) When no service is running on the port.

Pl. put your thoughts.

Anban

B

The end...

Not always true, TheSpecialist. What about inetd? Telnet, for example, doesn't run on port 23 until someone attempts to connect to your system on port 23. Then (assuming inetd is running) inetd checks the /etc/services file to see which port you have telnet configured on, and starts the service on that port. There isn't anything running on port 23 until someone attempts a connection on that port, right?

Perhaps I'm just splitting hairs.

Anyway, anban, to declare a port completely closed, I would turn off inetd, comment out any services you're not using in the /etc/services file on that port, and call it a day.

I think the word 'closed' is a bit poorly chosen. It's not a door that you can open and close all the time. A port just has different states. Either it is disconnected, it is listening or it is connected. That should be better definitions to use with ports, in my opinion...
If an OS is blocking a port, it is blocked, basically. The OS basically connects to it so no other form of communication can be done with it it.
And what kind of state is listening? Simple. For all communications you will need two sides to take part in it. One side that 'opens' the port and then starts to listen for incoming messages and the other side that 'links' to this open port to start the communications. As long as one side is connected to a port, it can't do much with it except listening until something makes a connection with it. You could call this 'open' because when a connection is made, the port will be closed for other processes for the duration of this communication...

Don't get too confused about definitions of words. There tend to be plenty of different definitions for these kinds of things. Just understand the logic behind it, which is more important when you need to use it.

port is considered closed when client sends a SYN and receives a FIN or a RST in response.
port is considered blocked when client sends a SYN and receives no response.

Hmmm. I suddenly realise that there might be a bit of confusion about the kind of port we're talking about here. Obviously not about those where ships get in and out. :D
But do we talk about a serial port here? Parallel port? USB port? Ir a TCP/IP port? Space port?

You can also drink port, apparantly. It's a bit disambiguous. :D But a good description of computer ports is available at http://en.wikipedia.org/wiki/Port_%28computing%29 if you're interested.

But basically, a port can be closed because the port master doesn't allow any ships to enter or leave, or a port is closed because a ship sunk in it and is blocking the entrance. (In which case you can also call it blocked.) :D It's all about traffic anyways...

Generally closed ports will send an rst/ack in response to unwanted tcp traffic, not a fin. And icmp port unreachable is sent for udp.

Blocked will generally drop the traffic or have an icmp response from the local router...something along the lines of admin prohibited..

I'm surprised, no one went into too much detail about filtered ports. :o

No one really asked about port filtering afaik.

I allways thought of filtered as what cacosapo calles blocked (when client sends a SYN and receives no response)

True, that would be the second part of my post where the user recieves no response or gets the icmp admin prohibited from the nearest local router responsible for that network segment.

Exactly the point, Juridian.

What is meant by the posters use of "Closed".

Is it rejecting, dropping, connecting, or connected? If there is a service listening (or as Roswell finehaired it, a superdaemon listening), the port is considered 'Open', agreed? If no service is listening, is it 'Closed' as TheSpecialist indicated? What about "Stealthed" as many port scanners will call unresponsive ports on obivously online hosts?

Semantics: not just an overbloated AntiVirus company anymore.

Stealthed is the same as filtered..

No responce at all..

A closed port should send a reset back..
The clients sends a SYN and the server sends a RST back.

And if a host shuts down right when it receives a "SYN" packet to a specific port?

Quote:

---

Originally posted here by ThePastorGang
And if a host shuts down right when it receives a "SYN" packet to a specific port?

---

The client precieves that as a broken request or a request to a filtered port . .

for me:

blocked = filtered = sthealthed --> a firewall is dropping the response packs or a firewall is blocking the input packets. its detected by timeout, since normal behavior is send a RST back

closed = no deamon, service is available on that port. It can be showed by a RST response (Juridian is correct about FIN flag)

The Port is considered to be closed if it is explicitly blocked by the Operating System .

thank you for the response.

So all of you suggest that - If explicitly Blocked by the OS or firewall in the system then the port is consifered to be closed.

If you have a different opinion pl. put it across.

Closed, blocked.... These are all just definitions and people tend to disagree with those definitions. Basically there are three situations with a port:
1) not a single process is using it.
2) A single process is listening to it.
3) Two processes are listening to it and thus communicate with each other.

In situation 2, it is possible that a process is listening and discarding each and every message that is sent to the port. This way, the process is actually blocking the port. In situation 1, I have the feeling that it is just closed since any process can decide to open the port to listen to it. But that's my personal feelings about it. Others have different opinions about this.

I love it when people over-analyze a question! :)

Think of any connection via TCP as a telephone conversation:

You dial the number of the other person (IP and Port) This immediatly initiates the SYN.

If the number is not in service (no service listening to port) you get that annoying mesage from the phone company (the RST).

IMHO, that is a closed port. There is no service or daemon running, so no process is listening on the port, preventing a connection from being established.

Any other event such as dropping the SYN and sending no response is simply stealthed, blocked, hidden, masked, etc. (which I personally collectively refer to as "blocked".

Also, While it is true that inetd will spawn telnet if it is requested, on most linux distros and MS OSes, telnet has its own service daemon that can be disabled, or simply not installed when setting up the OS, which effectively closes port 23 for telnet on these systems, and also prevents telnet access to SMTP (because there is no telnet service).

Quote:

---

So all of you suggest that - If explicitly Blocked by the OS or firewall in the system then the port is consifered to be closed.

---

No... ports can never be explicitly closed, only explicitly open and filtered (which may or may not be blocked completely).

If a port has NO service explicitly using it, the port is considered CLOSED.
If a port has NO service explicitly using it AND is filtered by firewall which allows ALL traffic, the port is considered CLOSED.
If a port has NO service explicitly using it AND is filtered by firewall which allows SOME/NO traffic, the port is considered FILTERED.

If a port has a service explicitly using it, the port is considered OPEN.
If a port has a service explicitly using it AND is filtered by firewall which allows ALL traffic, the port is considered OPEN.
If a port has a service explicitly using it AND is filtered by firewall which allows SOME/NO traffic traffic, the port is considered FILTERED.

It does not matter what generation of firewall is used or anything else.

"Blocked" and "Stealth" are casual terms which fall within the set of "Filtered"

Talk about RST flags and inetd, while interesting just confuse the point... as a non-standard TCP/IP stack may not issue the correct flags, but would still fall under the rules above.

cheers,

catch