Using Scripts to Populate Domain Name Sets - Dr. Tom Shinderamp;#039;s Configuring ISA Server 1002004 [Electronic resources] نسخه متنی

Using Scripts to Populate Domain Name Sets

One of the ISA firewall's strong suits is its exceptional stateful application layer inspection. In addition to performing the basic task of stateful filtering (which even a simple ‘hardware' firewall can do), the ISA firewall's strong application layer inspection feature set allows the ISA firewall to actually understand the protocols passing though the firewall. In contrast to traditional second generation hardware firewalls, the ISA firewall represents a third-generation firewall that is not only network aware, but application protocol aware.

The ISA firewall's stateful application inspection mechanism allows you to control access not just to 'ports', but to the actual protocols moving through those ports. While the conventional 'hardware' firewall is adept at passing packets using simple stateful filtering mechanisms that have been available since the mid 1990's, the ISA firewall's stateful application layer inspection mechanisms bring the ISA firewall into the 21^st century and actually control application layer protocol access. This allows strong inbound and outbound access control based on the firewall's application layer awareness, rather than through simple 'opening and closing' of ports.

One powerful example is the ability to control what sites users can access through the ISA firewall. You can combine this ability to control the sites users can access by adding strong user/group based access control as well as protocol control.

For example, you might have a group of users called 'Web Users,' and you might want to block access to a list of 1500 URLs or domains for those users. You can create an Access Rule that blocks only those 1500 sites and allows access to all other sites when members of that group authenticate with the ISA firewall.

Another example might be this: you want to create a block list of 5000 domains that you want to prevent all users except for domain admins from reaching via any protocol. You can create a Domain Name Set and then apply this Domain Name Set to an Access Rule blocking these sites.

The trick is to find a way to get those thousands of domains or URLs into Domain Name Sets and URL Sets. You can, of course, enter these URLs and domains manually using the built-in tools included in the ISA Management console. The problem with this approach is that you'll need to get your clicking thumb ready for a long weekend as you click your way through the user interface to add all of these domains and URLs.

A better way is to import the sites you want to include in your URL Sets and Domain Name Sets from a text file. There are a number of places on the Internet where you can find such files (I won't mention any here because I don't want to create an implicit endorsement of any of them). Once you have a text file, you'll want use a script to import the entries in the text file into a URL Set or a Domain Name Set.

First, let's start with the scripts. The first script below is used to import the entries in a text file into a URL Set. Copy the information into a text file and then save it as ImportURLs.vbs.

< ------------------Start with the line below this one------->
Set Isa = CreateObject("FPC.Root")
Set CurArray = Isa.GetContainingArray
Set RuleElements = CurArray.RuleElements
Set URLSets = RuleElements.URLSets
Set URLSet = URLSets.Item("Urls")
Set FileSys = CreateObject("Scripting.FileSystemObject")
Set UrlsFile = FileSys.OpenTextFile("urls.txt", 1)
For i = 1 to URLSet.Count
URLSet.Remove 1
Next
Do While UrlsFile.AtEndOfStream <> True
URLSet.Add UrlsFile.ReadLine
Loop
WScript.Echo "Saving..."
CurArray.Save
WScript.Echo "Done"
< ------------------End with the line above this one--------->

The two entries in this file you need to change for your own setup are highlighted in yellow.

In the line:

Set URLSet = URLSets.Item("Urls")

Change the Urls entry to the name of the URL Set you want to create on the ISA firewall.

In the line:

Set UrlsFile = FileSys.OpenTextFile("urls.txt", 1)

Change the urls.txt entry to the name of the text file that contains the URLs you want to import into the ISA firewall's configuration.

The next script is used to import a collections of domains contained in a text file. Save the following information in a text file and name it ImportDomains.vbs.

< ------------------Start with the line below this one-------
Set Isa = CreateObject("FPC.Root")
Set CurArray = Isa.GetContainingArray
Set RuleElements = CurArray.RuleElements
Set DomainNameSets = RuleElements.DomainNameSets
Set DomainNameSet = DomainNameSets.Item("Domains")
Set FileSys = CreateObject("Scripting.FileSystemObject")
Set DomainsFile = FileSys.OpenTextFile("domains.txt", 1)
For i = 1 to DomainNameSet.Count
DomainNameSet.Remove 1
Next
Do While DomainsFile.AtEndOfStream <> True
DomainNameSet.Add DomainsFile.ReadLine
Loop
WScript.Echo "Saving..."
CurArray.Save
WScript.Echo "Done"
< ------------------End with the line above this one--------->

