This is the second installment in a series of articles on automated security scanners and how to interpret their output. You can find part one of this series here.
In this article I will be digging deeper into how port scanning can help narrow the source of a finding.
Automated scanners generally provide both a summary of the issues found and a more detailed report for each finding. Both sections will contain information that is useful during the triage process but, crucially, they provide an insight into how the tool has identified a potential issue. The two common types of response I mentioned last time were how the tools interpret the results of port scanning and response to invalid HTTP requests. Today I’ll expand on the first of these two methods and provide you with some tips on how to investigate further.
Port Scans: Identifying Ports and Processes
One of the first tasks that a scanning tool will carry out on a live server is a port scan. This simple test provides the tool with a list of which ports (TCP and UDP) on the server are open and, from the responses that it gathers, allows it to make an educated guess on what services are running on the target machine.
On a typical XenApp or XenDesktop server, only some of the ports will be directly related to the Citrix components and services, the rest will be used by the underlying operating system and other services that are running. One technique for identifying running services on a Windows Server is the Windows netstat command.
The screenshot above shows the result of running netstat from the command prompt with the option –an (note that this command requires Administrator privileges to run). The output shows which ports on the local host are open and listening for connections FROM remote machines (for example port 80 in the example above) and which local ports are being used for established TCP connections TO remote servers.
It should be noted that a server component will typically use a lower numbered TCP port for incoming connections, whereas the higher numbered ports (for example TCP port 42146 in the example above) will be used by the machine for outgoing established connections.
Further information on what processes are being used for established connections can be carried by running netstat with the –b option. This, again, requires Administrator permissions to run and will produce an ordered list of open ports and the processes that are using them. An example of this is below:
This screenshot shows the complete set of TCP connections that the operating system has open together with the process that is responsible for the connection and the destination IP address or server.
With both sets of port information to hand, it is possible to match up the open ports from the scanning tool’s report with the process that is using that port, something that will allow you to know exactly who to contact for further information about a result.
Stay tuned for the third article in this series: How to record and interpret HTTP request/response transcripts.