LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 10-10-2017, 11:36 AM   #1
hack3rcon
Senior Member
 
Registered: Jan 2015
Posts: 1,211

Rep: Reputation: Disabled
Post 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:
Quote:
Nmap places ports in this state when it is unable to determine whether a port is open or filtered. This occurs for scan types in which open ports give no response.
How can I write an iptables rule to filter a port?

Thank you.
Attached Thumbnails
Click image for larger version

Name:	nmap.png
Views:	9
Size:	51.2 KB
ID:	26074  
 
Old 10-10-2017, 01:36 PM   #2
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,582

Rep: Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568
"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).
 
Old 10-10-2017, 01:56 PM   #3
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,606
Blog Entries: 4

Rep: Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997
Quote:
Originally Posted by rknichols View Post
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.
 
Old 10-10-2017, 02:01 PM   #4
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,582

Rep: Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568
Quote:
Originally Posted by sundialsvcs View Post
"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.
That sounds like you are claiming that UDP does not have "ports". I'm sure you did not mean to imply that.
 
Old 10-11-2017, 03:17 AM   #5
hack3rcon
Senior Member
 
Registered: Jan 2015
Posts: 1,211

Original Poster
Rep: Reputation: Disabled
Excuse me, My question is how can I make a port "filtered" with iptables?
 
Old 10-11-2017, 09:54 AM   #6
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,582

Rep: Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568
Quote:
Originally Posted by hack3rcon View Post
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".
 
Old 10-11-2017, 11:36 AM   #7
hack3rcon
Senior Member
 
Registered: Jan 2015
Posts: 1,211

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by rknichols View Post
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?
 
Old 10-11-2017, 12:33 PM   #8
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,606
Blog Entries: 4

Rep: Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997
Quote:
Originally Posted by rknichols View Post
That sounds like you are claiming that UDP does not have "ports". I'm sure you did not mean to imply that.
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.

Last edited by sundialsvcs; 10-11-2017 at 12:36 PM.
 
1 members found this post helpful.
Old 10-11-2017, 01:56 PM   #9
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,582

Rep: Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568
Quote:
Originally Posted by hack3rcon View Post
For TCP? Thus, The service that running on that port configured for not respond?
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".

Last edited by rknichols; 10-11-2017 at 01:58 PM.
 
Old 10-14-2017, 10:26 AM   #10
hack3rcon
Senior Member
 
Registered: Jan 2015
Posts: 1,211

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by rknichols View Post
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?
 
Old 10-14-2017, 10:50 AM   #11
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,582

Rep: Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568Reputation: 1568
Quote:
Originally Posted by rknichols View Post
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.
Quote:
Originally Posted by hack3rcon View Post
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.
 
Old 10-17-2017, 03:51 PM   #12
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,239

Rep: Reputation: 1405Reputation: 1405Reputation: 1405Reputation: 1405Reputation: 1405Reputation: 1405Reputation: 1405Reputation: 1405Reputation: 1405Reputation: 1405
Quote:
Originally Posted by sundialsvcs View Post
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."
Hmm, sounds like a non-standard definition.

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

Quote:
Sockets are local (specific to one node): they are local resources and cannot be referred to directly by other nodes, unlike ports. Further, sockets are not necessarily associated with a persistent connection (channel) for communication between two nodes, nor is there necessarily some single other endpoint. For example, a datagram socket can be used for connectionless communication, and a multicast socket can be used to send to multiple nodes, or an address range where there may or may not be any nodes to receive data. However, in practice for internet communication, sockets generally have associated addresses and often have a connection.
 
Old 10-17-2017, 06:04 PM   #13
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,606
Blog Entries: 4

Rep: Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997Reputation: 2997
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."
  • 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."

Last edited by sundialsvcs; 10-17-2017 at 06:07 PM.
 
Old 10-21-2017, 05:03 AM   #14
hack3rcon
Senior Member
 
Registered: Jan 2015
Posts: 1,211

Original Poster
Rep: Reputation: Disabled
Thus, It is defined in service not iptables?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Closed Port/Port in use when attempting to port forward for server. Tetrad Linux - Networking 2 07-06-2015 12:54 PM
Port Forwarding- Want to keep Port 587 incoming closed dman777 Linux - Networking 2 10-20-2011 10:33 PM
port 25 filtered despite firewall having port 25 open ille.pugil42 Linux - Security 8 03-09-2007 01:51 AM
Port Scan: Closed Port instead of Stealth unihiekka Linux - Security 9 12-26-2005 09:51 PM
port closed/filtered? name_in_use450 Linux - Security 3 09-06-2004 06:52 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 09:53 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration