ISA for Dummies

TERMS
This document and what comes with it are provided as-is with blunt warning: Use at your own risk, buyer beware. You break your system; you own the resolution as well. We have no liability for what you do, or cant do, or fail to do with this information. Your entire protection is to start over again with a protected backup, or from protected system. If you dont want to accept this idea, please dont use this document.

DISTRIBUTION AND DUPLICATION GUIDELINES

This document is not free.

If you received this document from any other source than Smallbizserver.Net, please contact us to become a subscription member. Smallbizserver.Net Tech Docs are licensed per technician. Smallbizserver.Net understands your need to protect your investment in the tools and documentation provided in your Smallbizserver.Net Tech Docs. We consider it fair and reasonable use for you to make as many backup copies of any of these items as is necessary to protect yourself from loss or damage. We also understand that you may wish to maintain multiple copies for the purpose of keeping references and tools in more than one location you can work from in the course of a project, or on more than one device, or for continuing use. We expect at all times that you would have the thought in mind that each copy you make is either for a backup to protect against loss, or a copy you have made to facilitate your active work process, but for no other reasons. Leaving copies for others to use is not a permitted use. You may not place any hard copy or electronic copy of any portion of a Smallbizserver.Net Tech Docs documentation or tool (or tool code) in a location that provides anonymous access. You may not store or locate the Smallbizserver.Net Tech Docs tools or documents in a manner which encourages, or permits violation of the license agreement or copyright such as with file swapping technologies. Under no circumstances are you permitted to abstract portions of this document and share them with anyone else, without obtaining specific and written authorization from Smallbizserver.Net for that purpose, and on that occasion, such as for a periodical review. This means that posting sections of documentation to the Internet or public network, or a chat room, or a private network are all examples in violation of our license and copyrights because they do not represent a backup or reasonable use.

Page 1 of 10

An overview into the inner workings of Microsoft's Internet Security and Acceleration Server 2000.

A Practical Introduction to Microsoft Internet Security and Acceleration Server for Microsoft Small Business Server 2000 System Administrators
Watching the activity on the Microsoft.public.backoffice.smallbiz2000 newsgroup, I see a lot of questions regarding Internet Security and Acceleration Server (ISA). Unfortunately, many of the resources available online only provide solutions or work-arounds for specific issues, or instructions on what steps to take to get certain functionality, but never go the extra step to explain why those steps work, or how the various pieces fit together and form the big picture. In doing so, those resources neglect one of ISAs single greatest features: its elegant simplicity. Dont rub your eyes or check to see if your glasses need cleaned yes I just described ISA as both elegant and simple. The goal of this paper is to communicate and demonstrate that simplicity so that administrators will possess a better understanding of how ISA works, which will not only assist them in their duties of maintaining their Small Business Server installation, but it should allow them to better understand and address security issues as well as increase their confidence in ISA. I will note that I do not purport to be any sort of expert on ISA. I am however, an SBS administrator and consultant who learned what I know of ISA by getting my hands dirty. Ill admit that I didnt have the slightest idea how ISA worked when I installed my first SBS which, thankfully was an internal installation long before I started supporting Small Business Server professionally. One day I was trying to get file sharing for MSN Messenger to work, and for the life of me I could not resolve the issue. I called it a night and went home. The next morning I came in, and had one of those experiences where that last neural connection was made, the lights came on and voila! So thats how ISA works! I immediately wondered why anyone hadnt written a basic reference that described how simple ISA really was, and how the parts fit together. Hence the idea for this paper was born.

ISA as the Gatekeeper