The two entries in this file you need to change for your own setup are shown below.

In the line:

Set DomainNameSet = DomainNameSets.Item("Domains")

Change the Domains entry to the name of the Domain Name Set you want to create on the ISA firewall.

In the line:

Set DomainsFile = FileSys.OpenTextFile("domains.txt", 1)

Change the domains.txt entry to the name of the text file that contains the domains you want to import into the ISA firewall's configuration.

Using the Import Scripts

Now let's see how the scripts work. The first thing you need to do is create the URL Set and the Domain Name Set in the Microsoft Internet Security and Acceleration Server 2004 management console. This is easy and involves only a few steps.

First, we'll create a URL Set named URLs, since that's the default name in our script. Remember, you can change the URL Set name in the script if you like; just make sure you first create a URL Set in the Microsoft Internet Security and Acceleration Server 2004 management console with the same name.

Perform the following steps to create a URL Set with the name URLs:

In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then click on the Firewall Policy node.

In the Firewall Policy node, click the Toolbox tab in the Task Pane. In the Toolbox, click the Network Objects tab.

In the Network Objects tab, click the New menu and click URL Set.

In the New URL Set Rule Element dialog box, shown in Figure 7.16, enter URLs in the Name text box. Click OK

Figure 7.16: The New URL Set Rule Element dialog box

The URL Set now appears in the list of URL Sets, shown in Figure 7.17.

Figure 7.17: The URL Sets list

The next step is to create a Domain Name Set with the name Domains, which is the default name of the Set used in the ImportDomains script. Remember, you can use a different name for the Domain Name Set; just make sure the name is the same as the one you set in the script.

Perform the following steps to create the Domain Name Set with the name Domains:

In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then click on the Firewall Policy node.

In the Firewall Policy node, click the Toolbox tab in the Task Pane. In the Toolbox, click the Network Objects tab.

In the Network Objects tab, click the New menu and click Domain Name Set.

In the New Domain Name Set Policy Element dialog box, shown in Figure 7.18, enter Domains in the Name text box. Click OK.

Figure 7.18: The New Domain Set Policy Element dialog box

Figure 7.19: the Domain Name Sets list

The new entry appears in the list of Domain Name Sets, shown in Figure 7.19.

Click Apply to save the changes and update the firewall policy.

Click OK in the Apply New Configuration dialog box.

Now we need to create two text files: urls.txt and domains.txt. Those are the default names used in the scripts. You can change the names of the files, but make sure they match the names you configure in the scripts.

The domains.txt file will contain the following entries:

stuff.com

blah.com

scumware.com

The urls.txt file will contain the following entries:

http://www.cisco.com
http://www.checkpoint.com
http://www.sonicwall.com

Next, copy the script files and the text files into the same directory. In this example, we'll copy the script files and text files into the root of the C: drive. Double click on the ImportURLs.vbs file. You'll first see a dialog box that says Saving, as shown in Figure 7.20. Click OK.

Figure 7.20: Saving the information

Depending on how many URLs you're importing, it will be a few moments or a few minutes until you see the next dialog box, shown in Figure 7.21, which informs you that the import was completed. Click OK.

Figure 7.21: Finishing the procedure

Now we'll import the Domains. Double click the ImportDomains.vbs file. You'll see the Saving dialog box again. Click OK. A few moments to a few minutes later, you'll see the Done dialog box. Click OK.

Close the Microsoft Internet Security and Acceleration Server 2004 management console if it is open. Now open the Microsoft Internet Security and Acceleration Server 2004 management console and go to the Firewall Policy node in the left pane of the console.

Click the Toolbox tab in the Task Pane and click the Network Objects bar. Click the URL Sets folder. Double click the URLs URL Set. You'll see that the URL Set was populated with the entries in your text file as shown in Figure 7.22. Cool!

