Every now and then someone asks me for the Word .doc version of an article or article series I’ve done on ISAserver.org. In general, I don’t provide these docs as the articles on the site have a Print View button that allows you to create a printer friendly version of the doc that’s on the site.

Is their any value to putting up Word .docs of the articles on the Web site? What would you get out of this if we decided to put them up? Are their problems with the print function on this site that we need to fix?

Let me know!

Thanks!

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:

Hey Tom, I love the new site.  Much more functional and faster than the last one.  I just finished reading your DNS Best Practices article on your blog and thought maybe you could answer a question for me.  I posted this on the forums but have been less than impressed with the responses.

I have a few Internet users configured to use only the Firewall Client with ISA 2004.  When the user goes to any website such as www.google.com, there is roughly a few seconds delay and then the request goes through and the page is loaded.  This does not happen with Web Proxy clients that can load the page immediately.

I performed a network capture of the request and it shows several DNS queries for www.google.com directed to our Internal DNS servers first, which currently fail as they cannot resolve external DNS queries, then the Firewall Client does its thing and the request goes through and the page loads.

After doing some research I see lots of people using forwarders on their Internal DNS servers to fix performance problems.  I tried this in the lab and it definitely fixes the problem.
I simply want to know, is it normal behaviour for Firewall Clients to query the Internal DNS servers first, then use the control channel of the firewall client to perform the request?

Anything I read says no, but I cannot seem to find away to fix this…other than use DNS forwarding from our internal DNS servers. You help is greatly appreciated.

Bryan Feltin

ANSWER:

Thanks for the kind words about the site!

First, let’s look at how things are supposed to work. When the Firewall client intercepts a connection request from the Winsock application, the name resolution is handled by the ISA Firewall and not the client system. After the ISA Firewall resolves the name of the destination site, the ISA Firewall then proxies the request to the destination host.

Second, Web proxy clients also have name resolution done by the ISA Firewall, and not by the client system. So both the Web proxy and Firewall clients allow the ISA Firewall to resolve host names on their behalf.

Because the ISA Firewall needs to resolve external host names, as well as internal host names (if the ISA Firewall is a domain member, which it should be for the highest level of security) you should configure the ISA Firewall to use an internal DNS server that can resolve both internal and external host names.

The primary reasons for using a forwarder are:

• Security You should avoid allowing internal DNS servers to contact untrusted DNS servers on the Internet. You can do this by creating a caching-only DNS server on the corporate network and using it as a forwarder
• Performance The idea here is that the forwarder will have a much larger cache than your own DNS servers, and therefore avoids the need to perform recursion to resolve the name, which can significantly improve performance if the forwarder is well-managed and is not overloaded to the extent the response times suffer

(NOTE: If you have an unsophisticated firewall, such as a PIX, in front of the ISA Firewall, you may need to configure it to support EDNS, or remove the unintelligent firewall)

The level of security and performance a DNS forwarder can provide depends on what device you use as your forwarder. Poorly managed ISPs will have not provisioned their DNS servers appropriately and you might find that using their machines as forwarders will actually slow down your name resolution attempts. On the other hand, a well-managed ISP will have high performance DNS server that can return responses much faster than one of your internal DNS servers (or internal caching-only forwarders) can perform recursion.

The same issues apply in regards to security. Many large ISPs use versions of BIND that are not secure and they have not taken any steps to fix the problem. In that case, you will want to use your own internal caching-only DNS server as a forwarder, although in this case, you will lose the benefits of the large cache on the ISPs DNS server, since in this scenario your own caching-only DNS server is going to perform recursion.

So, to answer your questions:

• A DNS forwarder can improve performance
• A DNS forwarder has no effect on how the Firewall client performs name resolution
• Firewall clients will allow the ISA Firewall to perform name resolution on their behalf
• Firewall clients will perform name resolution themselves for domain names listed on the Domain Name tab for the ISA Firewall Network — This enables Direct Access for internal resources for Firewall clients
• Web proxy clients will always allow the ISA Firewall to perform name resolution on their behalf, except for those sites configured for Direct Access

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 mentioned problems with editing the FBA form. PCC on the ISAserver.org Web boards came up with the solution. Check it out:

Within the HTML folder there is a folder named “nls”.  Within the “nls” folder there are several folders for all the different languages.  Go to the “en” folder if you are using English (or whatever folder is for your language) and you will find another “Strings.txt” file there.  Edit that file and you should see the changes after you restart the firewall service.
< Message edited by PCC — 27.Oct.2006 2:40:51 AM >

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