Anyone with a basic understanding of ISA knows it can perform two primary tasks: act as a firewall and as a web cache. Since we very rarely see many questions regarding the web cache functions of ISA, or misconceptions and confusion regarding web caching, it will not be addressed in this paper. Instead, we are going to focus on ISA as a firewall. To get an understanding of how ISA protects your network, we must first look at the different ways ISA protects your SBS network. ISA provides protection on two separate fronts, protecting against external and internal threats. The primary role of ISA as a firewall is to protect your SBS from external (internet) threats. For right now, forget about any clients on the network our only concern is the SBS itself one box with an internet connection. So how does ISA protect this box? Simple - packet filters. Simply put, packet filters are rules that determine what traffic is allowed to enter or exit the server itself. For an ultimately secure server, we would not accept any packets from the internet or allow any packets to leave our server. However, if we didnt want to allow any packets in or out, we wouldnt need an internet connection at all, and wouldnt need ISA. But in reality, we may decide that we want to host our own email, so we have to accept email traffic from the internet which requires a packet filter allowing inbound traffic on port 25. The good news is that if you have a standard installation of SBS, the Internet Connection Wizard (ICW) creates all of the necessary packet filters for you, allowing for email, VPN, and any other traffic you chose to be able to access your server from the internet. If you do not have 3rd party software installed on your SBS that requires internet access, you should not need to manually adjust the default packet filters created by the ICW. Any adjustments to these packet filters are best made by running the ICW. However, on occasion, you may need to create your own packet filters for third party software on the server that needs to access the internet, such as anti-virus software or to configure your server to reach an internet time server. Creating packet filters is simple and straight forward, so long as you have four key pieces of information: The IP protocol (ICMP, TCP or UDP), the direction you want (Inbound / Outbound) and the local and remote ports. Luckily, this information for most software titles can be found online through simple searches at groups.google.com, or by contacting technical support for the software title that needs access. When it comes to specifying the direction on your packet filter, allowing inbound traffic will result in your server accepting connections from the internet on the port you specify, and that port will show as open on a port scan. Allowing outbound access simply allows apps on your server to access the internet using the port you specify. A port listed in an outbound packet filter will not show as open on a port scan. If you do encounter the situation where you have to create your own packet filters (or modify existing filters), remember that when the ICW is ran, all existing packet filters are disabled. Therefore, you will need to go into ISA Management and re-enable any custom filters you had created.

Page 2 of 10

I strongly suggest that SBS administrators download the SuperScan tool from Foundstone. (www.foundstone.com/knowledge/proddesc/superscan.html) and use this tool to scan your external IP address. I should note that I have gotten false positives (reported open ports that are actually closed) when running SuperScan from inside the LAN, thus I would suggest running SuperScan from outside your network. SuperScan will list any open ports you may have, allowing you the opportunity to close any unnecessary open ports before a problem arises. And just how do you close an open port? By disabling the packet filter that is allowing inbound traffic on that port. You may notice that a port scan is indicating that ports 80 and 443 are open, even though you cannot find any packet filters allowing traffic on those ports. To find out why these ports show as open and find out how to close them, check out Why does GRC.com report that port 80 and 443 are open? In summary, if you want your server to accept incoming connections from the internet, you need to create an inbound packet filter. If you have an application on your server that needs to access the internet, you will need to create an outbound packet filter. For the most part, packet filters are that simple. If you have any questions on what a specific port is used for, check out www.eventid.net/searchprot.asp or www.iana.org/assignments/port-numbers

ISA as the Babysitter

