Problem Statement
When one looks at listening ports on ones machine and notices a port such as TCP 5985 listening but with an owning process ID of 4 (SYSTEM/kernel), outside of googling the port number, it appears difficult at best to try and track down the true program (binary) that's really behind the request for the listening port. In such an example with port 5985, I know it is WinRM, as I enabled that manually and saw the change. While I can google and assume that what may come back makes sense, that doesn't mean I truly know what's actually asking for it to listen on this port and I must assume that, next time, Google may not provide a definitive answer (I plan for the worst). To recreate this, one can go to PowerShell (elevated) and type Enable-PSRemoting. This will start the listener on 5985 by default and listen from owning PID 4.
Why I Care
In order to set up a workstation firewall policy at a large company, I'm running a large-scale project to look across thousands of machines for listening ports and aggregating results centrally in our log management tool (with heavy filtering/documentation for what I already know - so only looking for what's left). For each port, I interrogate the owning PID for who signed it, path/name, service name, file details (description, product name, etc.). However, with PID 4 that is, of course, not available, since it's the kernel itself. I really need to know more about the true program to make a more informed decision on initially blocking it during the testing phase or not. Either way, it must be understood and documented as to what it is and its reason for listening at all.
Question
How then does one trace back the port to the actual service that requested it? Of critical importance is to be able to trace this back programmatically via PowerShell (5.1 or 7.0 GA) or some other command-line tool in a script - it can't be GUI. I'm not a real developer, but I am pretty decent with PowerShell - until someone gives me a one-liner that makes me shake my head on how obvious this should have been to me.
Already Tried
Get-NetTCPConnection -State Listen -LocalPort 5985 | Select-Object *
Tcpvcon/TCPView
ProcessExplorer (GUI anyway, wouldn't help me)
ProcessHacker (GUI anyway, wouldn't help me)
For those that made it this far and especially to those who answer - THANK YOU!
Having a similar issue and wanting to know the actual process using a port as PID 4 - SYSTEM. The following was the only way I could find to show me the originating PID:
netsh http show servicestate view=requestq verbose=no
The only other reliable way I found SMsniff by Nirsoft, this does need a capture driver installed, and therefor would not be helpfull in this context.
Related
I am testing a simple client/server application. My unit tests on client side need the server up, but I seem to be getting hangs (individual tests work, but not more than one).
As part of my tearDown(), I thought it would be good to close the server socket, but... since I have no way of getting access to the server object, from the client code, I can't do a simple: serverSocket.close(). That said, I do know what port number the socket is running on, with the port number alone, is it possible to close a socket, irrespective of where/how the object using it resides?
Sorry for what is probably a trivial question... thanks...
I suppose another related question is... can I create a socket based on a port number already in use?
No. You need to get the server software to close the port.
The only other alternative is killing the server: you can identify the process that has the port open with lsof or netstat, then kill the process. That's a brutal way to free a port though. In your case, you'd be much better off fixing your software not to hang!
If the socket is in your process, what you can do is iterate over all file descriptors from 0 to getrlimit(RLIMIT_NOFILE) and invoke getsockname() on each of them. If the call succeeds and the port number matches you have found your socket by port number (beware though, the may be multiple sockets with the same port number but bound to different addresses).
I'm working on a personal project. It's to recreate server software for the game "Chu Chu Rocket" for the Sega Dreamcast. Its' servers went down in 2004 I believe. My approach is to use dnsmasq to change the originl hostname that the game originally connected to, to my own system. With a DC-PC server set up, I have done just that, now instead of it looking up a non-existent dns record, it connects to my computer which will eventually run the server software. I've used tshark (cli wireshark) to capture what's going on between the client (dreamcast) and the server (my computer). The problem is, I'm getting data, but I'm not sure how to interpret it, I don't know what it's saying, but I'm sure it can be done because private PSO servers were created, those are far more complex.
Very simply, where would I go about learning how to interpret data packets, and possibly creating packets that will respond to such queries from the client?
Thanks,
Dragos240
If you can get the source code for the server software on your PC, then that is the best place to look.
Otherwise, all you can do is look at the protocol, compare runs, and make notes of similarities and differences. With any luck, the protocol won't be encrypted.
I wanted to know if we could find out what type of switch our machine is directly connected to ..
For instance if I am connected to a Cisco,Brocade,foundry and Force10 switch .
Is it possible to write a perl script to find out the management address of the switch [without logging in]
Is it possible to write a perl script to find out the switch vendor and model number ...
Thanks for your suggestions.
EDIT: Wanted to add that I am directly connected to the switch .. I can disable the firewall on my machine ...
nmap is what you want. If that doesn't do it, the answer is probably "no". If you need the IP address of the switch, run traceroute/tracert to see what the next hop is.
There is no guaranteed way of being able to achieve this. It depends very much on how your switch has been configured and how open your network admins have made it.
If everything is completely open then the best way of finding out the type of switch is to use snmp. The net-snmp library for perl (see docs here) is a good place to start.
But that assumes that the management interface is exposed to your box.
There is no guarantee that it will be.
If it is then nmap (as suggested by others) may work. At least it might tell you if the management interface is accessible at which point you can use snmp to tell you the rest.
Traceroute might yield some more information, but only if the address used for it's routing is the same as the management address. (and assuming that your "switch" is really a "router". If not then this won't yield any useful information.)
ping might yield some information about the manufacturer, but only if it hasn't been configured to proxy-arp.
On Cisco switchs if CDP is activated you should be able to see CDP traffic on your wire which will indicate switch model, name and switch port you are connected to.
Don't know for other brands.
Not really. In the modern world of firewalled, packet-modifying, NATed subnetworks, you really can't do anything reliably to inspect a network from a client machine.
That said, trying nmap on your router might tell you something interesting. Or it might not. The results are entirely up to the admins of your network.
follow the wire
You can ping it to get its Ethernet address, and then look it up in one of the vendor code lists.
When the webbrowser control issues an HTTP request to a URL, it is assigned a port - which is utilized for the length of that connection.
Is there away to find out which port is being utilized for each connection the webbrowser control establishes/issues?
Every request is potentially using a different port. Since most requests are resolved in a couple of seconds and then closed, having the port information on the client isn't going to be very helpful.
If you're interested from a historical perspective, you can add the port number to the logs that many web servers generate.
In order to view this information live you can use a tool such as TCPView
Now for the real question. What are you trying to do? There may be an easier way.
you can run in background:
netstat -bn
and parse output to get information about your application (ports, ips, etc.)
I apologize for the weird question wording... here's the design problem:
I am developing a server (on Linux using C++, FWIW) that provides a service to many instances of a client application running on consumer PCs.
I want the following:
1) All clients first identify themselves to a "gatekeeper" server application. Consider this a login procedure, with credentials like a user name and password being passed in. Call the gatekeeper program "gserver". (for gatekeeper.)
2) Once each client has been validated, it is then placed into a long term connection with one of several instances of a different server application running on the same physical server box bound to the same server address. Call any of these instances "wserver" (for "working" server.)
So, what the client sees is that a "gatekeeper" application gives it passworded access to one of several "working" servers running on the same box.
Here is the "real" challenge: we want to exclusively use a "well known" port number for the inbound server connections (like port 80 or 443, say.) Or, our own "well known" port.
We would prefer not to have to make the client talk to a second port on the server for the long term connection phase with wserver(n). The problem with this, of course, is that only one server process at a time can be bound to the same port and server address.
This implies that a connection made by the client with gserver must also fill the role of the long term connection. The only way I see to accomplish this is that gserver must, after login, act like a proxy and copy traffic between itself and the client to the particular wserver(n) that the client is bound to logically.
It would be ideal if a TCP/IP connection first made between client(n) and gserver could be somehow "transported" to another application on the same server, intact, and could then be sustained by one of the wserver(n) instances for the long term connection.
I know that web servers do something like this for spreading out server loads. "Load balancing". The main difference here is that the "balancing" is the allocation of a particular user to a particular wserver(n) instance. But I also have the impression that load balancing is a kind of proxying - which I am trying to avoid (since it complicates the architecture and adds overhead as well as a single point of failure.)
This is a conceptual and design question. Don't worry about source code examples, unless they are absolutely essential to get the ideas across. If we pin down an approach, I can code it up.
Thanks!
What you are looking for is file descriptor passing. See UNP 15.7. One well-known heavy user of this facility is postfix.
I developed such an application long time ago. Since multiple servers can't listen on the same port. What you need is to have gserver listening on the well-known port. Once connection is established, pass the connection to the other servers via an Unix socket. Once the connection is passed to other server, gserver is out of picture. It can die and the other server will be still serving the connection.
I dont' know if this applies to your design, but the usual solution (as implemmented by the xinetd daemon) is to fork() and then exec() the process. For example, xinetd may serve services like rlogin, rsh, tftp, telnet, etc. which are actually served by different programs. This will not be useful to you if your wservers are processes already running in the system.