Find the entire thread at http://forums.isaserver.org/m_2002027726/mpage_1/k...030577

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)

From Jim Harrison:

“First of all, many thanx to Steve Moffat for his high-speed pedo-gluteal assist in this effort.  This change is something that’s been needed for some time now and it’s finally come to fruition.

The reason I bring this up in this forum is that many of you have direct links to specific tools on this site and those links are now most likely broken (my web logs clearly show this - lots of 404’s for old links).  You should review your ISATools.org references and update them.  Since the files list is now organized according to ISA version, it’s probably better if you just point your users to the root page so they can select the ISA version and select the file from there.

Any feedback; positive or negative is welcome…

Jim Harrison (ISA SE)”

Visit ISAtools.org now at www.isatools.org

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 configure a site for Direct Access, you’re telling the Web proxy client to not use it’s Web proxy client configuration to connect to the desired resource. The client then must leverage another method of communication to access the destination site, such as it’s Firewall client configuration, or if not configured as a Firewall client, it’s SecureNAT configuration.

Direct Access sites are configured in the Web browser configuration in the ISA Firewall console, as seen in the figure below.

There must be a mechanism to get the Direct Access list to the Web proxy clients. The Web proxy clients must have access to this list, because it’s the browser that makes the decision for Direct Access, not the ISA Firewall. That is to say, if the user wants to go to www.hotmail.com, its up to the user’s browser to decide “hey, I’m not supposed to use my Web proxy client configuration to reach Hotmail, so I’m not going to forward this connection request to the ISA Firewall’s Web proxy listener on my ISA Firewall Network.”

The way the browser gets the Direct Access list is via the autoconfiguration script. There are two ways to access the autoconfiguration script:

• Web browser autodiscovery (Autodiscovery information publishing must be enabled on the ISA Firewall)
• Web browser configuration to use the autoconfiguration script (this can be done manually, through Group Policy, or via start-up or log on script)

The figure below shows the Web browser configuration on my computer. This setting was made in AD Group Policy.

Notice the third option in this dialog box: Use a proxy server for you LAN. If you enable this option only, then the Web proxy client computers will not receive the autoconfiguration script and your Direct Access entries will not work.

The next step is to remove the Web proxy filter from the HTTP protocol. We need to do this because if we don’t remove the Web proxy filter from the HTTP protocol, then the Firewall client and the SecureNAT client requests will be automatically forwarded to the Web proxy filter and we’ll end up in the same mess we were in when the machine was acting as an explicit Web proxy client.

Go to the Properties of the HTTP protocol and remove the checkmark from the Web Proxy Filter checkbox. Click OK and save the changes.

After the Web proxy filter is unbound from the HTTP protocol, only machines acting explicitly as Web proxy clients will benefit from the Web proxy filter’s features, such as Web caching and HTTP protocol inspection. When machines configured as Web proxy clients try to access servers on the Direct Access list, the Web proxy client will not act as a Web proxy client for those connections and thus no caching or HTTP protocol inspection will take place for these problematic sites.

The last step is to create a rule (or rules) for the Direct Access site(s). If you still want to require authentication for outbound access, to those sites, then the client machines must be configured as Firewall clients, since SecureNAT clients can’t authenticate. If you don’t want to require authentication to reach the Direct Access site(s), then you can use the SecureNAT configuration.

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:

Tom,

We have ISA Server 2004 configured as a “back end” firewall, our front end is a Cisco PIX.

We have no problems blocking Web access (port 80 and 443) based upon Windows userids.
However when we try to block users from FTP it always fails and allows FTP access. We have tried allow rules and deny rules but nothing seems to work.

The only way we found to block FTP was with Microsoft’s new browser IE 7. IE 7 will stop any FTP request and will show the ISA Server message not allowing the FTP protocol.

Bottom line, is there any way to block FTP from client PCs not using IE 7? Thank you

Robert W. Kay - MCP

ANSWER:

One thing you need to keep in mind is that the ISA Firewall will not allow outbound access to protocols unless you give users or machines explicit access. If there is no rule that allows the connection, then the connection is dropped by the ISA Firewall.