Ok, we have discussed packet filters, focusing on the SBS itself, but lets be realistic if we have an SBS, we have workstations, and ISA is responsible for them as well. ISA uses protocol rules to control workstations internet access. Protocol rules work just like packet filters, the only differences are that protocol rules only allow outbound traffic, and protocol rules only apply to ISA clients, where packet filters apply to the ISA server itself. One of the primary benefits of a quality firewall (including ISA) is that they can dynamically open ports as necessary to allow outbound traffic. For example, when a user logs on to MSN Messenger which uses port 1863, they are able to connect to the Messenger service and send and receive text messages, yet a scan on your external interface will show port 1863 closed how can this be? ISA dynamically opens ports as they are needed.. When the user signs on to Messenger, ISA forwards the request from the client to the IP of the messenger service server and upon receiving a response, initiates a conversation, opening the necessary port (1863), but it only accepts inbound traffic on that port from the IP address of the server ISA originally contacted. Thus your user can chat while the port they are using still appears closed to the rest of the outside world. ISA can act as a babysitter for users & workstations, controlling what programs / computers / users have access to the internet from protocol rules and site and content rules. Protocol rules are exactly what they sound like: rules that either allow or block internet access to specific protocols. These rules offer impressive flexibility allowing you to not only specify the protocol you want to control, but also establish a schedule for when the rule applies as well as specifying the individual users, security groups and/or computers the rule applies to. On a default SBS installation, the ICW creates a BackOffice Internet Access Protocol Rule, which grants all users in the BackOffice Internet Users security group access to any internet resource at any time. While the creation of this protocol rule allows clients to have remote access after the firewall client is installed, it is not the most secure option. It is important to understand that having this default protocol rule enabled does not expose your SBS or network to internet born attacks. This rule simply allows internet access to any application on an internal client that wants it. When you think of all of the applications you would prefer to not have access, let alone the possibility of Trojans, there is a definite benefit in disabling this default protocol rule and creating your own rules for allowed internet traffic. I will admit that on a fresh installation, creating the necessary protocol rules may take a little time, however the majority of this time is spent determining which applications use which protocols, not creating the protocol rules themselves. Creating protocol rules are actually very easy. For this example, we will create a protocol rule to allow users to access internet newsgroups. Open the Administrator Console, and locate protocol rules under Internet Security and Acceleration Server | Servers and Arrays | | Access Policy. Clicking Action | New | Rule will open the Protocol Rule Wizard:

Page 3 of 10

Figure 1 - New Protocol Rule Wizard Enter a meaningful name for your protocol rule and click Next. On the next screen, select to Allow and click Next.

Figure 2 - Protocol Selection Screen

Page 4 of 10

On the Protocols page, change the Apply this rule to field from All IP Traffic to Selected protocols, and select the protocols you want to allow from the list. For our example, we select NNTP. Click Next On the following page, you have the option to select the schedule that you want to apply to this rule. By default, ISA has two schedules defined, Work hours and Weekends in addition to the default choice of Always. For our example, we will select Always. (Later in the paper we will discuss how to define your own custom schedules). The next page lets us define who this rule will apply to. Best practice is to not allow access to Any Request only grant access to users and groups that need it. Lets assume that you want all users who are allowed internet access to be able to read newsgroups. Select Specific Users and Groups and click next. You will then be presented with a page where you can select those users and groups. Click Add, then select the BackOffice Internet Users security group, click OK, click Next and click Finish. Creating a protocol rule is that simple. I mentioned earlier that we would look at how you can define your own custom schedules. A little further down in the ISA snap-in, you will see an entry for Policy Elements. Expanding policy elements reveals several groups of elements that can be mixed and matched to create protocol as well as site and content rules. Obviously we can create our own schedules by selecting the schedules folder, then clicking Action | New | Schedule. Creating a schedule in ISA is very intuitive and works just like creating a schedule for user access to the network in Active Directory. You will notice that under Policy Elements, there is also a protocol definitions group. This group contains all of the protocols currently defined in ISA, which is the group of protocols that appeared in figure 2 above. While ISA includes definitions for the most common protocols, it does not have a complete list, so you may need to define protocols for certain software, with one example being MSN Messenger. If you browse the list of defined protocols, you will notice that ISA already has a protocol definition for MSN Messenger, however this definition only permits text chatting it does not allow for file transfer or voice conversations. To enable this functionality, lets create a new protocol definition. Start the new protocol definition wizard.

Figure 3 - New Protocol Wizard On the first page, enter a meaningful name, such as MSN Messenger Full. On the second page, enter the primary connection information. For its primary connection, Messenger uses port 1863, protocol type TCP and direction equals outbound. The following page lets you define any secondary connections. Enter the following secondary connections,

Page 5 of 10

depending on what type of functionality you want from Messenger. Click Next and Finish.