Figure 7.22: URL Set entries

Click on the Domain Name Sets folder. Double click on the Domains entry. You'll see that the Domain Name Set is populated with domains you want to block, or allow, depending on your need. In this example we included a set of domains we'd like to block, shown in Figure 7.23.

Figure 7.23: Domain Name Set Properties

As you obtain more URLs, you can add them to the same text files and run the script again. The new entries will be added without creating duplicates of the domains or URLs that are already included in the Domain Name Set or URL Set.

Extending the SSL Tunnel Port Range for Web Access to Alternate SSL Ports

There will be times when your Web Proxy clients need to connect to SSL Web sites using an alternate port for the SSL link. For example, your users might try to access a banking Web site that requires an SSL connection on TCP port 4433 instead of the default port 443. This can also be problematic for SecureNAT and Firewall clients, since the default setting on the ISA firewall is to forward SecureNAT and Firewall client HTTP connections to the Web Proxy filter. Clients will see either a blank page or an error page indicating that the page cannot be displayed.

The problem here is that the Web Proxy filter only forwards SSL connections to TCP port 443. If clients try to connect to an SSL site over a port other than TCP 443, the connection attempt will fail. You can solve this problem by extending the SSL tunnel port range. However, to do so, you will need to download Jim Harrison's script at http://www.isatools.org, and enter the tunnel port range(s) you want the ISA firewall's Web Proxy component to use.

Perform the following steps to extend the ISA firewall's SSL tunnel port range:

Go to www.isatools.org and download the isa_tpr.js file and copy that file to your ISA firewall. Do not use the browser on the firewall. Download the file to a management workstation, scan the file, and then copy the file to removable media and then take it to the ISA firewall. Remember, you should never use client applications, such as browsers, e-mail clients, etc. on the firewall itself.

Double click the isa_tpr.js file. The first dialog box you see states This is your current Tunnel Port Range list. Click OK.

The NNTP port is displayed. Click OK.

The SSL port is displayed. Click OK.

Now copy the isa_tpr.js file to the root of the C: drive. Open a command prompt and enter the following:

isa_tpr.js /?

You will see the following dialog box, shown in Figure 7.24.

Figure 7.24: Help information for the isa_tpr.js script

To add a new tunnel port, such as 8848, enter the following command and press ENTER:

Cscript isa_tpr.js /add Ext8848 8848

You will see something like what appears in figure 7.25 after the command runs successfully.

Figure 7.25: Running the isa_tpr.js script to add a port to the SSL tunnel port range

Alternatively, you can download the .NET application, ISATpre.zip file (written by Steven Soekrasno) from the www.isatools.org site and install the application on the ISA firewall. This application provides an easy to use graphical interface that allows you to extend the SSL tunnel port range. Figure 7.26 shows what the GUI for this application looks like.

Figure 7.26: Using Steven Soekrasno's .NET Tunnel Port Range extension application

Avoiding Looping Back through the ISA Firewall for Internal Resources

A common error made by ISA firewall administrators involves allowing hosts on an ISA firewall Protected Network to loop back through the firewall to access resources on the same network where the client is located.

For example, suppose you have a simple ISA firewall configuration with a single external interface and a single internal interface. On the Internal network located behind the internal interface, you have a SecureNAT client and a Web server. You have published the Web server to the Internet using a Web Publishing Rule. The Web server is accessible to internal clients using the URL http://web1 and to external clients using the URL http://www.msfirewall.org.

What happens when users on the Internal Network attempt to connect to the Web server using the URL www.msfirewall.org? If you don't have a split DNS in place, the clients on the Internal Network will resolve the name www.msfirewall.org to the IP address on the external interface of the ISA firewall that is listening for incoming connections to www.msfirewall.org. The host then will try to connect to the Internal resource by looping back through the ISA firewall via the Web Publishing Rule. If the client is a SecureNAT client, the connection attempt may fail (depending on how the ISA firewall is configured) or the overall performance of the ISA firewall is severely degraded because the firewall is handling connections for local resources.

