I’ve seen a great number of odd troubleshooting problems on the ISAserver.org messages boards over the last month. The typical solutions for the types of failures being reported aren’t fixing the problem. What is fixing the problem is addressing the Registry entries required to fix the RSS and other networking bugs introduced in Windows Server 2003 SP2. If you have Windows Server 2003 SP2 installed on your ISA Firewall and you’re having new problems that you can’t explain, then make the Registry changes recommended on the ISA Firewall Team blog at:

http://blogs.technet.com/isablog/archive/2007/03/2...2.aspx

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)

When you enable the “Allow users to change their passwords” option on the Web listener used for publishing Exchange Server, your users experience delays while logging in to Outlook Web Access (OWA). The delay occurs after the user enters his credentials and clicks on the Log On button in the OWA logon form. You are using ISA Server Forms-Based Authentication. ISA Server 2006 is running on a Windows Server 2003-based computer with Service Pack 2 or the Scalable Networking Pack installed.

Go here to find the solution to this problem:

http://support.microsoft.com/kb/555958/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)

I’ll get questions from time to time from readers regarding their WPAD autodiscovery publishing not working correctly. They’ve created WPAD entries in DHCP and/or DNS but still the Firewall and Web Proxy clients aren’t getting the autodiscovery information from the ISA Firewall. What’s up with that?

What’s usually up is that autodiscovery publishing wasn’t enabled on the ISA Firewall Network on which you want it enabled. For example, go to the Networks node in the left pane of the ISA Firewall console and then click the Networks tab in the middle pane. Double click on the default Internal ISA Firewall Network.

In the Internal Properties dialog box, click on the Auto Discovery tab. Autodiscovery is disabled by default. You need to put a checkmark in the Publish automatic discovery information for this network checkbox. The default port is TCP 80. While you can change this to any port number you like, if you are using DNS WPAD, then you must leave it at TCP 80. If you’re only using DHCP WPAD for autodiscovery, then you can use any port you like and configure your DHCP option to support this alternate port.

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 question came up recently regarding redundancy for ISA Firewall Web Proxy clients. There are several ways you can do this, including using NLB or client side CARP. However, if you’re using the standard edition of the ISA Firewall, both NLB and client side CARP aren’t available to you. However, there is still a failover option for Web Proxy clients of Standard Edition ISA Firewalls.

If you go into the Networks node in the left pane of the ISA Firewall console and then click the Networks tab in the middle pane, you can select an ISA Firewall Network for which you want Web Proxy clients to fail over to another ISA Firewall.

For example, double click the default Internal ISA Firewall Network and then click the Web Browser tab. At the bottom of the dialog box you’ll see the option If ISA Server is unavailable, use this backup route to connect to the Internet. The default setting is Direct Access, which means that the client will try to use it’s SecureNAT or Firewall client configuration to access the site if the Web Proxy Filter becomes unavailable. However, it’s unlikely that just the Web Proxy Filter will fail, and it more likely if the Web Proxy Filter fails, the entire machine has failed and it probably off or blue screened.

In this case, you can use the Alternative ISA Server option and then enter the name of the ISA Firewall that you want the Web Proxy clients to use if the Web Proxy clients can’t communicate with the primary ISA Firewall’s Web Proxy Filter. You can see the alternate address in the figure below.

It’s important to note that this only works if you configure the Web Proxy clients to use the autoconfiguration script. This can be done most easily by provisioning the Web Proxy clients to be configured by the Firewall client installation. You can choose either the autodiscovery option (Automatically detect settings) or the autoconfiguration script option, as seen in the figure below.

Note that you’ll need to setup WPAD entries if you want to use the Automatically detect settings options.

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)

The title says it all!

Check out these scripts at:

http://forums.isaserver.org/Script_for_loading_bla...tm.htm

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)

SOX and HIPAA compliance requires that you exercise tight control over information moving between the protected network and the Internet. In order to meet these requirements, you must use an advanced stateful packet and application layer inspection firewall, such as the ISA Firewall. Simple firewalls such as the outdated PIX or similar “hardware” firewalls clearly don’t meet these requirements.

What makes the ISA Firewall so secure? Check out this list of checks and tests the ISA Firewall Team does to make sure your company meets the high security requirements suggested by SOX and HIPAA:

1. Threat Modeling – Together with subject matter security experts we performed a security design review for each component to identify design weaknesses, evaluate security architecture, identify threats to be tested and ensure that default settings are secure.
2. Manual and Automatic Code Reviews – We’ve ensured that all code undergoes human code reviews and that that all issues detected by static code analysis tools, such as PREfast, are fixed, to ensure code has no vulnerabilities.
3. 3^rd party penetration (pen-testing) – We employed the services of the best pen-test companies in the industry to perform security audit and penetration testing of the product.
4. Pen-testing and fuzzing – Our internal pen-test team tested every component for security vulnerabilities, especially buffer overruns. Moreover, to facilitate this work the ISA Server team developed the FuzzGuru fuzzing framework that was later adopted by many other teams in Microsoft and is used to look for buffer overruns and access violations.
5. Monitoring public security research  – We track security research in areas relevant to ISA Server – HTTP, VPN, PKI, proxies, firewalls, etc. I personally spend hours reading mailing lists, such as BugTrack and DailyDave, reviewing security research papers from DefCon/BlackHat/Usenix and other conferences. I regularly monitor CVEs - security vulnerabilities of other products. For each of them I evaluate whether it or a similar one may affect ISA Server.
6. We review the user interface and product documentation to ensure they clearly provide security best practices.
7. We regularly ship service packs fixing security vulnerabilities for shipped products, when we find new ones using pen-testing methodologies and tools that emerged since the previous release.

