Over the last few months I’ve had a few Windows XP SP2 and Media Center Edition machines that refused to access the Windows Update site. There weren’t mission critical machines so I didn’t worry about it too much, but I found the situation irritating, since a couple of these machines were laptops that updated just fine when I connected to hotel network that didn’t have an ISA Firewall in front them.

What was frustrating is that I had done everything right on the ISA Firewall. I created the correct Direct Access lists for the Web proxy clients, I didn’t mix IP address and FQDNs in my Direct Access lists, and I even configured the clients with local Web proxy bypass lists (which I expect did nothing anyhow, since I was using the autoconfiguration script).

I finally got fed up with the situation and started to think about doing something. The only thing I could think of was that perhaps the Windows/Microsoft Update mechanism used WinHTTP and it wasn’t getting the proxy server setting from the browser.

So I opened a command prompt and entered:

proxycfg -?

And I saw this:

C:\Documents and Settings\tshinder.TACTEAM>proxycfg ?
Microsoft (R) WinHTTP Default Proxy Configuration Tool Copyright (c) Microsoft Corporation. All rights reserved.

usage:

proxycfg -? : to view help information

proxycfg : to view current WinHTTP proxy settings

proxycfg [-d] [-p <server-name> [<bypass-list>]]

-d : set direct access
-p : set proxy server(s), and optional bypass list

proxycfg -u : import proxy settings from current user’s Microsoft Internet Explorer manual settings (in HKCU)

===================

I then ran:

proxycfg

and saw something like this:

C:\Documents and Settings\tshinder.TACTEAM>proxycfg
Microsoft (R) WinHTTP Default Proxy Configuration Tool Copyright (c) Microsoft Corporation. All rights reserved.

Current WinHTTP proxy settings under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\
WinHttpSettings :

Proxy Server(s) : <none>
Bypass List : <local>

=======================

This suggested that the WinHTTP proxy settings weren’t using the ISA Firewall, so I ran:

proxycfg -u

and I saw this:

Current WinHTTP proxy settings under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\
WinHttpSettings :

Proxy Server(s) : CELESTIX-H5L4CS.tacteam.net:8080
Bypass List : <local>

===================

After doing that automatic updates started downloading immediately! Good news.

I’d like to tell you that I know exactly why this worked, and what the relationship between the WinHTTP proxy settings are and Windows/Microsoft Update, and why it didn’t work before, but I can’t tell you that. Documentation in this area is about as weak as the documentation on the relationship between brain and mind

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

A best kept secret in the ISA Firewall world is the ability to publish servers using Server Publishing Rules even when there is a route relationship between the source and destination networks. Most people think of Server Publishing Rules as a form of reverse NAT that supports application layer inspection. While that is one scenario, there is no requirement for NAT when publishing servers.

For example, suppose you have  branch office that connects to the main office via a site to site VPN connection. It’s likely that you have a route relationship between the main office and branch office and you probably use Access Rules to allow connections from branch office clients to main office servers. That works well so you’ve probably not seen a reason to change your approach.

In what circumstances might you want to change your approach and use Server Publishing Rules instead of Access Rules? The primary reasons I can think of using a Server Publishing Rule instead of an Access Rule is when the Application Filter for the protocol that you’re allowing access to doesn’t work for outbound connections (Access Rules always use outbound connections) and when you don’t want to change your DNS infrastructure to support NAT for Server Publishing Rules (although you can use Access Rules to allow access, you don’t have the option of controlling the source IP address delivered to the published server when using Access Rules).

For example, the SMTP and POP3 application filters only work for SMTP Server and POP3 Server protocols. If you want to make sure branch office users are subjected to protocol inspection for those protocols, then you’ll need to use a Server Publishing Rule to publish the main office SMTP and POP3 servers to the branch offices.