Functionality File Transfer - Send* File Transfer - Receive Voice Conversation ** Voice Conversation

Port Range 6891 - 6900 6891 - 6900 6901 5004 - 65535

Protocol type TCP TCP TCP UDP

Direction Outbound Inbound Outbound Send Receive

*Allowing users to send files via instant messaging is NOT recommended without auditing software such as IM Sentry(www.evgl.com/imsentry.html) **ISA only allows accepting of inbound voice conversations. Users cannot initiate voice conversations behind ISA. Destination Sets, Client Address Sets and Content Groups are policy elements that apply to Site and Content Rules. Destination Sets include internet domains you want to either explicitly allow or deny access to. Client address sets are just like destination sets, except that instead of including internet domains, they include internal workstations. Last, content groups are just as they sound groups that specify content, such as applications, images and documents. As an example, lets assume you own an automotive repair shop and you want your technicians and parts personnel to be able to lookup service bulletins, schematic drawings and part information from an online service such as All Data, but you dont want these same employees to be able to access any other web sites. Accomplishing this task is simple, and can be handled with a Site and Content Rule. Before we can create these rules, we must first define the appropriate Client Address Sets, which will list internal PCs, as well as the necessary destination set, which will list alldata.com. Expand Policy Elements and click on Client Address Sets. Click Action | New | Set. Enter a logical name and description (i.e. name = Shop + Parts and description = PCs available to Shop & Parts Personnel), then click Add to add the IP addresses of the PCs you want to include in this set. Next, we need to define our destination set. Click on Destination Sets, then Action | New | Set. Enter the a logical name and description, then click Add. Select destination then specify *.alldata.com. Click OK to save the destination set.

Page 6 of 10

Figure 4 - Example Destination Set Once we have created our client address set and destination set, we can create our Site and Content Rule. Click on Site and Content Rules under Access Policy, then click Action | New | Rule to start the wizard.

Page 7 of 10

Figure 5 - New Site and Content Rule Wizard Enter a logical name for your rule, often using the primary site or content that will be defined in the rule is a good idea. On the second screen, select Allow as the Rule Action. For the Rule Configuration on the third screen, we will select Custom. Next, select Specified Destination Sets, then select the All Data destination set we just created. The following screen lets you specify a schedule (if any) to apply to this rule. For Client Type on the next screen, select Specific computers (client address sets). You can then specify the Shop + Parts client address set we created. The last option screen lets you specify what type of content this rule will allow. You may allow any content, or restrict the content as necessary. For example, virtually all of the information your technicians and parts personnel would need from All Data resides in html pages or images. Therefore, you could specify html documents and images as the only allowed content. If the default BackOffice Internet Access Rule is not disabled, the PCs in the client address set will still be able to access all websites. Only by disabling the default rule will you be able to restrict the access of internal clients. If you have other PCs that you wanted to grant full access to, you would create another client address set that included those PCs, then create a new Site and Content rule that allowed that client address set to access all destinations. As a side note, since Client Address Sets identify clients by their IP address instead of using a NetBIOS name or Mac address, I would suggest going to your DHCP properties and changing the IP lease to never expire for any client included in a Client Address Set. This way you dont have to worry about your site and content rules being side-stepped when a workstation gets a new IP address. I have not had the chance to test the ability of Client Address Sets with dynamic IP addresses to determine if the set adjusts accordingly, or if it is required to ensure that the client IP address does not change. The last realm of control ISA has over clients is the firewall client itself. You can block unauthorized applications in the firewall client. For example, lets assume you do not want users to be able to use AOL Instant Messenger. You will notice Client Configuration listed below Internet Security and Acceleration Server | Servers and Arrays | . Click on Client Configuration, then double-click on Firewall Client in the right hand pane. Click on the Application settings tab, then click New. For name, enter the executable file name without the extension (in this case, aim), for the Key select Disable, and set the value to 1. By disabling aim.exe in the firewall client, the firewall client will not provide proxy services to the specified application, thus blocking access. It is important to note that the firewall client updates itself automatically every 6 hours. If you need changes to take place immediately, you will need to either refresh the firewall client on each client machine, or stop the firewall service and restart it. Also, not all applications can be blocked by simply adding a disable entry to the firewall client. The article at