For the complete story on how the ISA Firewall was designed as an edge firewall to protect large enterprises, check out this post by John Neystadt on the ISA Team Blog at http://blogs.technet.com/isablog/archive/2007/07/0...x.aspx

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)

I received an email from someone yesterday who said that domain membership of the ISA Firewalls might have an adverse effect on Sarbanes-Oxley compliance. I thought this was interesting, because domain membership of the ISA Firewall confers a higher level of security than workgroup ISA Firewalls. However, having never actually read the entire Sarbanes-Oxley Act of 2002, I couldn’t say authoritatively that domain membership wasn’t an issue for ISA Firewalls and ISA Firewall arrays.

Today I decided to spend the morning reading the entire 66 page SOX Act of 2002. If you’d like to read it yourself, you can find it http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi...st.pdf

The result of my investigation is that there are no references to ISA Firewall domain membership, or to any specific IT or network security related configurations. The only references I found that were related to IT operations is that in several areas it is mentioned that “internal controls” must be exercised over corporate data that apply to SOX.

Because of these multiple references to internal controls, this argues for making the ISA Firewall a domain member because when the ISA Firewall is a domain member, you have enhanced security in a number of areas, including User Certificate based authentication, outbound access control and enhanced reporting using both the Web Proxy and Firewall clients, and centralized security controls by using highly codified Group Policy objects for ISA Firewall arrays. Perhaps most importantly, domain joined ISA Firewalls are easier to configure and maintain, and complexity of configuration is the leading cause of firewall related security events.

For all these reasons, to the best of my knowledge after reviewing the entirety of the SOX Act of 2002, there is no reason why the ISA Firewall or ISA Firewall array should not be domain members, and in fact, domain membership enhances the internal controls required by SOX.

NOTE: This is a review of SOX only. I will also review COBIT 4.1 to determine if there are domain related comments in there, but a quick review shows nothing related to ISA Firewall domain membership. I plan to review this with Jim Harrison and Tim Mullen next week and provide a more detailed analysis of anything that COBIT might infer related to domain membership.

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)

Common Criteria: A Global Security Standard

Many software products claim to make your networks secure, but how do you know for sure? Common Criteria (CC) is a framework for evaluating and certifying the security of IT products and systems that is recognized by governments and IT professionals around the world as a critical measure of the quality of an information technology security product. CC certification is increasingly used as one of the key decision-making criteria by local, federal, and international government agencies and is also becoming a key differentiator for many private-sector industries such as finance and healthcare. You can read more about CC on the Common Criteria site.

ISA Server 2006

Microsoft Internet Security and Acceleration (ISA) Server 2006 has been recently approved for certification of Common Criteria Evaluation Assurance Level 4+ (EAL 4+). The certification work is in progress, performed by the Federal Office for Information Security, the Common Criteria certification body of the German government. Microsoft Internet Security and Acceleration (ISA) Server 2006 is now listed in the Evaluated Products List (EPL) of the BSI.

For more information: http://www.microsoft.com/isaserver/commoncriteria/...t.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)

One of the features that I really liked about previous versions of the ISA Firewall (2000 and 2004) was the auto logoff when the user navigated about from the OWA page. I was very disappointed when this feature was removed from the 2006 ISA Firewall. I asked some of the ISA Firewall Team members why this feature was removed, and I got a variety of responses, mostly saying that auto logoff was problematic and difficult to make work right.

However, even with the previous versions of the ISA Firewall, if a pop-up blocker is enabled on the browser, the auto logoff feature still wouldn’t work.

This is a real problem, because users at kiosks, public computers, and unmanaged computers can leave the OWA site and think that they’re automatically logged off. If another person comes to the same computer later, he can look at the URL history in the Internet Explorer address bar and click on the OWA URL and be automatically logged on. This can be seen as a significant security issue, even when form-based authentication is used.

However, there is a solution. Messageware has a product called NavGuard that solves this problem. With NavGuard, users are automatically logged off when they move away from the OWA site and they’re given prompts about whether they want to log off or not.

For more information on this ISA Firewall security issue in OWA environments, check out Messageware’s White Paper on this issue at http://www.messageware.com/ISAWhitePaper.htm

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)

About two years ago, Desjardins moved to Microsoft Internet Security and Acceleration (ISA) Firewall 2004 Service Pack 2 (SP2), which features HTTP compression and traffic prioritization. Corriveau says the deployment, which went into production last year, has already saved on bandwidth costs and boosted performance. 

For more information:

http://www.itbusiness.ca/it/client/en/home/News.as...=42642