Is filtered port vs closed port?
 

Hello.
When I scan my system via Nmap then it tell me that some ports are filtered and according to the Google:
How can I write an iptables rule to filter a port?

Thank you.

"No response" == the DROP target, which simply discards the packet. The alternative is the REJECT target, which sends an ICMP response indicating why the packet could not be delivered (default: icmp-port-unreachable). nmap will report such a port as "closed". For protocols like UDP which do not automatically acknowledge packets, nmap cannot reliably distinguish between "open" and "filtered" (there might be an application silently listening on that port).

"Ports," as in "port scans," refer to the TCP/IP protocol. An application is listening for connection requests on a particular port number. The conversation is two-way and packets are guaranteed to be delivered in the order tendered.

UDP is a datagram protocol which provides no such niceties. You send a packet out into the gloom. You don't know if it arrived. You don't know the order in which it arrived, if it did. The packet will not be "replied to." If anyone hears you, they will send a packet back to you, not knowing if you heard them.

This is what enables OpenVPN, with tls-auth, to literally remain undetectable by the outside world. There is no "open port" to scan, and the server will not respond to a connection request unless – in the initial packet – the supplicant demonstrates that it is in possession of a verifiable secret. Without it, the server drops the packet, and therefore no one can discover that it is even there. The doorway into your system is a secret door.

That sounds like you are claiming that UDP does not have "ports". I'm sure you did not mean to imply that.

Excuse me, My question is how can I make a port "filtered" with iptables?

For UDP, you can't. From the outside, there is no way to distinguish between a filtered port (packet was DROP-ed by the firewall) and a port that is open to an application that is silently listening and does not respond. That is why nmap can only report that the port is "open|filtered". The only way to get a definite status for UDP from nmap is to use a REJECT rule in the firewall, which will cause nmap to report the port as "closed".

For TCP? Thus, The service that running on that port configured for not respond?

UDP has port numbers, to identify various destinations within a particular IP, but it does not have sockets.

The word, "port," is often used colloquially where "socket" actually should have been used. A "port scan" actually looks for "open TCP/IP sockets" and therefore should be properly called a "socket scan."

The TCP/IP protocol involves "opening a socket," then engaging in a two-way "conversation" over that socket, with guarantees of delivery and of packet-sequence. The UDP protocol has none of these: each message is a shot in the dark. It operates at a much lower level within the protocol stack.

Mea culpa for using the wrong term also.

Then the service is not really running TCP, but is using some bastardized implementation of sockets that sets up something that resembles a TCP socket but does not send the required acknowledgements. Could you implement something like that? Heck yes, you could do it right in the firewall by intercepting the TCP SYN packet, not passing it to an application, but doing something else with it. Of course a sender that is actually using TCP will simply abandon or reset the connection when no ACK packet is received. You are not using TCP, so a TCP port scan will see that port as "filtered".

Can you show me an iptables rule for do that?

One way would be to send the packet to the ULOG target, and then follow that with a DROP rule. You would then need to have one or more programs listening on the netlink socket that ULOG uses and doing whatever you wanted with that packet. The standard ULOGD deamons are mainly concerned with logging in a manner more sophisticated than you can get with the LOG target, but you can write other programs that listen on that socket.

Hmm, sounds like a non-standard definition.

https://en.wikipedia.org/wiki/Network_socket

Kindly remember the fundamental concept of "a networking stack," in which one layer of network-understanding is built upon another.

"UDP = Universal Datagram Protocol" is built upon the fundamental understanding of any radio operator: "that you tirelessly mash your fingers against a telegraph key, never knowing that anyone will actually hear you unless, and until. they respond."

"TCP/IP," on the other hand, is "several stack-layers higher." By now, "the radio operators have written-down their scribbles," and then, several layers of higher-level underlings have also "done their thing," and what is left is "a bona-fide conversation." :eek:

• By now, "the dutiful radio operators" are now(!) not only prepared to swear on a stack of Bibles say that "you have received all of your messages," but that they ... and every single one of your replies to them ... have, in fact, been "received (by both sides!) exactly as tendered" ... and furthermore, "in proper sequence!"

Each and every level of "the stack" is specifically designed to provide "yet-another guarantee against uncertainty" to all of the other levels "here or upstream."

Thus, It is defined in service not iptables?