For this worked example I am going to communicate with the target server (the server with the firewall) using PSEXEC for remote execution. You could just as easily work on the sever console or use PowerShell.
As usual, I like to explain by real-life example.
A colleague is setting up a Windows Print Server and Microsoft have provided the required protocols and ports to be opened, surprise, surprise the information is incomplete.
Step One
Examine the Windows Firewall Log. By default is resides at:
\\MyServerName\c$\Windows\System32\LogFiles\Firewall
We can see that when the engineer tries to remotely install a driver, packets are dropped. In the log it looks like this (I have removed the date and time for brevity)
You can look at the heading in the firewall log, but I have highlighted the destination port.
DROP TCP 10.150.85.240 10.20.68.183 12387 9001 48 S 4157967098 0 8192 - - RECEIVE
DROP TCP 10.150.85.240 10.20.68.183 12388 9001 48 S 3357802324 0 8192 - - RECEIVE
In this imaginary scenario, it looks like we are dropping TCP 9001 (if you already know what that is, pretend you don't for the sake of this tutorial). So the next step would be to track down what that port is being used for and whether we should be opening it. We need to get onto that server, either:
- PowerShell
- Console
- RDP
- PSEXEC
First we will run the built-in Windows tool 'NetStat' using the syntax:
netstat -an -o
Which will display all the ports on which the server is listening. The '-an' means supress the resolution of the IP address to which to the server may have a connection. This makes the command run much faster. The '-o' means display the running process which is what we want. The output will look something like this:
Active Connections
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 992
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:5357 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:5985 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:8081 0.0.0.0:0 LISTENING 3812
TCP 0.0.0.0:8092 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:8495 0.0.0.0:0 LISTENING 3812
TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:49664 0.0.0.0:0 LISTENING 680
TCP 0.0.0.0:49665 0.0.0.0:0 LISTENING 884
TCP 0.0.0.0:49666 0.0.0.0:0 LISTENING 1320
TCP 0.0.0.0:49669 0.0.0.0:0 LISTENING 2212
TCP 0.0.0.0:49670 0.0.0.0:0 LISTENING 760
TCP 0.0.0.0:49699 0.0.0.0:0 LISTENING 752
TCP 0.0.0.0:49710 0.0.0.0:0 LISTENING 3812
TCP 0.0.0.0:49713 0.0.0.0:0 LISTENING 760
TCP 10.150.210.201:9001 0.0.0.0:0 LISTENING 42
TCP 10.150.210.201:50495 10.20.104.6:443 ESTABLISHED 10744
TCP 10.150.210.201:50496 10.20.104.6:443 ESTABLISHED 10744
TCP 10.150.210.201:50497 10.20.104.6:443 ESTABLISHED 10744
We can see (highlighted) that port 9001 is being listened to by a process with PID (Process ID) 42. We now need to know what that process is. We can use the SysInternals tool 'tasklist', just run it and it should produce an output something like this (I have trimmed the output for clarity):
Image Name PID SessionName Session# Mem Usage
==================== ==== ============= ======= ===========
System Idle Process 0 Services 0 4 K
System 4 Services 0 2,764 K
svchost.exe 836 Services 0 23,516 K
svchost.exe 884 Services 0 16,544 K
svchost.exe 1104 Services 0 26,160 K
WUDFHost.exe 1184 Services 0 2,984 K
svchost.exe 1320 Services 0 65,344 K
dasHost.exe 1744 Services 0 6,912 K
svchost.exe 2020 Services 0 6,648 K
hpservice.exe 1256 Services 0 1,144 K
svchost.exe 1080 Services 0 4,808 K
svchost.exe 2156 Services 0 9,364 K
spoolsv.exe 42 Services 0 16,140 K
wrapper.exe 2408 Services 0 2,336 K
mDNSResponder.exe 2424 Services 0 2,832 K
If we examine this list we can see (highlighted) that PID 9001 is 'spoolsv.exe' so this all provides us with a set of clues:
- When we investigate the origin of the dropped traffic in the firewall log we discover that the IP belongs to the workstation we are testing our PrintServer from.
- Researching port 9001 reveals it to be the HP JetDirect printing port.
- Spoolsv.exe is the Windows Print Spooler.
So good bet this is something we need to open on the firewall of the printserver.
No comments:
Post a Comment