I want to close an open port which is in listening mode between my client and server application.
Is there any manual command line option in Linux to close a port?
NOTE: I came to know that "only the application which owns the connected socket should close it, which will happen when the application terminates."
I don't understand why it is only possible by the application which opens it ... But I'm still eager to know if there is any other way to do it.
I had same problem, the process must keep alive but the socket must close. Closing a socket in a running process is not impossible but difficult:
locate the process :
netstat -np
You get a source/destination ip:port portstate pid/processname map
locate the the socket's file descriptor in the process
lsof -np $pid
You get a list: process name, pid, user,fileDescriptor, ... a connection string.
Locate the matching fileDescriptor number for the connection. It'll be something like "97u" which means "97".
Now connect the process:
gdb -p $pid
Now close the socket:
call close($fileDescriptor) //does not need ; at end.
example:
call close(97)
Then detach gdb:
quit
And the socket is closed.
You're kind of asking the wrong question here. It isn't really possible to simply "close a port" from outside the application that opened the socket listening on it. The only way to do this is to completely kill the process that owns the port. Then, in about a minute or two, the port will become available again for use. Here's what's going on (if you don't care, skip to the end where I show you how to kill the process owning a particular port):
Ports are resources allocated by the OS to different processes. This is similar to asking the OS for a file pointer. However, unlike file pointers, only ONE process at a time may own a port. Through the BSD socket interface, processes can make a request to listen on a port, which the OS will then grant. The OS will also make sure no other process gets the same port. At any point, the process can release the port by closing the socket. The OS will then reclaim the port. Alternatively, if the process ends without releasing the port, the OS will eventually reclaim the port (though it won't happen immediately: it'll take a few minutes).
Now, what you want to do (simply close the port from the command-line), isn't possible for two reasons. First, if it were possible, it would mean one process could simply steal away another process's resource (the port). This would be bad policy, unless restricted to privileged processes. The second reason is it is unclear what would happen to the process that owned the port if we let it continue running. The process's code is written assuming that it owns this resource. If we simply took it away, it would end up crashing on it's own, so OS's don't let you do this, even if you're a privileged process. Instead, you must simply kill them.
Anyway, here's how to kill a process that owns a particular port:
sudo netstat -ap | grep :<port_number>
That will output the line corresponding to the process holding port , for example:
tcp 0 0 *:8000 *:* LISTEN 4683/procHoldingPort
In this case, procHoldingPort is the name of the process that opened the port, 4683 is its pid, and 8000 (note that it is TCP) is the port number it holds.
Then, look in the last column, you'll see /. Then execute this:
kill <pid>
If that doesn't work (you can check by re-running the netstat command). Do this:
kill -9 <pid>
In general, it's better to avoid sending SIGKILL if you can. This is why I tell you to try kill before kill -9. Just using kill sends the gentler SIGTERM.
Like I said, it will still take a few minutes for the port to re-open if you do this. I don't know a way to speed this up. If someone else does, I'd love to hear it.
Fuser can also be used
fuser -k -n *protocol portno*
Here protocol is tcp/udp and portno is the number you wish to close. E.g.
fuser -k -n tcp 37
More info at fuser man page
You can close a listening socket using ss:
sudo ss --kill state listening src :1234
Where 1234 is your port number.
ss is part of the iproute2 package, so there is a strong change it is already installed on a modern Linux.
I learned about this from an answer to a related question.
You could alternatively use iptables:
iptables -I INPUT -p tcp --dport 80 -j DROP
It basically accomplishes what you want. This will drop all TCP traffic to port 80.
netstat -anp | grep 80
It should tell you, if you're running apache, "httpd" (this is just an example, use the port your application is using instead of 80)
pkill -9 httpd
or
killall -9 httpd
You could probably just find out what process opened the socket that the port is associated with, and kill that process.
But, you would have to realize that unless that process has a handler that de-initializes all the stuff that it was using (open files, sockets, forks, stuff that can linger unless it's closed properly upon termination) then you would have created that drag on system performance. Plus, the socket will remain open until the kernel realizes that that the process has been killed. That usually just takes about a minute.
I suppose the better question would be: What port (belonging to what process) do you want to stop?
If you are trying to put an end to a backdoor or virus that you found, then you should at least learn what data is going back and forth before you terminate it. (wireshark is good for this) (And the process' executable name so you can delete it and prevent it from coming back on reboot) or, if it's something you installed (like HTTPD or FTPD or something) then you should already have access to the process itself.
Usually it will have a control program (HTTPD stop|start or something). Or, if it's a system thing, you probably should not mess with it. Anyway, i thought that since everyone else is giving you the "how-to" angle, i should give you the caveats.
You could write a script which modified the iptables and restarts them. One script for adding a rule dropping all packets on the port, another script for removing said rule.
The other answers have shown you how to kill the process bound to the port - this may not be what you want. If you want the server to keep running, but to prevent connections from clients then you want to block the port, not stop the process.
Use UFW on your machine and close it. Or something like UFW.
sudo ufw deny PORT
Execute the following command, replacing the PORT placeholder with the number of the port to be closed:
On Debian:
sudo ufw deny PORT
On CentOS:
sudo firewall-cmd --zone=public --permanent --remove-port=PORT/tcp
sudo firewall-cmd --reload
One more issue: sometime the kernel owns ports themselves. I know NAT routing holds some ports open for NAT use. You can not kill a process for this, this is a kernel, and a reconfiguration and a reboot is required.
I first looked for the mongo and node processes, then did the following:
ps -A | grep node
10418 pts/23 00:00:05 node
10551 pts/23 00:00:00 node
ps -A | grep mongo
10490 pts/23 00:00:00 mongod
Once identified, just kill the processes with the kill command.
kill -9 10418
kill -9 10490
Lastly, type meteor and it should be working again.
You can use the command named killcx, closing a connection without any process to be killed.
killcx [dest_ip:dest_port] {interface}dest_ip : remote IP dest_port : remote port interface (optional) : network interface (eth0, lo etc).
killcx 120.121.122.123:1234 killcx 120.121.122.123:1234 eth0
I am aware that this answer does not answer the question itself, strictly speaking, but reading into it this might be relevant information:
The default behaviour of binding a socket to a port (and address) is that when socket is closed by abrupt termination of process, the socket will stay in TIME_WAIT for a while. This will mean you cannot immediately re-bind to this address/port. If you are developing the system itself through the standard BSD socket interface, you can (at least to some extent) control this behaviour with SO_REUSEADDR socket option. This will basically allow you to bind into the same address/port again if the socket is in TIME_WAIT status. Still one socket per port though!
However, this information should only be used as development aid, since there's a reason for TIME_WAIT to exist in the first place, already explained in the other answers.
