How to close TCP and UDP ports via windows command line - networking

Does somebody knows how to close a TCP or UDP socket for a single connection via windows command line?
Googling about this, I saw some people asking the same thing. But the answers looked like a manual page of netstat or netsh commands focusing on how to monitor the ports. I don't want answers on how to monitor them (I already do this). I want to close/kill them.
EDIT, for clarification: Let's say that my server listens TCP port 80. A client makes a connection and port 56789 is allocated for it. Then, I discover that this connection is undesired (e.g. this user is doing bad things, we asked them to stop but the connection didn't get dropped somewhere along the way). Normally, I would add a firewall to do the job, but this would take some time, and I was in an emergency situation. Killing the process that owns the connection is really a bad idea here because this would take down the server (all users would lose functionality when we just want to selectively and temporally drop this one connection).

open cmd
type in netstat -a -n -o
find TCP [the IP address]:[port number] .... #[target_PID]# (ditto for UDP)
(Btw, kill [target_PID] didn't work for me)
CTRL+ALT+DELETE and choose "start task manager"
Click on "Processes" tab
Enable "PID" column by going to: View > Select Columns > Check the box for PID
Find the PID of interest and "END PROCESS"
Now you can rerun the server on [the IP address]:[port number] without a problem

If you know the port that you want to free you can sort your netstat list by looking for the specif port like this:
netstat -ano | findstr :8080
Then the pid will appear at the rigth which you can kill with taskkill.
taskkill /pid 11704 /F
Also you may want to look at this question which is specifically for localhost, but I think it is relevant:

Yes, this is possible. You don't have to be the current process owning the socket to close it. Consider for a moment that the remote machine, the network card, the network cable, and your OS can all cause the socket to close.
Consider also that Fiddler and Desktop VPN software can insert themselves into the network stack and show you all your traffic or reroute all your traffic.
So all you really need is either for Windows to provide an API that allows this directly, or for someone to have written a program that operates somewhat like a VPN or Fiddler and gives you a way to close sockets that pass through it.
There is at least one program (CurrPorts) that does exactly this and I used it today for the purpose of closing specific sockets on a process that was started before CurrPorts was started. To do this you must run it as administrator, of course.
Note that it is probably not easily possible to cause a program to not listen on a port (well, it is possible but that capability is referred to as a firewall...), but I don't think that was being asked here. I believe the question is "how do I selectively close one active connection (socket) to the port my program is listening on?". The wording of the question is a bit off because a port number for the undesired inbound client connection is given and it was referred to as "port" but it's pretty clear that it was a reference to that one socket and not the listening port.

For instance you want to free the port 8080
Then, follow these commands.
netstat -ano
taskkill /f /im [PID of the port 8080 got from previous command]
Done!

Use TCPView: http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx
or CurrPorts: https://www.nirsoft.net/utils/cports.html
Alternatively, if you don't want to use EXTERNAL SOFTWARE (these tools don't require an installation by the way), you can simply FIRST run the netstat command (preferably netstat -b ) & then setup Local Security Policy to block the IP address of the user's machine in question, that's what I have been doing with unwanted or even unknown connections - that allows you doing everything WITHOUT ANY EXTERNAL SOFTWARE (everything comes with Windows)...

Try the tools TCPView (GUI) and Tcpvcon (command line) by Sysinternals/Microsoft.
https://learn.microsoft.com/en-us/sysinternals/downloads/tcpview

Use CurrPorts (it's free and no-install): http://www.nirsoft.net/utils/cports.html
/close <Local Address> <Local Port> <Remote Address> <Remote Port> {Process Name}
Examples:
# Close all connections with remote port 80 and remote address 192.168.1.10:
/close * * 192.168.1.10 80
# Close all connections with remote port 80 (for all remote addresses):
/close * * * 80
# Close all connections to remote address 192.168.20.30:
/close * * 192.168.20.30 *
# Close all connections with local port 80:
/close * 80 * *
# Close all connections of Firefox with remote port 80:
/close * * * 80 firefox.exe
It also has a nice GUI with search and filter features.
Note: This answer is huntharo and JasonXA's answer and comment put together and simplified to make it easier for readers. Examples come from CurrPorts' web page.

You can't close sockets without shutting down the process that owns those sockets. Sockets are owned by the process that opened them. So to find out the process ID (PID) for Unix/Linux. Use netstat like so:
netstat -a -n -p -l
That will print something like:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1879/sendmail: acce
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 1860/xinetd
Where -a prints all sockets, -n shows the port number, -p shows the PID, -l shows only what's listening (this is optional depending on what you're after).
The real info you want is PID. Now we can shutdown that process by doing:
kill 1879
If you are shutting down a service it's better to use:
service sendmail stop
Kill literally kills just that process and any children it owns. Using the service command runs the shutdown script registered in the init.d directory. If you use kill on a service it might not properly start back up because you didn't shut it down properly. It just depends on the service.
Unfortunately, Mac is different from Linux/Unix in this respect. You can't use netstat. Read this tutorial if you're interested in Mac:
http://www.tech-recipes.com/rx/227/find-out-which-process-is-holding-which-socket-open/
And if you're on Windows use TaskManager to kill processes, and services UI to shutdown services. You can use netstat on Windows just like Linux/Unix to identify the PID.
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/netstat.mspx?mfr=true