The nice thing about using Server Publishing Rules when there is a route relationship between the source and destination is that clients connect to the actual IP address of the published server, not the address on the ISA Firewall listening for the request. What happens in this scenario is that the ISA Firewall uses something called port stealing intercept the request so that application layer inspection can be performed on the request and then be passed to the published server if the connection passes application layer inspection.

Another thing you can do with Server Publishing Rules that you can do with Access Rules is control the source IP address of the incoming request to the published server. This is extremely useful if you can’t make the published server a SecureNAT client of the ISA Firewall.

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

We get a fair number of people asking about problems with connecting to SSL sites. In most cases, these problems are related to:

• The SSL site was configured to listen on a non-standard port
• Connections limits are exceeded, because each element is a separate session when using SSL
• Access rules are configured to allow paths to a specific SSL site, but not to the root. The ISA Firewall can’t see the paths in an outbound SSL tunnel, so if you don’t allow access to the entire site, then all connections to the SSL site are denied

However, there might be another problem if you haven’t updated your ISA Firewall. These days, there’s no reason to not keep your ISA Firewall updated, as ISA Firewall updates are part of the Microsoft Update option. This is a great security advantage over “hardware” firewalls or Blue Coat proxies, where you have to remember to update the Firewall or proxy and hope you don’t get nailed by the time the update for the non-ISA Firewall device is updated.

If you haven’t updated your ISA Firewall, you might have problems with SSL sites if:

• The ISA Firewall software isn’t completely up to date
• The client is configured as a Web proxy client
• The ISA Firewall’s Web listener is configured to use integrated authentication
• The Web proxy client hasn’t been configured to use HTTP 1.1 (you should always configure your Web proxy clients to use HTTP 1.1)

Updating the ISA Firewall will stop the problem. For more information check out the KB article at http://support.microsoft.com/kb/923766/en-us

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Have you ever tried to open an email message via an OWA site that has been published by an ISA Firewall and received an error message indicating that the HTTP Security Filter blocked the connection? If so, you problem saw something like this:

The page cannot be displayed

Explanation: There is a problem with the page you are trying to reach and it cannot be displayed.
Try the following:

• Refresh page: Search for the page again by clicking the Refresh button. The timeout may have occurred due to Internet congestion.
• Check spelling: Check that you typed the Web page address correctly. The address may have been mistyped.
• Access from a link: If there is a link to the page you are looking for, try accessing the page from that link.

Technical Information (for support personnel)

• Error Code: 500 Internal Server Error. The request was rejected by the HTTP Security filter. Contact your ISA Server administrator. (12217)

One reason why this might happen is that the message contained high-bit characters, as seen in non-English languages such as Spanish or German. You can fix this problem by configuring the HTTP Security Filter for the Web Publishing Rule to not block high-bit characters, as seen in the figure below.

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

A number of people have had problems with connecting to FTP sites using Active Mode when behind the ISA Firewall. The problem is mostly seen when the Firewall client is installed, the Enable folder view for FTP sites is enabled in Internet Explorer and the Use Passive FTP checkbox is not selected in Internet Explorer.

The problem doesn’t happen if you use the built in FTP client (ftp.exe) that comes with Windows or when the Firewall client isn’t installed and the machine is configured as a SecureNAT client.

Microsoft has a hotfix with a file version dated 9/20/2004, so I suspect that if you installed ISA 2004 SP2, you’ll have the fix, since my file version is dated 1/18/2006.

For more details, check out the KB article at http://support.microsoft.com/kb/884580/en-us

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Several people have asked me in the last few weeks about problems with the OWA form coming up too slowly. In many cases this might be related to not publishing the CRL for the site and the Web browser is configured for CRL checking. However, something I’ve taken for granted is that ISA 2004 Firewall users have updated their ISA Firewall to Service Pack 2.

If you haven’t upgraded your ISA Firewall to Service Pack 2, then you should do that now. I’ve heard some “tribal knowledge”, especially in the SBS space, that you shouldn’t install ISA SP2 because of some non-specific problems. While the ISA Firewall does introduce a new CARP algorithm that can play havoc with your Direct Access configuration, this is easy to fix. Check out Stefaan Pouseele’s article on this subject at http://blogs.isaserver.org/pouseele/2006/07/

