Mapping TCP ports back to VOS (STCP), Windows (server 2003 and XP) and ftLinux processes

Blue Bar separator

This article updates my December 2002 article How to map TCP ports back to a VOS or ftServer process with new and improved ways to map a TCP port number back to a VOS STCP (15.3 or later) or ftServer Windows 2003 server process. It also adds information on finding a VOS STCP process using a UDP port and finding an ftLinux process. For information about TCP_OS, STCP before 15.3 or ftSever running Windows 2000 server refer to the original article.

VOS (STCP - TCP))

This is now a 2 step process instead of 3 or 4 steps. The first step is to use the analyze_system request dump_stcbq to find the STCP device associated with the socket. You can specify any combination of the local and remote IP addresses and port numbers (see figure 1). IP addresses cannot be specified in dotted decimal notation; you have your choice between decimal or hex. In general I think hex is easier since each decimal portion of the IP address is converted to hex independently of the other sections. So 10.11.12.13 would be 0A0B0C0D in hex. In decimal it would be 168496141. The port numbers can be specified in decimal. Since dump_stcbq dumps a lot of information you want to filter it with match. In this case match on the string "dv" (see figure 2). Note that if there is only 1 socket with the specified port number you do not need to specify an IP address. If there is more than 1 socket with the same port number dump_stcbq will display all of them (see figure 4 for an example). It is very important to remember to use the -full argument as well. If you do not, nothing useful will be displayed.

 
as:  dump_stcbq -form
 ---------------------------------- dump_stcbq --------------------------------
 -full:  no                                                                
 -laddr:                                             
 -faddr:                                                                   
 -lport:                                              
 -fport:        
Figure 1 - VOS analyze_system dump_stcbq request form

 
as:  match dv; dump_stcbq -laddr A4984D22x -lport 22  -full                    
    sth_dvtx                 = 151 (stcp.m15_9380)
Figure 2 - Step 1 -- Find VOS device name with dump_stcbq

Step 2 is to associate the device found in step 1 with a process. This can be done with the who_locked command (figure 3).

 
as:  ..who_locked #stcp.m15_9380
stcp.m15_9380:
     Object is write locked by root.root (sshd) on module %phx_vos#m15         
          executing sshd.pm.
Figure 3 - Step 2 -- Finding the process that owns the VOS device

Note that this will NOT work with connected sockets being used by OSL since there is no associated device. A connected socket is one that is in an ESTABLISHED state. It will work for OSL sockets in a LISTEN state. You can confirm that a socket without an associated device is being used by OSL by looking for a "Q Name = osl" entry instead of a device. You can see this in figure 4. First a netstat shows that there are 3 sockets using a port number of 3005 (two local one remote). If we match on both "@" or "dv" and select the local port 3005 you can see that two socket TCBs (TCP Control Blocks) are displayed. These match up with the first column from the netstat display. However, only the first socket - the one in a LISTEN state has a device associated with it. If instead we match on "@" or "osl" we get the same two TCBs but now only the second one has a "Q Name = osl". If we match on the third socket's local port number you can see no device information is returned but there is a "Q Name = osl" line.

 
netstat -number -all_sockets
. . .
8b1931c0  tcp       0      0  *:3005             *:*                LISTEN
86a24040  tcp       0      0  172.16.1.116:3005  172.16.1.203:50559 ESTABLISHED
8b774680  tcp       0      0  172.16.1.116:49224 164.152.77.203:3005 ESTABLISHE
+D
. . .

as:  match '@' -or dv; dump_stcbq -lport 3005 -full
*************** STCP TCB @ 8B1931C0                                ************
    sth_dvtx                 = 51 (stcp.m16_18)
*************** STCP TCB @ 86A24040                                ************


as:  match '@' -or osl; dump_stcbq -lport 3005 -full
*************** STCP TCB @ 8B1931C0                                ************
*************** STCP TCB @ 86A24040                                ************
Q Name = osl
as:

as:  match '@' -or dv; dump_stcbq -lport 49224 -full 
*************** STCP TCB @ 8B774680                                ************
as:  match '@' -or osl; dump_stcbq -lport 49224 -full
*************** STCP TCB @ 8B774680                                ************
Q Name = osl
as:
Figure 4 - Sockets used by OSL

VOS (STCP - UDP)