If you know the particular port you want to kill, simply open Command Prompt as admin (on windows) and:
npx kill-port 1900
1900 above is the port number in my case. I use this most times when I want to close a port that React-Native developer tools (and Expo) is running on. Reason being that even after closing the developer window or stopping the server, the port still somehow remains in use.

You can't close sockets on your server without owning those sockets hence you can't actually close the socket down without having code running in the process that owns the server socket.
However, there is another option which is telling the client to close its socket. Sending a RST TCP packet to the port the client is connecting on will cause the client to drop their connection. You can do that with RST scanning using nmap.
http://nmap.org/

I found the right answer to this one. Try TCPView from Sysinternals, now owned by Microsoft. You can find it at http://technet.microsoft.com/en-us/sysinternals/bb897437

wkillcx is a reliable windows command line tool for killing tcp connections from the command line that hasn't been mentioned. It does have issues with servers with large number of connections sometimes though. I sometimes use tcpview for interactive kills but wkillcx can be used in scripts.

you can use program like tcpview from sysinternal. I guess it can help you a lot on both monitoring and killing unwanted connection.

In order to close the port you could identify the process that is listening on this port and kill this process.

CurrPorts did not work for us and we could only access the server through ssh, so no TCPView either. We could not kill the process either, as to not drop other connections. What we ended up doing and was not suggested yet was to block the connection on Windows' Firewall. Yes, this will block all connections that fit the rule, but in our case there was a single connection (the one we were interested in):
netsh advfirewall firewall add rule name="Conn hotfix" dir=out action=block protocol=T
CP remoteip=192.168.38.13
Replace the IP by the one you need and add other rules if needed.

instant/feasible/partial answer : https://stackoverflow.com/a/20130959/2584794
unlike from the previous answer where netstat -a -o -n was used incredibly long list was to be looked into without the name of application using those ports

If you're runnning on Windows 8,`Windows Server 2012 or above with PowerShell v4 of above installed, you can use the below script. This finds the processes associated with the port & terminates them (i.e. kills the process along with its connection; not just the connection).
Code
#which port do you want to kill
[int]$portOfInterest = 80
#fetch the process ids related to this port
[int[]]$processId = Get-NetTCPConnection -LocalPort $portOfInterest |
Select-Object -ExpandProperty OwningProcess -Unique |
Where-Object {$_ -gt 0}
#kill those processes
Stop-Process -Id $processId
Documentation:
Get-NetTCPConnection - PowerShell's NetStat equivalent
Select-Object - Pull back specific properties from an object / remove duplicates
Where-Object - Filter values based on some condition
Stop-Process - PowerShell's TaskKill equivalent

Yes there is possible to close TCP or UDP port there is a command in DOS
TASKKILL /f /pid 1234
I hope this will work for You

Related

TCP SYN flooding from Linux Machine(which is acting as client) to Destination (Server)