Page 8 of 10

www.isaserver.org/tutorials/how_to_block_dangerous_instant_messengers_using_isa_server.html provides additional information on disabling unauthorized applications.

Figure 6 - Entry to block AOL Instant Messenger Now that weve discussed the differences between packet filters, protocol rules, and site and content rules, we should discuss the differences between the various clients ISA supports. ISA allows for three different types of clients: web proxy, firewall and secure NAT. Workstations can be configured as any combination of these three types of clients. Web proxy clients include not only web browsers, but any application that can use a proxy server to access the internet, including most instant messaging clients. Firewall clients are any workstations with the firewall client software installed, and secure NAT clients have their default gateway set to the internal IP of the ISA server. Understanding web proxy client is fairly simple. The big question is what exactly is the difference between firewall clients and secure NAT clients? As I mentioned above, firewall clients have the firewall client software installed and secure NAT clients have their default gateway set to the internal IP of the ISA server. In a typical SBS setup using two network interface cards and running ISA in firewall or integrated mode, workstations are automatically secure NAT clients, because the SBS sets the default gateway to its internal IP when it assigns addresses via DHCP. Virtually any application can access the internet whether the workstation it is running on is set up as a firewall or secure NAT client. The significant difference between firewall and secure NAT clients is controlling outbound access. Earlier in the paper, we discussed how to create protocol and site and content rules that restricted access based on user account and/or security group membership. If you need to restrict outbound access based on these criteria, workstations must be configured as firewall clients. The reason for this is because the firewall client software is necessary to pass user information to ISA. Secure NAT clients cannot provide user information, thus ISA will deny outbound access since it cannot verify that the user is allowed to access the internet using the requested port. This is why you cannot access newsgroups or other nonweb internet content if you disable the firewall client software on a workstation in a standard SBS installation. By default, ISA uses the BackOffice Internet Users protocol rule, which only allows internet access to members of the BackOffice Internet Users security group. With the firewall client disabled, your user information is not passed to ISA, thus ISA cannot determine if you are a member of the BOIU group and denies the request for access. If you do not need to restrict outbound access based on user / group membership, you can set your packet filters to apply to Any Request which will allow secure NAT clients the ability to access the internet. In addition, as mentioned earlier, you as the Administrator can configure the firewall client to restrict certain applications from accessing the internet, which is something that isnt possible for straight secure NAT clients. In short, the firewall client offers Administrators more options in controlling outbound access, but is by no means necessary to allow internet access to workstations. Now that we have discussed the various types of clients and differentiated between packet filters, protocol rules and site and content rules, you need to know the order in which rules are applied. First, if there is no packet filter or protocol rule in place for a requested port / protocol, ISA will deny the request. Second, if you have two packet filters or protocol rules for the same port / protocol, one being an allow rule and the other being a deny rule, the deny rule will always take precedence. Last, packet filters apply to the ISA server itself, protocol rules apply to ISA clients, and site and content rules apply to both the ISA server and ISA clients.

Page 9 of 10

As you can see, the power that ISA gives administrators in controlling internet access is impressive to say the least. We can go from granting access to all resources at all times, to establishing a custom access policy that restricts or grants access depending an a combination of factors, including the time and day the request is made, the user who makes it, the computer the request is made from, the program that is being used to make the request, the specific protocol being employed to carry the request, the destination domain being requested as well as the type of content that is being requested. If that doesnt give you enough control over what your users can or cannot access online, I think you just might be the poster child for micro-management. To review, ISA protects you both externally and internally. Packet filters control the type of information that is allowed to access the server itself, while Protocol Rules and Site and Content Rules control what internal clients can access from the internet. For additional information, check out www.microsoft.com/isaserver, www.isaserver.org, and www.isatools.org

Page 10 of 10