This is a multistep process requiring that you manually follow pointers. The first step is to get the PCB address. You do this with the netstat command. I'll use port 58686 as an example, its PCB address is fe6e0700. The next step is to dump the PCB and find the qptr value. Then dump the stream associated with that qptr to get the q_next pointer. Follow that by dumping the stream assocaited with the q_next value but now you can match on the "dv" string to get just the device name (just like the TCP socket at this point). Finally we can do a who_locked on the device to find out who is using it.

 
netstat -numeric -protocol udp -PCB_addr -all_sockets
Active connections (including servers)
PCB       Proto Recv-Q Send-Q  Local Address      Foreign Address    (state)   
fe6f8600  udp        0      0  *:161              *:*
fe6f8800  udp        0      0  *:7                *:*
fe6fa000  udp        0      0  *:9                *:*
. . .
fe6f4100  udp        0      0  164.152.77.34:123  *:*
fe6ee200  udp        0      0  172.16.1.34:123    *:*
fe6f3b00  udp        0      0  *:58682            *:*
fe6f3d00  udp        0      0  *:58683            *:*
fe6e8600  udp        0      0  *:58684            *:*
fe6e9c00  udp        0      0  *:58685            *:*
fe6e0700  udp        0      0  *:58686            *:*
ready  10:51:23



as:  match qptr; dump_oneucb fe6e0700                                       
     ub_qptr                       87E8D400
as:  match
as:  match q_next; dump_stream -queue 87E8D400
    q_next    = 87E8D240
as:  match dv; dump_stream -queue 87E8D240
    sth_dvtx                 = 172 (udp.m15_58695)
as:



as:  ..who_locked #udp.m15_58695
udp.m15_58695:
     Object is write locked by Noah_Davids.SysAdmin (radius_auth_server) on
          module %phx_vos#m15 executing radius_auth_server.pm.
as:
Figure 5 - Finding the owner of a UDP socket

ftServer (2003)

Windows 2003 and Windows XP have added 3 control arguments to the netstat command. The first "-o" will display the PID of the controlling process (figure 5). Once you have the PID you can use taskmanager to map the PID to an EXE file. I don't recommend this approach, why do in two steps what you can do in one? Note to get the sockets in a LISTEN state you need to use the "-a" argument.

 
C:\Documents and Settings\Noah Davids>netstat -nao

Active Connections                                                             

  Proto  Local Address          Foreign Address        State           PID
  TCP    0.0.0.0:21             0.0.0.0:0              LISTENING       1844    
  TCP    0.0.0.0:80             0.0.0.0:0              LISTENING       1844
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       1056
  TCP    0.0.0.0:443            0.0.0.0:0              LISTENING       1844
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:1048           0.0.0.0:0              LISTENING       1844
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       976
. . .
Figure 6 - Windows netstat -nao - to display the sockets owners PID

The second new argument, "-b" will display the PID, loaded DLLs and the name of the EXE file (figure 6).

 
C:\Documents and Settings\Noah Davids>netstat -nab

Active Connections                                                             

  Proto  Local Address          Foreign Address        State           PID
  TCP    0.0.0.0:21             0.0.0.0:0              LISTENING       1844    
  [inetinfo.exe]

  TCP    0.0.0.0:80             0.0.0.0:0              LISTENING       1844
  [inetinfo.exe]

  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       1056
  c:\windows\system32\WS2_32.dll
  C:\WINDOWS\system32\RPCRT4.dll
  c:\windows\system32\rpcss.dll
  C:\WINDOWS\system32\svchost.exe
  C:\WINDOWS\system32\ADVAPI32.dll
  [svchost.exe]

  TCP    0.0.0.0:443            0.0.0.0:0              LISTENING       1844
  [inetinfo.exe]

  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
  [System]

  TCP    0.0.0.0:1048           0.0.0.0:0              LISTENING       1844
  [inetinfo.exe]

  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       976
  -- unknown component(s) --
  C:\WINDOWS\system32\ole32.dll
  [svchost.exe]
. . .
Figure 7 - Windows netstat -nab - to display the sockets owner's PID, components and EXE

The final argument "-v" when used with "-b" will display even more information about the components used in the EXE file (figure 7). I have no idea how Windows decides to display a loaded DDL with the -b switch or the -v switch.

 
C:\Documents and Settings\Noah Davids>netstat -nabv

