MalwareDomains.com provides a DNS blocklist of known malware domains. This list is natively used as a part of DNS configuration, however, the below tool will allow you to import the domains.txt definitions file into ISA Server as a URL Set or DNS Set. You can then create a deny access rule based on the imported list.

Note that I have not tested this application yet, so use at your own risk

Check it out at:

http://sync-io.net/ISATools.aspx

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

This is always in interesting area of conversation.

Check out Mike Bazarewsky’s answer to the problem at:

http://demos.software-answers.com/CS/blogs/mike_ba...X.aspx

Also, check out Microsoft’s solution:

http://support.microsoft.com/kb/556039/en-us

(which interestingly enough, it also done by Mike!)

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Ever wonder what access a specific user or group has through the ISA Firewall? While you could fish through your firewall policies and figure it out, sometimes there are so many rules controlling so many protocols and sites, it’s hard to see the forest from the trees.

In that case, you can use a new tool called ISA User Access Check.

To download the tool, go to:

http://sync-io.net/ISATools.aspx

This tool is a work in progress, so if you want to participate in the development, check out:

http://forums.isaserver.org/m_2002066218/mpage_1/k...066279

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

One of the more common troubleshooting issues with the ISA firewall has to do with the DNS settings on the firewall’s interfaces. The same issues apply to the new TMG’s interfaces.

In order to avoid common DNS and name resolution issues, here’s what you need to know about configuring DNS settings on the TMG:

• Never put an an external DNS server address on any of the TMG firewall’s interfaces if you need to resolve internal host names
• You also always need to have the TMG resolve internal host names, so don’t put any external DNS server addresses on any of the TMG’s interfaces
• Configure a DNS server on only one interface on the TMG. There is no fault tolerance value to adding DNS server settings on multiple interfaces
• Configure the internal interface of the TMG firewall with the DNS server settings. If you have multiple internal DNS servers, you can put them all on the same internal interface
• Move the internal interface to the top of the interface list so that the internal interface is queried first for DNS settings
• Configure the internal DNS server that the TMG will use to resolve host names so that it can resolve both internal and external names
• You can have the internal DNS server perform recursion on its own, or you can configure the internal DNS server to use a forwarder (such as your ISP, or even another DNS server on your network that is configured as a caching only forwarder)
• Remember that the Forefront TMG Firewall will resolve names for Web Proxy and Firewall clients. It will not resolve names for SecureNAT clients, so make sure you configure your SecureNAT clients with a DNS server that can resolve both internal and external hosts names. It can be the same DNS server that the Forefront TMG Firewall is using, if you want
• If you have a Forefront TMG scenario where you don’t want the machine to resolve names (such as a Web hosting environment), you can leave out all DNS settings and use a HOSTS file on the TMG firewall

DNS misconfiguration on the TMG can lead to performance problems and failures to reach requested sites.

Also, remember that if the TMG firewall is in an environment where you have enabled DDNS (such as when the TMG is a member of the domain), when make sure that only the internal interface of the TMG firewall is registered in DNS. Double check your DNS server’s Host (A) records after installing the TMG firewall to make sure that the external interface is not registered.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

All versions of the ISA Firewall, as well as the TMG support Firewall chaining. Firewall chaining involve two or more ISA or TMG devices in an upstream and downstream configuration. The device closest to the Internet is considered the upstream device, while the device closest to the source requests is referred to at the downstream device.

The advantage of using Firewall chaining is that you can deploy the downstream firewalls in a way that is transparent to your routing infrastructure. The downstream firewall only need to know the route to the upstream ISA firewall, even if that route isn’t the default gateway of the downstream ISA firewall. Once the downstream firewall knows the route, it sends the requests directly to the IP address of the upstream ISA or TMG firewall.

Firewall chaining forward requests from SecureNAT and Firewall clients for all protocol except for the HTTP and HTTPS. Those requests are automatically forwarded to the Web Proxy filter. Similarly, requests from Web Proxy clients are not handled through a Web chaining configuration. To route HTTP requests in a way similar to Firewall chaining, you will need to use Web Proxy chaining by creating a Web chaining rule.

Over the years there’s been a bit of “rot” taking place in the Firewall chaining feature, but it really never was clearly documented. This is where the TMG firewall documentation comes in handy. The limitations of firewall chaining now include:

• Responses to firewall chaining requests are not cached. This makes sense, since it’s the Web Proxy filter that’s responsible for Web caching.
• Authentication on the upstream firewall is not supported. While you can enforce authentication on users on the downstream firewall, you cannot require that the upstream firewall authenticate the downstream firewall.
• Complex protocols might not work correctly, in spite of the fact that the downstream firewall is essentially a Firewall client to the upstream firewall. This is really problematic, was one of the major reasons to using the Firewall client is to support complex protocols that require secondary connections
• Firewall chaining does not work if you have defined an TMG Firewall network between the downstream and upstream TMG firewall. Again, this is really problematic, because in most cases where there is Firewall chaining, you will want to create an TMG Firewall Network between the upstream and downstream

Bottom line? Firewall chaining is really only useful if you’re using only SecureNAT clients and simple protocols, or at least protocols that have application filters. If you have Firewall clients behind the downstream firewall, then Firewall chaining is not for you.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)