The first thing I’d check is the Firewall policy. Do you see a rule that is allowing outbound FTP connections? If so, either disable that rule, or remove the FTP protocol from rule. If the rule is an “all open” rule, you can create a protocol exception in the rule by selecting the “all protocols except” option and exclude the FTP protocol.

If you’re not sure what rule is allowing the outbound FTP connections, then you can use the ISA Firewall’s real time log analyzer and check the FTP connections. The rule that allows the connection will appear on the line representing the outbound FTP connection.

One last thing to consider is to make sure that the ISA Firewall is an inline device. Often, the “network guys” will claim that the ISA Firewall is set in a back-end firewall topology, when in fact the ISA Firewall was placed in the PIX DMZ and both the ISA Firewall and the PIX can provide direct outbound paths to the Internet. This allows users to set a default gateway configuration so that outbound FTP goes through the PIX, instead of the ISA Firewall.

The solution in this case is to correct the network topology and place the ISA Firewall behind the PIX, not adjacent to it. There should be no way for users to bypass the ISA Firewall for outbound Internet access.

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)

“With its new line of security applications for businesses, officially introduced in June, the company is starting an effort to establish itself as a key vendor in a market that it has previously been happy to turn over to Independent Software Vendor (ISV) partners. Those partner-turned-competitor ISVs will have to respond to Microsoft’s challenge, just as other partners will need to manage relationships both with current ISV security partners and with Microsoft in order to fully exploit the opportunities that Forefront creates.

“Available now, Microsoft Internet Security and Acceleration (ISA) Server 2006 is a gateway server designed to protect a network from Internet-based threats and give users remote access to applications, the company’s literature says. Microsoft’s Steve Brown says the company expects to release a new Forefront version of ISA with the release of Longhorn server in late 2007.”

For more information: http://rcpmag.com/features/article.aspx?editorialsid=643

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)

ClearTunnel:  Close the SSL Hole!

http://www.collectivesoftware.com/Products/

Your ISA web filters are powerless to inspect outbound (forward proxy) SSL connections for:

• Unauthorized browsing
• Viruses, trojan code, web exploits
• Prohibited content

All this and more can be going on right now right under your firewall’s nose, and since ISA can’t inspect forward SSL connections, you might not find out until too late!

Get the only solution for ISA Server that empowers ISA to see inside SSL tunnels. With ClearTunnel, ISA can leverage these powerful features:

• Contents of HTTPS connections are exposed to the web proxy as normal HTTP requests/responses.
• Apply HTTP filter rules to HTTPS connections.
• Cache forward proxied HTTPS responses, decreasing your external bandwidth usage.
• Automatically compatible with most third-party web filters, enabling them to see and secure HTTPS traffic as though it was normal HTTP.

Don’t be fooled by Blue Coat sale reps who misrepresent the ISA Firewall. The ISA Firewall provides a higher level of security and superior performance per dollar that any Blue Coat offering. Obtain more security, better performance and higher reliability at a fraction of the Blue Coat high margin reseller cost by using ISA Firewalls with ClearTunnel SSL inspection.

Instead of paying the high margins to Blue Coat resellers, why not save that money and buy a car or boat for yourself instead of paying for the Blue Coat sales guy’s car and boat? You’ll end up with a superior ISA Firewall solution and the satisfaction that you weren’t tricked by the Blue Coat guys.

We won’t be fooled again!

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 Whale Intelligent Application Gateway with SharePoint Application Optimizer is the only SSL VPN solution specifically designed for SharePoint. The Whale Intelligent Application Gateway complements the Microsoft Internet Security & Acceleration (ISA) Server 2004 solution for securely publishing SharePoint (and Exchange) by providing additional security elements, integrating third-party applications into the portal and publishing to unmanaged endpoints without requiring a component download. The gateway provides browser-based access, endpoint security including the Attachment Wiper session residue shredder, and the ability to host multiple portals on a single gateway. By leveraging these capabilities, customers can expand the availability of SharePoint to a broad range of users and access scenarios, entrenching its value as a collaboration platform.

For more information about using the ISA Firewall as a SSL VPN Gateway, check out:

http://whitepaper.informationweek.com/cmpinformati...ONWEEK

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 spend a lot of time talking about DNS issues on this site. One of the core competencies that any network engineer needs to master is DNS, since name resolution is critical for almost all network connected devices and applications. You need to have a good grounding in DNS basics to troubleshooting many networking and connectivity related problems.

