If you would like to read the next part in this article series please go to ISA Server 2006 as a Kitchen Utensil: Part 2 – Internal Attacks.
Firewall as a kitchen accessory
People see firewalls like flaming walls, like a miraculous solution to the problems of security in the enterprise. Firewalls make people feel safe. Nevertheless firewalls do not make networks completely safe, however they do make them safer. In my opinion, firewalls are strainers, the size of the holes of the strainer depends on how the firewall is administered. Hackers are like the lumps that you don’t want in your juice.
Legitimate users are allowed access through the holes of the strainer. However, the security within these services is as important as the security of the firewall itself.
I have finished setting up my firewall, now what?
Now the difficult part begins, you will have to be sure that your firewall does what you think it does. Also, you will need to make sure that the security provided by the firewall does not degrade due to a bad administration.
In this article you will learn:
-
How to test an ISA 2006 Firewall
-
How ISA 2006 Firewalls react to attack.
-
Some tools that hackers could use to attack your network.
-
Some new functionalities in the 2006 ISA Firewall
The figure below provides a high level overview of the example network used within this article.
Diagram 1: Example Network
Don’t believe in it, prove it
After you install the ISA firewall and create the initial rules, the first thing you must to do is audit it. By auditing your firewall internally and externally you will have a clear vision about your real attack surface. The first thing that a hacker does when he wants to attack the system is find out all the information that is possible about it. One of the most valuable sources of information that hackers can use are port scanners.
A security administrator must know how his systems react to a scan and the information that hackers could obtain as a result of the firewall scan. One of the best known tools for port scanning is Nmap. Nmap is a free open source tool that supports dozens of scanning techniques; Nmap also provides some “stealth scanning” modes. You can find Nmap and more information at Insecure.org
Within security focused architectures it is common to find IDS and IPS’s that can detect port scans, however stealth techniques will try to deceive them. Now we will scan our test environment´s ISA firewall. In this example the ISA firewall is publishing a Web site on port 80.
Figure 1: Basic Nmap Scan (sS)
Nmap has detected an open port 80. But the ISA Firewall detected various strange things in the network activity; the number of connections that Nmap establishes to scan the firewall makes ISA log an alert.
Figure 2: Denied connections per minute alert
This alert is written to the event log, this event is easily captured by monitoring tools like MOM.
Figure 3: Denied connections per minute event
This alert is produced by the new flood mitigation features on the ISA 2006 Firewall. You will learn more about these new features within this article.
Although Nmap uses the SYN stealth technique, the ISA Firewall detected the traffic and denied everything except that sent to port 80.
Figure 4: Denied traffic
When the ISA Firewall denies a packet, the firewall drops the packet and the connection. The port scanners don’t know if the port is closed or filtered. Another technique is to use fragmented packets to scan the targets, however since the ISA Firewall only runs on Windows Servers, Windows by default discards all fragmented traffic. A scan with fragmented packets will produce no results.
The ISA 2006 Firewall, by default, doesn’t write an alert or event about port scans. In order to change this behavior you must activate the port scan detection feature:
Figure 5: Enable port scan detection (Step 1)
Figure 6: Enable port scan detection (Step 2)
For more information about these settings, you can read Microsoft´s article; ISA Server Port Scan Alerts.
After you enable these options, the ISA Firewall will log a port scan alert using the criteria you specified.
If you try to scan after this change you will see the following alert.
Figure 7: Port scan detected alert
An event is also logged.
Nmap provides other techniques for scanning:
Null Scan
From Nmap help: “The null scan (sN) does not set any bits (tcp flag header is0)”
The results of null scan in ISA are:
Figure 8: Null Scan Alert
Figure 9: Null Scan Events
Figure 10: Null Scan Events
Nmap didn’t find any port open although port 80 is open.
Figure 11: Null scan results
Figure 12: Detected traffic in firewall logs
FIN Scan
From Nmap help:”The FIN scan sets just the TCP FIN bit.”
The results of FIN scan in ISA are:
ISA doesn’t log any alert or event, but Nmap doesn’t find any port open although port 80 is still open.
Figure 13: FIN Scan results
Figure 14: Detected traffic in firewall logs
Xmas Scan
From Nmap help: “Xmas Scan sets the FIN, PSH and URG flags, lighting the packet up like a Christmas tree.”
The results of Xmas scan in ISA are:
ISA doesn’t log any alert or event, but Nmap doesn’t find any port open although port 80 is still open.
Figure 15: Xmas Scan results
Figure 16: Detected traffic in firewall logs
TCP ACK Scan
From Nmap help: “The ACK scan probe packet has only the ACK flag set (unless you use --scanflags). When scanning unfiltered systems, open and closed ports will both return a RST packet. Nmap then labels them as unfiltered, meaning that they are reachable by the ACK packet, but whether they are open or closed is undetermined. Ports that don’t respond, or send certain ICMP error messages back (type 3, code 1, 2, 3, 9, 10, or 13), are labeled filtered.”
The results of an ACK scan in ISA are:
ISA doesn’t log any alert or event, but Nmap doesn’t find any port open although port 80 is still open.
Figure 17: ACK Scan results
Figure 18: Detected traffic in firewall logs
TCP connect scan
When using a TCP Connect Scan, Nmap uses the underlying operating system to make a normal connect() to the ports. This scan is easily detected by IDS , IPS and of course ISA.
The results of TCP Connect scan in ISA are:
ISA logs an intrusion detection alert and event, Nmap finds port 80 open.
Figure 19: Intrusion detection alert
Figure 20: TCP Connect Scan results
Figure 21: Detected traffic in firewall logs
TCP Window Scan
From Nmap help: ”Window scan is exactly the same as ACK scan except that it exploits an implementation detail of certain systems to differentiate open ports from closed ones, rather than always printing unfiltered when a RST is returned. It does this by examining the TCP Window field of the RST packets returned. On some systems, open ports use a positive window size (even for RST packets) while closed ones have a zero window. So instead of always listing a port as unfiltered when it receives a RST back, Window scan lists the port as open or closed if the TCP Window value in that reset is positive or zero, respectively.”
The results of a TCP Window scan in ISA are:
ISA doesn’t log any alert or event, but Nmap doesn’t find any port open although port 80 is still open.
Figure 22: TCP Window Scan results
TCP Maimon scan
From Nmap help: ”The Maimon scan is named after its discoverer, Uriel Maimon. He described the technique in Phrack Magazine issue #49 (November 1996). Nmap, which included this technique, was released two issues later. This technique is exactly the same as Null, FIN, and Xmas scans, except that the probe is FIN/ACK. According to RFC 793 (TCP), a RST packet should be generated in response to such a probe whether the port is open or closed. However, Uriel noticed that many BSD-derived systems simply drop the packet if the port is open.”
The results of TCP Maimon scan in ISA are:
ISA doesn’t log any alert or event, but Nmap doesn’t find any port open although port 80 is still open.
Figure 23: Denied connections alert
Figure 24: Scan results
|
|
sS |
sN |
sF |
sX |
sT |
sW |
sM |
|
Detect Open Ports |
Yes |
No |
No |
No |
Yes |
No |
No |
|
Raise Event |
Yes |
No |
No |
No |
Yes |
No |
No |
|
Raise Alert |
Yes |
No |
No |
No |
Yes |
No |
No |
|
Scan Detected |
Yes |
Yes |
No |
No |
Yes |
No |
No |
|
Denied Traffic Detected |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Table 1: Port Scanning ISA Server 2006
Reacting to a port scan
With ISA Server you can react to an attack by executing an action on alert.
Figure 25: Configure alert definitions
Figure 26: Modifying Intrusion detection alert definition
Figure 27: Configure alert Actions
It is easy to make a script that blocks all traffic from the source of attack.
Firewall Fingerprint
Nmap also provides an OS detection feature. This feature uses a database of stack fingerprints. Nmap and other tools can detect that the firewall is in a Windows box, but for this, they need at least one open port and one closed port.
Security focus is a recognized vulnerabilities database, if an attacker tries to find ISA 2004, 2006 vulnerabilities they will not find anything of value, only one vulnerability with no influence on firewalls, only on proxies!!.
Figure 28: Security Focus ISA 2004 vulnerabilities
Conclusion
If an attacker accepts the risk of being detected, he would find our open ports. The next step would be to try and attack the services being publishing with the firewall.
For this job the attacker will use vulnerability scanning tools like retina, nikto, etc, but this is not the objective of this article.
Your firewall could be secure, but if you publish an NT 4 server with an IIS 5 web site, be sure that your network is not secure. You must secure all your servers and services, especially the published ones.
In the next part of this article we’ll see how ISA Server reacts to attacks coming from the internal network, like ARP poisoning, spoofing and man in the middle attacks.
If you would like to read the next part in this article series please go to ISA Server 2006 as a Kitchen Utensil: Part 2 – Internal Attacks.