You should always avoid looping back through the ISA firewall for resources located on the same network as the requesting host. The solution to this problem is to configure SecureNAT, Firewall and Web Proxy clients to use Direct Access for local resources (local resources are those contained on the same ISA firewall Network as the host requesting those resources). A Direct Access solution depends on the following components:

Create a split DNS so that the clients can use the same domain name to reach the same resources both internally and externally. This requires two zones on two DNS servers. One zone is used by external clients and one zone is used by internal clients. The external client zone resolves names to the externally accessible address and the internal zone resolves names to internally accessible addresses. The key is that the zones are authoritative for the same domain name.

Configure the properties of the network on which the Protected Network Web Proxy client is located to use Direct Access to reach both the IP addresses on the Internal network and the internal network domain names. This is done on the Web Proxy tab.

Configure the properties of the network on which the Protected Network Firewall client is located to use Direct Access for internal domains

Details of this configuration are included in chapter 5 on ISA client installation and provisioning and in Chapter 4 on the ISA firewall's networking design.

Anonymous Requests Appear in Log File Even When Authentication is Enforced For Web (HTTP Connections)

A common question we encounter from ISA firewall admins relates to the appearance of anonymous connections from Web Proxy clients in the ISA firewall's Web proxy logs. These connections appear in spite of the fact that all rules are configured to require authentication. The short answer to this question is that this is normal and expected.

The long answer to this question involves how Web proxy clients normally communicate with authenticating Web proxy servers. For performance reasons, the initial request from the Web Proxy client is send without user credentials. If there is a rule that allows the connection anonymously, then the connection is allowed. If the client must authenticate first, then the Web proxy server sends back to the Web proxy client an access denied message (error 407) with a request for credentials. The Web proxy client then sends credentials to the ISA firewall and the user name appears in the log files.

Figure 7.27 shows the HTTP 407 response returned to the Web proxy client. On the right side of the figure, you'll see the ASCII decode of a frame taken from a Network Monitor trace. On the fifth line from the top, you'll see HTTP/1.1 407 Proxy Authentication Required… This is the 407 response the Web Proxy clients receive when an Access Rule requires authentication in order to connect to a Web site through the ISA firewall.

Figure 7.27: A 407 response is returned to the Web proxy client

Blocking MSN Messenger using an Access Rule

Blocking dangerous applications is a common task for the ISA firewall. There are a number of methods you can use to block dangerous applications:

Use the HTTP Security Filter to block the application if the application uses a Web (HTTP) connection to reach the site

Use Domain Name Sets or URL Sets to block the sites the dangerous application needs to access to establish a connection

Block the protocol, or do not allow access to the protocol, required by the dangerous application if the application uses a custom protocol

If the application can use both a custom protocol and Web connection to access the Internet, then block the custom protocol and then use Domain Name Sets or URL Sets to block its ability to access the Internet using a Web connection

Simplify your life by using the Principle of Least Privilege. When you use Least Privilege, you create rules to allow access. Anything not explicitly allowed is blocked. In this way, you'll almost never need to create a Deny rule of any kind

To demonstrate one method you can use to block dangerous applications, we'll create an Access Policy that blocks the MSN Messenger 6.2 application. The elements of the solution include the following:

Create a Deny Rule that blocks the MSN Messenger Protocol

Create an Access Rule that blocks the MSN Messenger HTTP header.

In this example, we will create an 'all open' rule that allows all protocols outbound, but include a signature in the HTTP Security Filter that blocks the MSN Messenger. The second rule blocks the MSN Messenger protocol. Tables 7.2 and 7.3 show the properties of each Access Rule.

You can use the information given earlier in this chapter on how to create the Access Rules. The Deny Messenger Protocol Access Rule must be placed above the All Open rule. Deny rules should always be placed above allow rules. Your firewall policy should look something like that in figure 7.28.

Figure 7.28: Firewall Policy to block MSN Messenger

After creating the Access Rules, right click on the All Open -1 Access Rule and click the Configure HTTP command. In the Configure HTTP policy for rule dialog box, click the Add button. In the Signature dialog box, shown in Figure 7.29, enter the following information:

Name: Enter a name for the MSN Messenger blocking signature

Description (optional): Enter a description for the rule

Search in: Select the Request headers option from the drop down list

