Hardening ISA Server 2004 (Part 1)

If you would like to read the other part in this article series please go to Hardening ISA Server 2004 (Part 2).

An audit of the ISA 2004 server may reveal that it has not been hardened and that some attention has to be paid to this. This article will take the security professional through a step by step process of hardening ISA server 2004, focusing on the procedures necessary to assist in creating and sustaining a secure ISA Server 2004 environment. This involves the assessment of three categories which include securing the ISA Server computer, securing the ISA configuration and lastly securing the operation of ISA.

One of the main functions of using (ISA) Server 2004 is to protect your network or other resources from attack by malicious users, ISA Server does an extraordinary job, yet it is recommended to take exceptional care in hardening the ISA Server computer in order to optimize this functionality and securing itself and access to the ISA resources itself.

Hardening is the process by which one is able to enhance protection of the ISA firewall computer configuration as well as the operating system on which it is being run.

Third party Pentesting

Penetration testing is an excellent way to discover holes in your system This audit should be done by an experienced well versed third party organization and background checks on such an organization are essential. In fact think about what would happen if a street hacker were to do your pentest and find a vulnerability, would he tell you or secure a backdoor for himself? Only the paranoid survive. Do not just trust an organization, do reference checks and background checks, it could save your organization. Then pentest should uncover certain details that will help the organization when devising its security strategy.

Hardening the windows infrastructure

One needs to consider how ISA server functions and harden the operating system in view of that. Look at services, drive permissions and local accounts and utility access and available programs. More information about this process is available at: http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/hardeningwindows.mspx there is a document called Isaharden.doc follow the link for additional information.

Step 1: Securing the ISA Server Computer

The initial step should be to analyze the obvious, which is to determine whether the ISA server computer is physically secure. Physical security can be translated in basic security; the lack of this type of security can result in serious consequences, particularly because a malicious person could cause physical harm and modification to the ISA server itself by having unauthorized physical access. Authorized physical access is also a concern if the authorized personnel are not well trained and modify hardware and physical characteristics without control. Further detail will be covered below.

Configurations can be applied to assure the physical safety of the computer. Once this is verified the security professional can begin to consider other underlying issues. The recommendations involved in securing the ISA server computer are:

Physically securing the computer
This is an obvious but very important aspect to analyze, as not having a physically secure computer is a high security risk, which could potentially lead to unauthorized access of the server and tampering there of, influencing the integrity of the ISA and potentially the network and any resource attached. To avoid this latent threat one must ensure that the ISA Server computer is located in a physically secure environment which is always maintained and controlled with emphasis on secure controlled access to authorized individuals only. Additional physical security measures like CCTV and logged physical access control is best practice. Auditing who has entered the secure location and proving that the individual has entered is just as important as the technical control itself.

Managing the updates
Service packs are applications that are released after the public discharge of a certain software product. If a product that has been released is found to have a flaw, a hot fix is developed for that product and when the hot fixes are put together they form a service pack. The product does not function as it was intended without its service packs. Some service packs add functionality and rectify functionality that may have logic or circumstantial flaws. Security patches are also released occasionally to patch up software areas that have vulnerabilities and that programmers have not secured. Typically ISA server is not vulnerable to these flaws and it is a common misconception that it is, because ISA is installed on Windows it is vulnerable, when it really is not. ISA firewalls all traffic to and from the local host. It does this by installing a lower level network communication LSP type software that intercepts all traffic. All traffic will be scanned by the ISA engine and only if the traffic is allowed can the vulnerability be exposed and exploited.

Millions of users make use of the Windows platform daily and a multitude of these users are programmers and people with advanced technical skill. Some of these people like to stress test and find vulnerabilities within the Windows platform. When a vulnerability is found it may be days or even weeks before software vendors write an effective patch that is publicly released. This is especially true for alternate software that does not have the type of financial backing and support that commercial proprietary software has. The chance that your machine will be scanned and the vulnerability found is higher than you imagine. Whilst working at an extremely large ISP, the security manager showed me a brand new installation of an operating system on a desktop computer unpatched. Within ten minutes the computer had been scanned by other infected hosts and a worm had infected the computer.

Solution:
Keep all machines on the network updated and check with Microsoft and other vendors on a scheduled basis for service releases to software that you may be running. You may wish to automate this process but testing of patches and results thereof need to be verified. Underestimating this function can cost your organization many hours of down time equating to losses. If you do not want to become a statistic, ensure that your machines are properly patched.

Determining domain membership:
This only need be considered if the ISA server is going to be set up as a member of a domain. ISA server should never be run as a domain controller although it can and on SBS (small Business server) some modifications make this possible. In some high security configurations, complete domain isolation may be a consideration. Remember that once a computer is part of a domain, it has access to the domain even though it may be to verify accounts, it still constitutes a threat. An intruder will look for a computer that can do the dirty work, like do lookups on a domain to verify user accounts and or authenticate.

Account considerations:
Ensure that if you are using Windows NT and above that your administrative account is secure. Renaming the account to something ordinary is good practice then recreating another account named administrator. Giving that account the most restrictive privileges will give any intruder a challenging time if he does manage to gain access to your “bait” administrative account. However an intruder that understands how the account information is displayed will quickly figure out the accounts with the highest privilege. Account authentication across a network, like from the ISA server to the domain controller, if not properly secured can be a major vulnerability. For this reason, in high security environments, it may make sense to have an exclusive network card for authentication to the domain so that traffic does not traverse the typical network that can be sniffed. In this environment, confidentiality of the user identity presents the major risk and if the dedicated network card can not be used, encryption should be looked at.

Certain accounts on the ISA server are not needed and this can be easily checked and audited. It is strongly recommended that the unneeded accounts be removed and not disabled. This should be done before ISA is installed. I strongly recommend that no other accounts are added at a later stage as this can introduce a physical security risk.

Summary

In part two of this article, further hardening tips will be discussed. Patching and elements of physical security are all good and well, but it is not all that can be done to secure your ISA server. Look out for part two of this article to complete this education and provide your organization with a comprehensive solution.

If you would like to read the other part in this article series please go to Hardening ISA Server 2004 (Part 2).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top