ROB(CLIENT) and BOB(SERVER) is Established with TCP , after some time ROB Linux Machine frequently sending TCP [SYN] to BOB(SERVER). The SYN packet is initiated automatically , which is not triggered by any service from ROB. Due to this BOB is dropping TCP connection .
We have enabled TCP Dump in ROB machine and Identified this issue.
How to Identify who is sending the Unnecessary SYN initiation from ROB to BOB ?
You could consider using the auditctl kernel level auditing framework that has been built into Linux for a while. It won't be pretty, but it will create audit records that you can then work through and tie to users. For example:
sudo auditctl -a exit,always -F arch=b64 -S socket -F success=1
Once that is done (you may need to install auditctl if it isn't there already... Check your package manager...), you can review the audit logs using ausearch
sudo ausearch -sc connect
The records will include the PID, PPID, and UID. You can dig further, but decoding the arguments to the call will take some effort since they are just raw hunks of data and will not be represented as the structures that they actually are.
Also, note that depending on your Linux version, you may find that you need to monitor a different system call. Obviously, the -b64 needs to match your architecture as well.

nmap - repeatedly scan a port for a syn/ack reply and output to file

I need to hit a http server every second for an ack reply once every second repeatedly for various lengths of time, and to output the replies into a textfile with information such as the response time in ms. this is basically to check for latency, but for my purposes i need to do it with a syn/syn-ack.
I've gotten somewhere with
nmap -sS 1.1.1.1 -p 80 -o test.txt -v
this outputs well on screen, but not into the text file -- how do i get all the output that nmap runs into the file?
also, not sure how to run this every second - does nmap have a flag for repeating? or shall i just put it in a bash script?
This command is probably doing more than you want. Each time you run it, Nmap does the following:
Does a reverse-DNS (PTR) lookup of your target
Sends a host-discovery probe to make sure the target is "up." If you are root, this is a set of 4 ICMP and TCP probes. If not, it is 2 TCP connect calls.
Sends a TCP SYN probe to port 80. If you are running as root, the sequence is SYN, SYN/ACK, RST. Otherwise it is SYN, SYN/ACK, ACK, RST/ACK.
So instead, you can use some helpful flags to reduce this overhead and be more specific with what you are asking for.
nmap -n -sn -PS80 1.1.1.1
This command will skip the reverse-DNS lookup (-n) and use the host discovery phase to find the latency. -sn skips the port scan and -PS80 says to use TCP SYN to port 80 to do host discovery. Whether the TCP handshake is completed depends on whether you have root privilege or not.
nmap -n -Pn -p 80 1.1.1.1
This command will send the exact same probes as the previous, but will show the output as a port scan, not just a host discovery scan.
To repeat the scan, you'll have to put it in a shell loop. It would be better to use a dedicated tool for this, but I don't know which one would be best. Nmap comes with a tool called Nping that can send repeated probes and report the round-trip time, but I can't get it to display it per-packet; it just gives a summary at the end. You may have better luck with hping.

Solaris tcp_time_wait_interval configuration

In my Solaris server, I have an HTTP Server which handle many incoming connections. In my server logic, it closes connection from client manually so that many TIME_WAIT status appear when I call command netstat -an in my server.
So that I change the tcp_time_wait_interval to 10 second with command:
ndd -set /dev/tcp tcp_time_wait_interval 10000
But I read from user guide, it says : "Do not set the value lower than 60 seconds".
Does anyone know why Oracle recommend that?
The user guide URL is : http://docs.oracle.com/cd/E19455-01/806-6779/chapter4-51/index.html
Was told my Oracle engineer with a very heavy trans load in thousands/sec can set to as low as 10 ms on Solaris 11/11.1

How to determine what subsystem listens to each port in a large java system

I have a big java system on unix with many subsystems (email, connection etc..) that listen on many ports, but i dont know which of my classes\subsystems listen to which port.
Is there a tool that can help me figure this out?
example:
this is what i get when i run netstat, and i dont know what in my java system is using port 2503 and what 2505
>netstat -nap |grep 250
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:2503 0.0.0.0:* LISTEN 26659/java
tcp 0 0 0.0.0.0:2505 0.0.0.0:* LISTEN 26659/java
The same PID/app is using 2 ports. You have your answer.
You will have to be MUCH more specific on your problem given the fact that the answer is so obvious based on the information provided; I can only assume this isn't what you're looking for
Once you have the PID, you can use ps
ps -Af |grep 26659 |less
The -f option will show not only the program (java) that is using the port, but also the command line used to start it. So if you have multiple java processes running, and each are started as a separate task, you will see which one is using the port.
You will probably want to view the result in "less" so you can scroll the very long command lines common to java.

On Hadoop Network System Call

Since Socket is used in hadoop src, guess it's TCP connections to send/recv messages and files, right?
How JVM translate these Socket instances to Linux system calls, is that socket/send, or select/poll?
If it's all about select/poll, I still can get ip/port through relative socket system calls, right?
When I collect all the sys_calls during a terasort (1 master, 3 slaves), I got rare connect/accept/socket sys_calls, and they are without any LAN ip in the sockaddr struct (either 0 or strange ones, IPv4). There are bunches of select/poll sys_calls, is that reasonable?
you could use "netstat --tcp -n" commands to check current tcp connection. i guess Hadoop should use TCP.
you may need use strace to start your Hadoop JVM. The strace will print system calls used by the running application. Usual application use sys_poll to check connection FD's status and use read/write or sendto/recvfrom syscall to receive transmit packet.
?
Right, these system call is only called once during connection setup through sys_socket system call, then application does many polls, transmit or receives operation on that socket.

Resources