• ISAserver.org Site Updates
• New ISA Server Book Out Now!
• Feature: Controlling Outbound Access
• ISAServer.org Learning Zone Articles of Interest
• Q Articles of the Month
• Post of the Month
• ISA Server Link of the Month
• Ask Dr. Tom

1. Site Updates

By Stephen Chetcuti
With ten new articles added to ISAserver.org during November, it has been a busy month, we've also been hard at work with our new Windows Security website, WindowSecurity.com (http://www.windowsecurity.com), promising fresh and original content from experienced authors such as Robert Shimonski, Ricky Magalhaes as well as a new member of the team who we're excited to have on board, Debra Shinder.

Following the release of Thomas Shinder's first ISA Server book, which was extremely popular amongst all ISAserver.org members, comes Part II; 'ISA Server and Beyond', which was officially released last week and is available worldwide through your usual sources like Amazon.com. From his best-selling first ISA book, to the hundreds of help articles posted to ISAserver.org, to daily and continuous ISA support on the forums, comes 'ISA Server and Beyond', there's no contesting that this book is a must-have for all ISA Server administrators.

Best Regards,
Stephen Chetcuti

2. Thomas Shinder's new ISA Server book out now!

By Thomas W Shinder, M.D., MCSE, etc. It’s what we’ve all been waiting for: ISA Server and Beyond is officially released and immediately available for purchase at Amazon.com. It seems like it took forever to write it. Thousands of hours went into researching the information in this book. There were several times when Debi would have to rescue me from our ISA Server lab because it was 4AM and I hadn't slept for a couple of days. There is so much cool and undocumented stuff in this book that its hard to say what’s best. Click here to pre-order from Amazon.com today!

Click here to Order your copy today at 30% discount!

3. Controlling Outbound Access

One of the topics that generates a large number of questions is outbound access control. We usually don’t think about much about firewalls in terms of outbound access control because we spend so much time thinking about how to protect our internal network from Internet intruders. But outbound access control is vital because the vast majority of network security breaches are related to malicious and “unsophisticated” users on your own internal network.

ISA Server provides a number of outbound access control options. These outbound access control methods are collective known as “Access Policy” in ISA Server lingo. The following access policies can be configured at the ISA Server:

• Protocol Rules
• Site and Content Rules
• Bandwidth Rules
• Packet Filters

These outbound access policies are used to control what hosts on the trusted network can access on untrusted networks. The entries in the Local Address Table (LAT) determine what networks (actually, IP addresses) are trusted. Any IP address not contained in the LAT is an untrusted host. The only way untrusted hosts will be able to access internal network resources is by accessing them via publishing rules.

Let’s take a closer look at Protocol Rules. I’ll cover the other access policies in subsequent ISAServer.org newsletters.

Protocol Rules
Protocol Rules determine what protocols internal network hosts can be use to access resources on external networks. There must be a Protocol Rule in place that supports the protocol the internal network host wants to access on the external network. For example, if you want to allow internal network hosts to use the HTTP protocol to access resources on the Internet, you must create a Protocol Rule that includes the at least the HTTP protocol. If you want to allow internal network hosts to reach a POP3 server on the Internet, then there must be a Protocol Rule that includes at least the POP3 protocol.

Note that a single Protocol Rule can contain multiple protocols. For example, you can create a single Protocol Rule that includes the HTTP, SMTP, POP3 and NNTP protocols. The value in creating Protocol Rules containing multiple protocols is that you can assign permissions to that Protocol Rule to a specific user, group or collection of IP addresses.

Assigning Permissions to Protocol Rules
The permissions you assign to the Protocol Rule allow a second level of access control. You can create a Protocol Rule that includes the HTTP, SMTP, POP3 and NNTP protocols and allow Everyone to use that protocol. Such a Protocol Rule limits outbound access because if you have no other Protocol Rules, no user will be able to able to access the IRC protocol.

However, most organizations require a higher level of access control. For example, you might want to allow a specific group of users access to these protocols while preventing everyone else from having access to these protocols. In that case, you can configure the Protocol Rule to allow only the users or groups or IP addresses of your choice to use the rule. If there are no other Protocol Rules, users or IP addresses that aren’t listed in the permissions for the rule will be dropped.

Think of user groups in your organization that require Internet access When planning out your Protocol Rules,. What protocols do these users require? Then create separate Protocol Rules for each group. You may want to create new groups to support the type of access required by these users. For example, you might create an “All Open” group that can access any protocol. Another group of users might require the standard Internet protocols such as HTTP, FTP, SMTP and POP3. You can create a second group called “Limited Access” and allow the Limit Access users to use the Protocol Rule that contains these protocols.

Deny Protocol Rules Not Required
Note that you do not need to create Deny Protocol Rules to prevent Internet access. If there is no Protocol Rule that allows the user or IP address access, then the user or IP address will not be allowed to access the protocol. However, you may run into situations where a user is able to access a protocol because he belongs to another group that allows access, but you want to block that particular user. For example, you might have a user that belongs to the “All Open” group, but that user has been abusing the NNTP protocol. In this case, you will need to create a second Protocol Rule that specifically denies the user account access to the NNTP protocol. 

Deny Protocol Rules are processed before Allow Protocol Rules. If a user has permission to use a Protocol contained in a Protocol Rule that allows the user access, but the user also has permissions to use a Protocol Rule that denies access to a protocol contained in the first Protocol Rule, then access will be denied because the Deny rule is processed first.

User/Group and IP Address based Access Control
It’s important to keep in mind that only machines configured as Firewall clients will be able to always send user credentials to the Firewall service. That is why it’s critical for you to install the Firewall client software on all Windows-based operating systems. The only Windows operating systems that don’t support the Firewall client are Windows 3.1 and the initial release of Windows 95. You have far greater security concerns than controlling outbound access to the Internet if you run these operating systems, so their lack of Firewall client support isn’t a serious issue.