Active Connections                                                             

  Proto  Local Address          Foreign Address        State           PID
  TCP    0.0.0.0:21             0.0.0.0:0              LISTENING       1844
  C:\WINDOWS\system32\WS2_32.dll
  C:\WINDOWS\System32\inetsrv\ISATQ.dll
  C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
  C:\WINDOWS\System32\inetsrv\ftpsvc2.dll
  C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
  C:\WINDOWS\System32\inetsrv\ftpsvc2.dll
  C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
  [inetinfo.exe]

  TCP    0.0.0.0:80             0.0.0.0:0              LISTENING       1844    
  C:\WINDOWS\system32\WS2_32.dll
  C:\WINDOWS\System32\inetsrv\ISATQ.dll
  C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
  C:\WINDOWS\System32\inetsrv\w3svc.dll
  C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
  C:\WINDOWS\System32\inetsrv\w3svc.dll
  C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
  [inetinfo.exe]

  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       1056
  c:\windows\system32\WS2_32.dll
  C:\WINDOWS\system32\RPCRT4.dll
  c:\windows\system32\rpcss.dll
  C:\WINDOWS\system32\svchost.exe
  C:\WINDOWS\system32\ADVAPI32.dll
  [svchost.exe]

  TCP    0.0.0.0:443            0.0.0.0:0              LISTENING       1844
  C:\WINDOWS\system32\WS2_32.dll
  C:\WINDOWS\System32\inetsrv\ISATQ.dll
  C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
  C:\WINDOWS\System32\inetsrv\w3svc.dll
  C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
  C:\WINDOWS\System32\inetsrv\w3svc.dll
  C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
  [inetinfo.exe]

  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
  -- unknown component(s) --
  [System]

  TCP    0.0.0.0:1048           0.0.0.0:0              LISTENING       1844
  C:\WINDOWS\system32\WS2_32.dll
  C:\WINDOWS\system32\RPCRT4.dll
  C:\WINDOWS\System32\inetsrv\INFOCOMM.dll
  C:\WINDOWS\System32\inetsrv\ftpsvc2.dll
  C:\WINDOWS\System32\inetsrv\inetinfo.exe
  [inetinfo.exe]

  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       976
  -- unknown component(s) --
  C:\WINDOWS\system32\ole32.dll
  [svchost.exe]
. . .
Figure 8 - Windows netstat -nabv - to display even more

You have to be patient with "-b" and "-v", it can take a while to generate the output; long enough that you may think something has gone wrong with the command.

ftLinux

On ftLinux you can use the "-p" argument with netstat to get the process ID (PID) and command associated with each ESTABLISHED and LISTEN socket (you need to use "-a" to get LISTEN sockets). You have to be root in order for this to work (figure 8). If you are not root you get an error message before the display. If there is a lot to display, the warning will scroll off the top of your window so you may miss it. The key is just a "-" where the PID/Command should be (figure 9).

 
[noah@164dhcp-1707-13092 ~]$ sudo netstat -nap | grep tcp
tcp   0   0 0.0.0.0:1152              0.0.0.0:*                  LISTEN      5026/ftltrapsubagen 
tcp   0   0 0.0.0.0:384               0.0.0.0:*                  LISTEN      5010/ftlsubagent    
tcp   0   0 0.0.0.0:199               0.0.0.0:*                  LISTEN      4995/snmpd          
tcp   0   0 0.0.0.0:777               0.0.0.0:*                  LISTEN      4835/rpc.statd      
tcp   0   0 0.0.0.0:111               0.0.0.0:*                  LISTEN      4816/portmap        
tcp   0   0 127.0.0.1:25              0.0.0.0:*                  LISTEN      5131/sendmail: acce 
tcp   0   0 0.0.0.0:764               0.0.0.0:*                  LISTEN      5249/sra_ssn        
tcp   0   0 ::ffff:127.0.0.1:32781    :::*                       LISTEN      5273/java           
tcp   0   0 :::22                     :::*                       LISTEN      5065/sshd           
tcp   0  48 ::ffff:164.152.76.141:22  ::ffff:164.152.77.50:2857  ESTABLISHED 20077/sshd: noah [p
Figure 9 - ftLinux netstat -nap - to display PID and command line executed as root

 
[noah@164dhcp-1707-13092 ~]$ netstat -nap | grep tcp
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp   0   0 0.0.0.0:1152              0.0.0.0:*                  LISTEN      - 
tcp   0   0 0.0.0.0:384               0.0.0.0:*                  LISTEN      - 
tcp   0   0 0.0.0.0:199               0.0.0.0:*                  LISTEN      - 
tcp   0   0 0.0.0.0:777               0.0.0.0:*                  LISTEN      - 
tcp   0   0 0.0.0.0:111               0.0.0.0:*                  LISTEN      - 
tcp   0   0 127.0.0.1:25              0.0.0.0:*                  LISTEN      - 
tcp   0   0 0.0.0.0:764               0.0.0.0:*                  LISTEN      - 
tcp   0   0 ::ffff:127.0.0.1:32781    :::*                       LISTEN      - 
tcp   0   0 :::22                     :::*                       LISTEN      - 
tcp   0   0 ::ffff:164.152.76.141:22  ::ffff:164.152.77.50:2857  ESTABLISHED - 
Figure 10 - ftLinux netstat -nap - to display PID and command line executed as regular user

Sometimes the command as displayed by netstat is not complete. You can get the complete command by going to the /proc/PID directory and looking at the cmdline file. Note that this file does not end in a new line so the prompt will follow the command line.

 
[noah@164dhcp-1707-13092 5065]$ cd /proc/20077
[noah@164dhcp-1707-13092 20077]$ cat cmdline
sshd: noah [priv][noah@164dhcp-1707-13092 20077]$                              
Figure 11 - Displaying the process' complete command line


Blue Bar separator
This page was last modified on 08-09-18
mailbox Send comments and suggestions
to ndav1@cox.net