There are two core concepts that you should master as an ISA Firewall admin. The first is that of the split DNS. This topic is widely misunderstood and has slowed the adoption of robust and highly functional split DNS infrastructures. For detailed information on what a split DNS is, what it does, and why you need to implement a split DNS, please see the following articles:

http://www.windowsecurity.com/articles/Split-DNS-S...s.html

http://www.isaserver.org/tutorials/You_Need_to_Cre...S.html

http://www.isaserver.org/tutorials/2004illegaltlds...s.html

The key DNS concept you need to master is separation of DNS operations. This is important because a well designed, secure infrastructure has at its core an implementation of least privilege. Least privilege is the reason why we create multiple perimeters for multiple security zones. Users and applications should never be able to access protocols and services that they don’t need in order to carry out business operations.

Tim Mullen (Thor) from www.hammerofgod.com provides an excellent treatise on this subject:

“I’ve found that many people seem to dance over the security ramifications of DNS/forwarders when designing an infrastructure. I had some off-list conversations about this, and thought that it may be valuable to fully flesh-out what I think the issues are and how to avoid them. Now’s also probably a good time to share my “trick” regarding publicly available DNS and minimizing service exposure. So, for the benefit of those who are interested:

When AD DNS is configured as a forwarder, all domain members using that DNS server will be able to resolve hostnames directly from their IP stack. There is no operational reason to have this– when one considers that most spyware/malware/trojans/backdoors/shells/etc typically depend on hostname lookups for direct access to a resource, the capability of a client box to
perform direct host lookups outside your network should (to me) be considered unwanted and un-needed. Personally, I qualify it as “dangerous.”

That’s why I always configure my AD DNS with a root (.) zone- that way, only local zones may be queried by the client’s stack. I typically only use web proxy clients for HTTP(S)/FTP where all DNS is proxied by the ISA box. If one needs direct DNS for another application (say DOS FTP) then use the FWC and all DNS will be resolved over the control channel, still being proxied by the ISA server.

The ISA server itself will have whatever “public” DNS server configured in its stack so that it can do the resolution for the clients.

Not only is direct client DNS “dangerous,” but having an AD box set up as a forwarder is “dangerous” as well as the box must be configured to access a remote resource over TCP/UDP 53. This also means that you’ve opened that box up for incoming traffic on TCP/UDP 53 as well. Having static paths into your internal network from source port routing is crazy. I can push anything I want over 53, not just DNS (and have . Remember, the DNS filter is only for published DNS servers, not clients requesting DNS lookups.

But there is the issue of one wanting complete control over host names and the need to publish your own DNS. This is what the DMZ is for. The DMZ box is set as a forwarding server, and the internal ISA box is set to use that box for all DNS requests. In this way, only the ISA box itself need to request DNS outside the internal network, and it is already protected. In this manner, there is no DNS leaving the internal network at all, and no static ports into the internal network– only the ISA box looking up DNS, and only to that DMZ resource. The DNS server in the DMZ is protected by the border ISA box, which (where necessary) is publishing DNS to the DMZ for remote hosts to look up your domain information. And here the DNS filter is used.

But you can get even better than that– you can actually be fully in control of your own zone data without having to actually publish your DNS to the world if you have a decent ISP.

Here’s what I do for that– I have DMZ DNS servers set up as primary DNS zones, and have told my ISP to set up their servers as secondary zones for my domains. The DMZ box can only zone transfer to the IP’s of my ISP’s DNS servers. Additionally the DMZ box is set to forward to my ISP’s cache servers. So, at this point, all internal AD DNS is stopped at the controller, and only the ISA box can resolve DNS and only to the DMZ DNS server. My internal Exchange clusters’ stack resolves to the AD controller, and they smart host deliver mail to my DMZ GFI gateway, so still no DNS leaving. The GFI box in the DMZ uses the DMZ DNS.

The trick is that though I’m primary DNS, and though any changes I make to my DNS hosts are immediately replicated to my ISP as secondary DNS, I’ve registered my DNS with the domain registry as my *ISP* being primary. So the world resolves my host names via my *ISP’s* DNS servers, not *mine*. I don’t even have to publish DNS at all.

The end result is that no DNS requests leave my internal network at all, except for a single DNS box in the DMZ that can only resolve to the ISP DNS caches. There is no publishing at all, no internal paths, no vulns, nothing at all since the world resolves to the ISP boxes yet I have full control over all host name entries.

It’s a pretty tight config.”

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)