You can also use client access sets to assign permission to a Protocol Rule. When should you use client address sets to control access to a Protocol Rule? The only times I would use client address sets to control access to Protocol Rules is when the machines that require outbound access do not have logged on users (and therefore do not require the Firewall client) and those machines not running Windows operating systems.

For example, servers do not have logged on users. Domain controllers, SMTP servers, Web servers, FTP servers and other network servers should not have logged on users. You don’t want users logged onto these servers because the logged on user’s credentials can be used to control the machine in the event the machine is compromised. Machines like FTP and SMTP servers need outbound access to the Internet, so you would allow them access via Protocol Rules using client address sets that include the IP addresses of these servers.

How Web Proxy Clients “break” the Rules
Web Proxy clients present a special situation. Web Proxy clients can send credentials to the Web Proxy service either automatically (if integrated authentication is used), or via a log on dialog box if basic authentication is used. The Web Proxy client machine does not need the Firewall client to access Protocol Rules with user/group based access controls on them. However, the protocols the user can access with the Web Proxy client configuration are limited to HTTP, HTTPS, FTP (download only) and Gopher.

The difference between the Web Proxy client and the Firewall client is that the Firewall client always sends credentials, while the Web Proxy client only sends credentials if asked. This has an important effect in terms of how requests from Web Proxy clients are processed!

For example, suppose you have two Protocol Rules:

Protocol Rule 1:
Allow Rule
HTTP Protocol
Everyone 

Protocol Rule 2:
Deny Rule
HTTP Protocol
“Dangerous Users” group 

What do you think will happen when the member of the “Dangerous Users” group tries to access the Internet? If the machine is configured as a Firewall client, the request will be denied because the user’s credentials are sent with the request. But if the client is configured as a Web Proxy client, the request is sent without credentials. Since there is an Allow rule that allows everyone outbound access, the user will be allowed access to the HTTP protocol! Again, the reason for this is that the Web Proxy client does not send credentials until it is asked. Since the Protocol Rule that allows “Everyone” access matches the anonymous request, the user is allowed outbound access to the HTTP protocol.

Conclusion
Protocol Rules are your first defense when it comes to outbound access control. If there isn’t a Protocol Rule that allows outbound access, the client won’t have access to the protocol. Protocol Rules can be applied to users, groups and IP addresses. Protocol Rules can contain multiple protocols, and you can create multiple Protocol Rules that contain the same protocol, but have some allow access and other Deny access. Keep in mind that only Firewall clients always send credentials and that Web Proxy clients only send credentials when they are asked for them. Web Proxy clients will not be asked for credentials if an anonymous access rule is available.

Protocol Rules work together with Site and Content Rules, Bandwidth Rules, and sometimes packet filters. It’s important to have a good understanding of each of these access policies and how they interact with one another. I’ll cover the other access policies in subsequent newsletters.

4. ISAServer.org Learning Zone articles of Interest

• Configuring XBox Live
• The Mystery of the HTTP Redirector and Site & Content Rules
• Publishing Multiple Web Sites using Web Publishing Rules
• Configuring Web Proxy Clients for Direct Access
• Allowing External Connections to the Incoming Web Requests Listener
• Understanding SSL Bridging and Tunneling in ISA Server
• Configuring Web Sites using Client Certificate Authentication

5. Q Articles of the Month

• How to Manually Remove and Reinstall Microsoft Firewall Client on Windows 98 and Windows 98 Second Edition
• You Receive an Error Message from Your Firewall Client After You Upgrade to Windows XP Professional
• Outlook Web Access Prompts You for Logon Credentials Multiple Times Before Inbox Appears
• FIX- ISA Server Blocks Incoming Traffic Although a Valid Server Publishing Rule Exists
• FIX- Server Publish May Fail on Dial-up Links
• Cannot Uninstall ISA Server if IIS Has Already Been Removed
• Disable the IP Spoofing Detection Feature in Internet Security and Acceleration Server 2000

6. Post of the Month!

"Microsoft has managed to reproduce our problem in their lab AND they have managed to find the cause -- no cure yet though :-(  IF you have UDP based publishing (any UDP not just DNS) AND a Site and Content filter containing FQDN the following happens:

Incoming UDP requests are checked against the Site and Content rules by attempting to do a reverse lookup on the incoming IP (to find a FQDN to match against the IP). If this for some reason it fails (like the requesting IP not being in a reverse zone) then the ISA tries to make a NBTSTAT query against the remote IP to find the FQDN. Once it has succeeded, failed or timed-out on the incoming request, it will then process the request.

This can take some time (at least on my side we just drop incoming NetBIOS, so those will have to timeout) and during that time the ISA is gobbling up UDP connections. With heavy traffic this will at times cause the pool of available UDP mappings to be full so that incoming requests first have to wait for another request to make it through the S&C rules before itself can start a path through!

So if:

• You have a remote client that is not in a reverse zone and that can not be resolved by nbtstat AND if it is re-requesting the DNS information after say 5 seconds
• Then you can easily end up in a situation where
• The requests are being held pending, in wait for a process slot, while the ISA is trying to resolve the FQDN of a previous request FROM THE SAME MACHINE!

So the good news is that they know why and the bad news is that it sounds like it is a fundamental change that needs to be done! Possible workaround, no S&S rules! Not sure I want to go that way. Was this clear? If not, drop me a line and I'll try again. /Jörgen"

Thanks Jorgen! That was perfectly clear. --Tom.

7. ISA Server Link of the Month

8. Ask Dr. Tom