How to check opened/closed ports on my computer?
@Justgivemeaname: nmap is a tool to check for open ports on another host. If you can run netstat on a machine, it’s much faster and reliable to use it.
@DavidFoerster: Didn’t know about netstat , so I learned that. It says in the link that it should be used from another host, though. Thanks!
8 Answers 8
There’s a few parameters to netstat that are useful for this :
- -l or —listening shows only the sockets currently listening for incoming connection.
- -a or —all shows all sockets currently in use.
- -t or —tcp shows the tcp sockets.
- -u or —udp shows the udp sockets.
- -n or —numeric shows the hosts and ports as numbers, instead of resolving in dns and looking in /etc/services.
You use a mix of these to get what you want. To know which port numbers are currently in use, use one of these:
netstat -atn # For tcp netstat -aun # For udp netstat -atun # For both In the output all port mentioned are in use either listening for incoming connection or connected to a peer** all others are closed. TCP and UDP ports are 16 bits wide (they go from 1-65535)
** They can also be connecting/disconnecting from the peer.
If it shows some process its used. Its closed(not used) if there is no output.
Another alternative command line easy to use to find out which process is using a port:
lsof -n -i4TCP:$PORT | grep LISTEN I added the next function in my .bash_profile,
and now run «pslisten 5060» to see who is grabing my SIP port.
It’s work with Apple Mac OS X too.
Is the port status «LISTENING» indicated that the port is opened?
Yes. It means that some service is listening to that port on your computer for incoming connection i.e. this port is open for establishing new connections.
Any port that are not shown in the output indicated that it’s closed?
Yes. Remember netstat -a will show all active (listening) and passive (non-listening) connections i.e. the ports that are acting as both server (some services are listening to these ports for connections from a different machine/process) and established (connections are established on these ports regardless of the fact the host/a service can be a server or client)
All TCP and UDP ports belong to a category called sockets and there are a whole lot of those. To view socket info you can check man ss .
Thanks. you wrote that -a means server and established. Does «server» means ports that are being listened at by some services? Does «established» mean ports where there are existing connections regardless of it is a client or server’s port? Then what kinds of ports does -a not show?
I don’t think the -a option means «all active» sockets; it just means «all». netstat shows all active sockets by default, but leaves out the passive sockets (open, listening). By using the -a option both active and passive sockets are shown.
@heemayl The second part of your answer is still not correct. A TCP socket in the «listening» state can never be a connection; it is not connected to anything, it is only listening. Listening TCP sockets are also called passive sockets because of this. If a client attempts to connect to a (listening) socket on a server, a new socket will be created on the server to establish a connection with the client. A socket which is part of an established connection is called an active socket.
Another option is ss. It’s much easier to use.
The below command will only output a list of current listening sockets.
root@server:~# ss -l Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port u_dgr UNCONN 0 0 * 23353 * 23352 u_dgr UNCONN 0 0 * 568 * 362 u_dgr UNCONN 0 0 * 14836 * 14837 u_dgr UNCONN 0 0 * 20446 * 369 u_dgr UNCONN 0 0 * 22877 * 369 u_dgr UNCONN 0 0 * 504 * 347 u_dgr UNCONN 0 0 * 16298 * 369 u_dgr UNCONN 0 0 * 23343 * 369 u_dgr UNCONN 0 0 * 24125 * 369 u_dgr UNCONN 0 0 * 24617 * 369 u_dgr UNCONN 0 0 * 23352 * 23353 u_dgr UNCONN 0 0 * 23334 * 369 u_dgr UNCONN 0 0 * 17113 * 369 u_dgr UNCONN 0 0 * 16957 * 369 u_dgr UNCONN 0 0 * 14793 * 362 u_dgr UNCONN 0 0 * 23345 * 362 u_dgr UNCONN 0 0 * 24070 * 369 udp UNCONN 0 0 *:sunrpc *:* udp UNCONN 0 0 *:981 *:* udp UNCONN 0 0 . sunrpc . * udp UNCONN 0 0 . 981 . * tcp LISTEN 0 128 127.0.0.1:85 *:* tcp LISTEN 0 128 *:ssh *:* tcp LISTEN 0 128 *:3128 *:* tcp LISTEN 0 100 127.0.0.1:smtp *:* tcp LISTEN 0 128 *:8006 *:* tcp LISTEN 0 128 *:sunrpc *:* tcp LISTEN 0 128 . ssh . * tcp LISTEN 0 100 ::1:smtp . * tcp LISTEN 0 128 . sunrpc . * Why is my port closed when accessing from the network?
I have read so many pages, and tried so many things, but am stuck here. I have a freshly installed Ubuntu 20.04 server. And on it I run a Django test server (just to try it out). It is running and listening on port 8000. I can see that:
$ sudo netstat -tulpen Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN 112 62240 47748/postgres tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN 1000 65495 48618/python tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 101 23068 755/systemd-resolve tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 27689 850/sshd: /usr/sbin tcp6 0 0 . 5432 . * LISTEN 112 62241 47748/postgres tcp6 0 0 . 22 . * LISTEN 0 27691 850/sshd: /usr/sbin udp 0 0 127.0.0.53:53 0.0.0.0:* 101 23067 755/systemd-resolve udp 0 0 192.168.0.15:68 0.0.0.0:* 100 23071 753/systemd-network udp6 0 0 fe80::224:e8ff:fe22:546 . * 100 23086 753/systemd-network And it responds just fine. I can on the server do: wget localhost:8000 and I get a response. So now I move to a desktop machine on my lan. And I try wget:
$ wget server.lan:8000 --2020-10-11 11:42:18-- http://server.lan:8000/ Resolving server.lan (server.lan). 192.168.0.15 Connecting to server.lan (server.lan)|192.168.0.15|:8000. failed: Connection refused. $ nmap server.lan Starting Nmap 7.80 ( https://nmap.org ) at 2020-10-11 22:43 AEDT Nmap scan report for server.lan (192.168.0.15) Host is up (0.00025s latency). Not shown: 998 closed ports PORT STATE SERVICE 22/tcp open ssh 5432/tcp open postgresql Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds $ nmap serverlan -p 8000 Starting Nmap 7.80 ( https://nmap.org ) at 2020-10-11 22:44 AEDT Nmap scan report for server.lan (192.168.0.15) Host is up (0.00068s latency). PORT STATE SERVICE 8000/tcp closed http-alt Nmap done: 1 IP address (1 host up) scanned in 0.03 seconds $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp dpt:8000 Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination $ sudo iptables -A INPUT -p tcp --dport 8000 -j ACCEPT $ sudo ufw status verbose Status: inactive Yet from a desktop on the lan port 8000 is closed! I should note port 22 is open (as in I am doing this using an ssh login to the server, and I can see the database on port 5432 as well and manage it with pgadmin4 from the desktop just fine, so ports 22 and 5432 are open, and yet I cannot see on iptables -L that they are open. What mystical magic is Ubuntu 20.04 working that none of many pages I’ve read hit at here. I can even ping it fine:
$ ping arachne.lan PING arachne.lan (192.168.0.15) 56(84) bytes of data. 64 bytes from 192.168.0.15 (192.168.0.15): icmp_seq=1 ttl=64 time=0.269 ms 64 bytes from 192.168.0.15 (192.168.0.15): icmp_seq=2 ttl=64 time=0.267 ms 64 bytes from 192.168.0.15 (192.168.0.15): icmp_seq=3 ttl=64 time=0.530 ms 64 bytes from 192.168.0.15 (192.168.0.15): icmp_seq=4 ttl=64 time=0.284 ms 64 bytes from 192.168.0.15 (192.168.0.15): icmp_seq=5 ttl=64 time=0.280 ms 64 bytes from 192.168.0.15 (192.168.0.15): icmp_seq=6 ttl=64 time=0.280 ms So because I like it and use I installed cockpit and it runs of port 9090. It installs and works from a desktop. Now:
$ netstat -tulpen (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN 112 62240 - tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN 1000 65495 48618/python tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 101 23068 - tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 27689 - tcp6 0 0 . 5432 . * LISTEN 112 62241 - tcp6 0 0 . 9090 . * LISTEN 0 71091 - tcp6 0 0 . 22 . * LISTEN 0 27691 - udp 0 0 127.0.0.53:53 0.0.0.0:* 101 23067 - udp 0 0 192.168.0.15:68 0.0.0.0:* 100 23071 - udp6 0 0 fe80::224:e8ff:fe22:546 . * 100 23086 - $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp dpt:8000 Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination $ nmap server.lan Starting Nmap 7.80 ( https://nmap.org ) at 2020-10-11 22:55 AEDT Nmap scan report for server.lan (192.168.0.15) Host is up (0.00024s latency). Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 5432/tcp open postgresql 9090/tcp open zeus-admin Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds So cockpit and postgresql and ssh all manage somehow when installing to tell Ubuntu 20.04 to open a port. So looking on the server at an introspective nmap:
$ nmap localhost Starting Nmap 7.80 ( https://nmap.org ) at 2020-10-11 11:58 UTC Nmap scan report for localhost (127.0.0.1) Host is up (0.00021s latency). Not shown: 996 closed ports PORT STATE SERVICE 22/tcp open ssh 5432/tcp open postgresql 8000/tcp open http-alt 9090/tcp open zeus-admin Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds Port 8000 looks open. There is no firewall between the desktop and server, just a standard LAN switch. How is it, that cockpit and postgresql and ssh can all achieve something and it be so hard to work out what and how they have achieved it? They don’t use iptables it seems. Nor ufw . What magic am I missing? How can I open port 8000?
How to close ports in Linux?
it show that 23/tcp port is closed. Which of them is true? I want to close this port on my whole system, how can I do it?
they are both true. TCP ports aren’t associated with hosts. they are associated with network interfaces. the difference is subtle but important. interfaces are often the same as hosts, but not always. in this case (as stated in answers) localhost is accessing the lo (loopback) interface. the IP Address is accesing your real interface, probably eth0 or wlan0 or somesuch.
5 Answers 5
Nmap is a great port scanner, but sometimes you want something more authoritative. You can ask the kernel what processes have which ports open by using the netstat utility:
me@myhost:~$ sudo netstat -tlnp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1004/dnsmasq tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 380/sshd tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 822/cupsd tcp6 0 0 . 22 . * LISTEN 380/sshd tcp6 0 0 ::1:631 . * LISTEN 822/cupsd
The options I have given are:
- -t TCP only
- -l Listening ports only
- -n Don’t look up service and host names, just display numbers
- -p Show process information (requires root privilege)
In this case, we can see that sshd is listening on any interface ( 0.0.0.0 ) port 22, and cupsd is listening on loopback ( 127.0.0.1 ) port 631. Your output may show that telnetd has a local address of 192.168.1.1:23 , meaning it will not answer to connections on the loopback adapter (e.g. you can’t telnet 127.0.0.1 ).
There are other tools that will show similar information (e.g. lsof or /proc ), but netstat is the most widely available. It even works on Windows ( netstat -anb ). BSD netstat is a little different: you’ll have to use sockstat(1) to get the process information instead.
Once you have the process ID and program name, you can go about finding the process and killing it if you wish to close the port. For finer-grained control, you can use a firewall (iptables on Linux) to limit access to only certain addresses. You may need to disable a service startup. If the PID is «-» on Linux, it’s probably a kernel process (this is common with NFS for instance), so good luck finding out what it is.
Note: I said «authoritative» because you’re not being hindered by network conditions and firewalls. If you trust your computer, that’s great. However, if you suspect that you’ve been hacked, you may not be able to trust the tools on your computer. Replacing standard utilities (and sometimes even system calls) with ones that hide certain processes or ports (a.k.a. rootkits) is a standard practice among attackers. Your best bet at this point is to make a forensic copy of your disk and restore from backup; then use the copy to determine the way they got in and close it off.