HTTP Header: Enter User-Agent: in the text box

Signature: enter MSN Messenger in the text box

Figure 7.29: The Signature dialog box

Click OK to save the signature and click OK in the Properties dialog box. Click Apply to save the changes and update the firewall policy and Click OK in the Apply New Configuration dialog box.

Figure 7.30 shows log file entries for the blocked connection from MSN Messenger. This first entry shows the connection using the MSN Messenger protocol being blocked and the third entry shows that the MSN Messenger connection was blocked by the HTTP Security Filter signature in the All Open rule.

Figure 7.30: Log file entries showing the HTTP Security Filter blocking the MSN Messenger connection

Allowing Outbound Access to MSN Messenger via Web Proxy

The MSN Messenger can access the Internet using its own protocol, or it can tunnel its communications in an HTTP header. However, you will run into problems if you want Web Proxy clients to access the MSN Messenger site because of an authentication issue that hounds both the MSN Messenger and Hotmail applications.

When the MSN Messenger sends credentials to the MSN Messenger site, those credentials are also sent to the ISA firewall. If the user name and password the user uses to access the MSN Messenger site aren't the same as the credentials the user uses on the corporate network, then the connection will fail. If you allow anonymous access to the MSN Messenger site, then you won't have problems because no credentials are sent to the ISA firewall because the firewall won't challenge the user for credentials.

You can get around this issue by enabling an anonymous access rule for Web Proxy clients so that they can use the HTTP and HTTPS protocols to reach the sites required by the MSN messenger. This limits your exposure because you're not allowing anonymous access to all sites, just MSN Messenger. However, you do lose out on user/group based access control. You can easily solve this problem by using the Firewall client on your hosts and enforcing authentication via the Firewall client and configuring the MSN sites for Direct Access.

You will need to allow anonymous access to the HTTP protocol to the following sites:

Config.messenger.msn.com
Gateway.messenger.hotmail.com
Loginnet.passport.net
Loginnet.passport.com
207.46.110.0/24 (this is a Subnet Network Object)

We obtained this information by viewing the log file entries in the ISA firewall console's real time log viewer. The subnet and domains may change over time, so if you find that the rule no longer works, you'll need to check your log files and see what sites are required by the Messenger.

Table 7.4 shows the settings in the Access Rule allowing Web Proxy clients access to the MSN Messenger site.

Changes to ISA Firewall Policy Only Affects New Connections

After a client initiates a request, the ISA firewall maintains an active state in the firewall state table for the session which permits the response to return to the client. The active state permits the client to send new requests. The ISA firewall removes the active state from the state table after the session is idle for an unspecified period of time (usually a minute or two).

For example, try the following:

Open a command prompt on a host on a Protected Network and ping a host through the ISA firewall using the 'ping -n IP address' command. The -n allows the ping to continue unabated during your test. When you're finished with your test, you can use the CTRL+C command to stop the ping. Make sure there is a rule that allows the host to ping the host through the ISA firewall.

On the ISA firewall, apply a Deny rule for the Ping protocol and place it above any rule that currently allows the ping through the ISA firewall.

The ping continues unabated even after the rule is applied. This is because there is an active state table entry for the ping from that client and the destination address being pinged.

Open a second command prompt on the client that is pinging the remote host. Start a ping to a second host through the ISA firewall. The ping requests are denied because there is no state table entry for the ping protocol from that host to that destination host.

If you try to ping from a different client, the ping is denied.

Access Rules are applied immediately for new connections when you click Apply to save the changes and update firewall policy. To make changes apply to all existing connections, you can do either of the following:

Disconnect existing sessions in the Sessions tab of the Monitoring node. To disconnect a session, open the Microsoft Internet Security and Acceleration Server 2004 management console, click the Monitoring node, click the Sessions tab in the middle pane, click the session that you want to disconnect, and then click Disconnect Session on the Tasks tab.

Another option is to restart the Microsoft Firewall service. In the Microsoft Internet Security and Acceleration Server 2004 management console, click the Monitoring node, click the Services tab, click Microsoft Firewall, click Stop Selected Service on the Tasks tab, and then click Start Selected Service on the Tasks tab.