Another reason to upgrade to SP2 is that it will fix your OWA performance issues. There was a memory leak in pre-SP2 where there was a leak of 8 handles for each successful FBA log on. That leak goes away with SP2.

For more information on this problem, check out the KB article related to this issue at: http://support.microsoft.com/kb/897717/en-us

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Microsoft ISA 2006 is being offered in two versions: ISA 2006 Standard and ISA 2006 Enterprise. While ISA 2006 Enterprise Version is intended for use in large corporate environments with several firewalls and integrated load balancing, the standard version is meant to replace existing firewall solutions in smaller systems or to be a solution just behind an existing firewall implementation. The changes and additions in ISA 2006 are nowhere near as extensive as those undertaken between ISA 2000 and ISA 2004.

For more information: http://www.heise-security.co.uk/articles/76593

I never ceased to be amazed when I go to conferences and talk about the ISA Firewall. There are still a number of MS network admins out there who think that the ISA Firewall is some sort of revved version of Proxy Server 2.0. It surprises them when I talk about the ISA Firewall, as I always make it clear that the ISA Firewall is a network firewall first, middle and last. Any proxy components included with the ISA Firewall are an extension of the ISA Firewall’s core feature feature set and firewall technologies.

I recently had an interesting conversation with someone who is very well versed with the PIX and Check Point firewalls, and he pointed out to me that the new flood mitigation settings included with the 2006 ISA Firewall make the ISA Firewall more secure and more resilient to attack than the traditional hardware firewalls out on the market. I thought this was an amazing admission by someone who I considered a dyed-in-the-wool “hardware” firewall guy.

If you haven’t had a chance to check out the new flood mitigation settings on the 2006 ISA Firewall, you can find the configuration interface in the General node located under the Configuration node in the left pane of the ISA Firewall console. In the middle pane of the General node, click the Configure Flood Mitigation Settings link. You’ll see the Flood Mitigation dialog box as it appears in the figure below.

What do all these options mean? Check this out:

Maximum concurrent TCP connections per IP address: Edit

ISA Server mitigates a TCP flood attack that occurs when an offending host maintains numerous TCP connections with ISA Server or other servers.

Click to edit the maximum number of TCP connections allowed concurrently per IP address. The default limit is 160. The custom limit for IP address exceptions is 400.

Maximum half-open TCP connections: View

ISA Server mitigates SYN attacks. In a SYN attack, an offending host sends TCP SYN messages without completing the TCP handshake.

Click to view the maximum number of TCP connect requests allowed per minute, per IP address. ISA Server limits the number of concurrent half-open TCP connections to half the number of concurrent connections configured for concurrent TCP connections. You cannot change this default.

Maximum HTTP requests per minute per IP address: Edit

ISA Server mitigates denial of service (DoS) attacks. In a DoS attack, an offending host sends numerous HTTP requests to victim Web sites.

Click to edit the maximum number of HTTP requests allowed per minute per IP address. The default limit is 600. The custom limit for IP exceptions is 6,000.

Maximum new non-TCP sessions per minute per rule: Edit

ISA Server mitigates non-TCP DoS attacks. In a non-TCP DoS attack, malicious hosts send numerous non-TCP packets to a victim server. The specific non-TCP traffic is denied by an ISA Server rule.

Click to edit the maximum number of non-TCP sessions allowed per minute per rule. The default limit is 1,000. You cannot specify IP exceptions for this mitigation.

Maximum concurrent UDP sessions per IP address: Edit

ISA Server mitigates UDP flood attacks. In a UDP flood attack, an offending host sends numerous UDP messages to victim hosts.

When a UDP flood attack occurs, ISA Server discards older sessions, so that no more than the specified number of connections are allowed concurrently.

Click to edit the maximum number of UDP sessions allowed per IP address. The default limit is 160. The custom limit for IP exceptions is 400.

