When I wrote my series on how to secure your ISA Server installation, I had it in mind that ISA Server administrators could use the information to confirm whether or not their ISA Server installations we’re secure. We got some good feedback on the series, but you wanted more! Specifically, you wanted to know how you could test (via port scanning tools) what ports and services were visible and available on the external interface of the ISA server.
This is a reasonable request. There’s nothing like seeing that your external interface is not responding to anything except what you want it to respond to! To meet this goal, we’ll talk about the following topics:
After you’re done reading this article you’ll have a better understanding of port scanning and be able to use port scanning tools to investigate the port status on the external interface of your ISA Server.
What is Port Scanning?
Port scanning is a method of detecting if a server is operational and if there are open ports on a network interface. The reason why you would perform a port scan depends on your point of view. If you are looking to break into a machine, you want to know what “doors and windows” are open. If you are looking to defend your machine, you want to know if there are any portals of attack an enemy might exploit.
There are two ways to scan a computer:
Let’s look at these in more detail.
ICMP scans are not really port scans. There reason for this is that ICMP doe s not use ports as an endpoint. Instead, the ICMP scan just looks to see if a machine can respond to IMCP messages.
For example, when you ping a machine, you send out an IMCP Echo Request. The ICMP Echo request contains a directive for an ICMP Echo Reply from the destination host. If the destination host is configured to respond to ICMP Echo Request messages, it will return an ICMP Echo Reply. If the machine cannot send an ICMP Echo Reply, you’ll likely get a message that the Request timed out as seen below.
ICMP ping scans are a quick and dirty way of checking if anyone is home. If you were a not very bright burglar, you might go from house to house and knock on all the doors to access whether anyone was home. You then assume that if no one answers the door than its safe to begin the crime of home invasion. Of course, if you broke into a home on my street here in Texas, you’d be staring at the business end of a 12 gauge.
So, while you can use ICMP scans for a quick reconnaissance mission, you certainly don’t want to depend on them if you’re interested in a detailed reconnoitering of the joint.
In contrast to ICMP scans, TCP/UDP scans give you useful information about the open ports on a network interface. These TCP/UDP ports are required to create the socket that you need to create a connection with a destination computer.
A socket is the endpoint of TCP/IP communications. A socket is made of the following components: a port number, an IP address and a protocol (TCP or UDP). This is in contrast to ICMP, where a socket connection is not created (ICMP packets do not use port numbers).
There are a number of approaches you can take to TCP/UDP scans, but one way of looking at them includes the following:
TCP “IP Half Scans”
To establish a TCP session, the two computers participating in the session must first go through what is known as the “three-way handshake”. The three way handshake goes something like this:
Client: sends a message with the SYN flag on
Server: replies to the client with a message that has SYN and ACK flags on
Client: replies to the server’s SYN/ACK message with an ACK message
During the three-way handshake, various TCP/IP parameters are set that insure the two machines are able to participate in a TCP session. After the handshake is completed, a session is established and the machines can start transferring Application Layer data.
If you want to know what TCP ports are open, you can generate a three way handshake on all TCP ports at the destination computer. This can be a time consuming process, so you might want to speed things up by only investigating ports of interest.
Another way of speeding up the investigation for open TCP ports is to eliminate the final ACK message sent by the client. You don’t need to establish a TCP session with the destination computer; you just need to know if a port is open and responding to connection requests. You can do this by eliminating the third phase of the three-way handshake. You still get the information you need, because all you need to know is if the server responds with the SYN/ACK message.
The TCP half scan is a good way of enumerating the open TCP ports. Other techniques can be applied to the identified ports to assess whether more information can be gleaned from them.
Scanning UDP Ports
UDP port scanning works a bit differently because UDP communications do not establish sessions. Therefore, you can’t take advantage of the three-way handshake to determine open UDP ports.
If you scan for UDP ports, the destination computer will respond differently depending on how ICMP is configured on the destination computer. If you send a packet to a UDP port and you don’t get a reply, you might be able to assume that the port is available. If you send a UDP packet to a computer and receive an ICMP Destination Unreachable message, then you can assume that the UDP port is not available.
The problem with this method of UDP scanning is obvious. If the administrator has configured the machine to not return ICMP Destination Unreachable messages, the scanner will assume that all UDP ports are available. This makes a quick assessment of UDP ports difficult, because you’ll have to carry out further investigations against all ports, rather than a nice subset of all possible ports.
This is not to say that UDP port scanning is impossible. If just means that you have to be more circumspect about your scanning procedure when ICMP Destination Unreachable messages are disabled. For example, if you want to ascertain whether UDP is open, you’ll have to do something like send a DNS query message to the machine at UDP 53.
Source Port Manipulation
Source port manipulation is not exactly a form of scanning, but rather a method that can be used in conjunction with either TCP or UDP scanning. Source port manipulation is used to get by packet filters that are set on routers and firewalls.
FTP provides a good example. If you’re trying to configure a router to allow PORT mode FTP clients to work, you are going to need to allow new (non-ACK) inbound connections from FTP server TCP port 20 to all high ports (>1024) inbound into your internal network. Some router/firewall administrators will try to improve on the atrocious security situation by allowing non-ACK packets inbound to high-number ports only from TCP port 20. The port limitation helps us deal with the situation where the PORT mode FTP client requires the FTP server to create a new inbound connection to complete the data channel.
Source port manipulation lets you get around these problems by changing the source port your requests are sent from. If you change your source port from a random high-number port to TCP port 20, the router/firewall will allow inbound new connection requests to high-port number. Not bad! This method can be used to probe any service that expects to receive connection requests from a specific port number.
Tools of the Trade
There are a tremendous number of network scanners on the market. It would be impossible for me to do justice to even a tiny fraction of them, or even a fraction of what I consider good ones. However, there are two that I especially like. One is a GUI scanner and the other a command line scanner. These are:
Both of these scanners are free!
LANguard Network Scanner
The LANguard network scanner is a powerful and flexible GUI based scanning tool. There are a great number of options includes with this too, including:
We’ll take a look at how the LANguard Network Scanner works when we scan our ISA Server computer. You can obtain the LANguard Network Scanner at http://www.gfi.com/languard/lanscan.htm
FScan is the premiere command line port scanning tools provided by Foundstone (www.foundstone.com). The features provided by FScan are almost too numerous to count! Some of the more useful features include:
You can get the FScan tool at http://www.foundstone.com/knowledge/free_tools.html. Click the SCANNER link and select FScan v1.12 (or whatever the latest version is at the time you carry out the download).
Probably one of the most useful tools our there for port scanning and a lot more is netcat. Netcat (http://www.atstake.com/research/tools/nc11nt.zip) allows you to do many things, including the following:
This is a tool you should check out, especially if you’re doing advanced reconnaissance.
We’ll look at how to carry out scan against the external interface of the ISA Server using Fscan in the next section.
Scanning ISA Server’s External Interface
Now for the moment of truth: Scanning the external interface of the ISA Server. When you first install ISA Server, it should have packet filtering enabled. Always check that this is the case by right clicking on the IP Packet Filters node, click Properties and put a checkmark in the Enable packet filtering checkbox.
Once packet filtering is enabled you can begin your scan on the ISA Server’s external interface. You can use the default LANguard settings to scan the ISA Server. Make sure that you carry out the scan from a client on an external network! Your scan results will not be entirely accurate if you scan from an internal network client. Remember, you want to be able to see what the external network attacker will see when he scans your ISA Server.
With packet filtering enabled, you should see the following:
That’s exactly what you should see with the default installation of ISA Server with packet filtering enabled and the default ICMP packet filters configured. Note that at this point no Web Publishing or Server Publishing Rules and no Incoming Web Proxy listeners have been configured. When you configure publishing rules, the ports that you have been configured to listen for the various published servers will become available to the port scanner.
Open ports are open ports! If you publish services the ports will be open. They must be open if you wish external network clients to establish connections to your internal network servers. There is no way to “stealth” or otherwise hide open ports. This seems to be a common misunderstanding among junior ISA Server administrators that I encounter.
Compare the results of your port scanning adventure against what you see when you do a netstat –na port enumeration on the ISA Server computer.
Wow! Look at all those ports are that listening on all interfaces. These are the ones with the IP address 0.0.0.0 for the local address. These ports do not show up on the port scan because the ISA Server packet filters prevent them from accept connections.
You can also use FScan to scan the external interface of the ISA Server. At the command prompt, do a fport /? and you’ll see:
With this information, we can do a quick (well, maybe not that quick) port scan on the external interface of the ISA Server by issuing the following command:
Fscan -p 1-65535 -u 1-65535 192.168.1.125 -o c:\isa.txt
You’ll see the following output after the scan is complete:
Not very interesting. That’s because the scanner didn’t find any ports open.
Now, let’s turn off packet filtering on the ISA Server and see if the situation changes:
This is only a partial listing of the open ports. But as you can see, without packet filtering enabled, your ISA Server is a sitting duck, especially if the external interface is directly connected to the Internet. There are very few situations when you would not want packet filtering enabled. One scenario might be when the external and external interfaces are connected to trusted networks. However, even in this situation, you will have a lot of work ahead of you in terms of hardening the server.
If you want to see what’s going on, open up the Network Monitor on the machine and capture some packets. You’ll be able to easily trace the port scan.
Check this Out:
When you restart your ISA Server computer, the machine will not be protected until the ISA Server services initialize. Take a look at the following:
The first scan was started as the machine was booting up. You can see that FScan is enumerated several dangerous open ports. I stopped the scan and restarted it about 15 seconds later. The scan then detects no open ports at all.
The following requests were issued as the ISA Server was starting up:
You’ll notice that at 17:06:43 TCP 25 as open, but FScan could not grab a banner (that’s what the –b switch does). At 17:06:45 the ISA Server packet filters kick in. So, in spite of the fact that the port reports as open, its most likely that no information could be passes through this port, since not even a banner could be grabbed during the time it was opened.
In this article we examined some aspects of how ports scanning works and how to use some common tools used to perform port scanning. We then took at look at how the external interface of an ISA Server responds to port scanning with and without packet filtering enabled.