Specify how many denied packets trigger an alert: Edit

ISA Server raises an alert if the number of denied packets from a specific IP address exceeds a preconfigured threshold. The specified limit applies to all IP addresses.

Click to edit the number of denied packets, which when exceeded, triggers an alert.

Log traffic blocked by flood mitigation settings

Select to log all traffic that is blocked by flood mitigation settings. When you select this option, a log record will be generated for each request rejected by the flood mitigation mechanism.

In general, we recommend that you select this option. In case of flood attack, however, after you identify the list of offending IP addresses, disable this option to prevent high resource consumption

For the most part, you’ll never need to make any changes to these settings. If you want to know more about how these settings work with the 2006 ISA Firewall, check out the Microsoft paper on Flood Mitigation with ISA Firewalls at http://www.microsoft.com/technet/isa/2006/flood_re...y.mspx

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Did you know that the ISA Firewall is automatically configured to check for revoked certificates?

You can control this behavior by going to the General node located under the Configuration node in the left pane of the ISA Firewall console. In the middle pane of the General node, you’ll see a link saying Specify Certificate Revocation Settings. Click that and you’ll see the dialog box that appears in the figure below.

There are two sections: Client Certificates (User Certificates) and Server Certificates.

By default, the Verify that incoming client certificates are not revoked option is enabled. When this is enabled, the ISA Firewall will check to make sure that User Certificates presented to the ISA Firewall for User Certificate authentication are not revoked.

Another default setting has the Verify that incoming server certificates are not revoked in a forward scenario. This option enables the ISA Firewall to check whether or not the server certificate from a Web server that the ISA Firewall is connecting to (or an upstream Web proxy, if the ISA Firewall is a downstream member of a Web proxy chain) has been revoked. If revoked, the connection request will be denied.

The other Server Certificate option, which is not enabled by default, applies to Web Publishing Scenarios where you’re using SSL to SSL bridging. When this option is enabled, the ISA Firewall will check to see if the Web site certificate presented to the ISA Firewall by the published Web server has been revoked. If so, then connections to the published Web server are denied. This option is disabled by default for performance reasons, because it’s assumed that you’re in control and paying attention to the certificate status on your published Web servers.

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

QUESTION:

Dear Dr. Shinder,

First, I  would like be sorry for inconvenient to you. But I hope you could share your great experience to me.

My name, Bong Benly (Mr.). Benly is my first name. I live and work in Cambodia. At my institution, we use MDaemon (9.0.6) as mail server. Since I installed ISA server 2004, we could not send email to outside, and could not receive email from outside too. All email to outsiders, were get stuck in MDaemon.

I checked for solution from MDaemon website, the answer is as below:

There is an application filter for SMTP in ISA that needs to be disabled. Visit www.isaserver.org for more configuration information.

I still have no idea to get it work. I hope to hear from you. Thank you for your time.

With my best regards,

Benly

ANSWER:

It seems strange that that the recommendation would be to disable the SMTP filter, since the SMTP filter provide vital security for published SMTP server. Keep in mind that the SMTP filter work only for Server Publishing Rules, not for outbound SMTP messages. So, for the techs at the MDaemon Web site to tell you to disable the SMTP filter to fix an outbound SMTP problem sounds ridiculous and indicates that they don’t understand how the ISA Firewall works, and they’re just guessing as to the nature of the problem.

The most common reasons for outbound mail to get “stuck” at the SMTP MTA include:

• DNS problems. The SMTP server can’t resolve the name of the destination SMTP servers
• Access Rule problems. You haven’t created a DNS server rule that allows outbound DNS, or you haven’t created a rule that allows outbound SMTP for the SMTP server
• ISP problems. The ISP doesn’t allow you to send outbound SMTP. They might require that you use their SMTP relay

Bottom line: The probability that a correctly configured ISA Firewall is blocking outbound SMTP messages from going through is infinitesimally small.

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)