ISAserver.org Monthly Newsletter of January 2009 Sponsored by: Collective SoftwareWelcome to the ISAserver.org newsletter by Thomas W Shinder MD, MVP. Each month we will bring you interesting and helpful information on ISA Server. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: tshinder@isaserver.org 1. ISA and TMG Firewalls: Control the Language to Control the DiscourseMost people do not think about the deeper meaning of the words they use. Most of the time we just want to communicate an idea, a concept, a request or a wish. There is typically no reason to think about the underlying issues and unconscious associations tied to the specific words we use to communicate what we are trying to communicate. However, there are people who do think a lot about the deeper implications of the words they use, because they know the power of those words. There are usually multiple words you can use to communicate the same thing. However, your word choice determines what other associations the person or persons you are communicating with will make that are in addition to what your main topic of communication might be. A good example of this is seen when talking about ISA or TMG firewalls. You might notice that I always refer to ISA Server or Forefront Threat Management Gateway as firewalls. Why do I do this? Because in our society (or more accurately, "societies" since this newsletter goes to readers worldwide), the term "firewall" is associated with security. "Firewall" is a word that even non-IT people know and use, and they associate "firewall" with security and protection. When something is a "firewall", there is an automatic conscious and unconscious association with strong security and improved protection. In contrast, consider the terms "server" and "computer". We all know servers and computers are prone to viruses, worms, trojans and other forms of malware. "Servers" and "computers" need firewalls, anti-virus software, anti-spyware software and all sorts of other technologies to secure them from the malware and hackers out there. "Servers" and "computers" are potential victims; they need to be protected. In the mind of the person with whom you are communicating, "servers" and "computers" are the antithesis of security. Servers are the sheep; firewalls are the sheepdogs. This is why it is important for you to associate (or more accurately concatenate) the term "firewall" when you talk about ISA or TMG, and disassociate the terms "server" and "computer". This was a major challenge with ISA, since the name of the product is "Internet Security and Acceleration Server", making it harder to completely disassociate the term "server" from the product. In contrast, it will be much easier with the Forefront Threat Management Gateway, or TMG, since the TMG firewall can be more easily and reliably referred to as a firewall because "server" is not part of its name. Purists might find this to be a silly argument - stating that in fact even "hardware" firewalls have for years in their technical documentation referred to various services as "servers". However, have ever heard of a "PIX server" or "Netscreen server" or "Check Point server"? No, what you hear about are "PIX firewalls", "Netscreen firewalls" and "Check Point firewalls". Because these terms are part of standard usage, we should always refer to the ISA and TMG firewalls as "ISA firewalls" and "TMG firewalls". To do otherwise creates fear, uncertainty and doubt about the inherent level of security included with the ISA or TMG solution. In spite of this, it never ceases to amaze me when I see push back on using the more effective and powerful terminology. In a recent editing effort, I found that even people who are great fans of the ISA and TMG solutions are uncomfortable referring to them as firewalls. They are comfortable calling them "servers", or "computers" or "proxies", but shy away, for presumably unconscious reasons, from referring to the ISA or TMG firewalls as firewalls. While I do not think these people represent an anti-ISA or TMG contingent, they should be aware of what they are doing, and that it is vital that they disassociate the terms "server" and "computer" from ISA, and even more importantly in the future, from TMG. What do you think? Is this a real problem? Does it matter if you refer to an ISA or TMG firewall as a firewall? Should they be called ISA servers and TMG servers? Which sounds "stronger" and more secure to you? Do you think that an ISA firewall dies a little inside each time you call it a "server" or "computer"? Should Microsoft make it a policy to not refer to TMG as a server, and use alternate terminology such as "firewall" or "gateway" or even "machine" or "device"? Let me know! Send me a note at tshinder@isaserver.org and I will share the results with you next month.
Tom ===================== 2. ISA Server 2006 Migration Guide - Order Today!
3. ISAserver.org Learning Zone Articles of InterestWe have a great group of articles in the Learning Zone that will help you get a handle on your most difficult configuration issues. Here are just a few of the newer and more interesting articles:
4. KB Article of the MonthI have some very bad news to share with you all. The MCP KB search site that I have been using for the last year or so to find new KB articles is dead. It is gone, it has no DNS records. That site was our last and best hope to find the latest KB articles. Given that I can no longer provide this service, we will change the name of this section to "KB Article of the Month!" So, instead of being a list of recent, important KB articles, it will be a KB article that I think is interesting or useful. "An ISA server or Forefront Threat Management Gateway server requests credentials when client computers in the same domain use Internet Explorer to access Web sites that contain Java programs Consider the following scenario:
In this scenario, when the client computer uses Internet Explorer to access a Web site that contains Java programs, the ISA Server or the Microsoft Forefront Threat Management Gateway, Medium Business Edition server may request that the client computer provides credentials. This issue occurs even if the client computer is located in the same domain as the ISA server or the Microsoft Forefront Threat Management Gateway, Medium Business Edition server." Go here to find the answer. 5. Tip of the MonthThis month's tip has to do with a recent update affecting PPTP functionality on ISA firewalls. When you install KB 95670, you might find that you cannot authenticate to your ISA firewall after establishing a PPTP connection. In addition, you might find that that if PPTP is not yet enabled, and you then try to enable PPTP, the RRAS console will show no ports allocated for PPTP. Check out this thread on the ISAserver.org Web boards. At this time there are no references in the Microsoft KB regarding this issue. If you find that you?re having similar problems, just uninstall the hotfix and report your case to PSS. You will not be charged for reporting a bug. Have you been thinking about putting your ISA or upcoming TMG firewall in a virtual machine? I know there's guidance on how to do this and it's even supported by Microsoft PSS - but is it a good idea? Is it a good idea to expose your network security device to the security flaws introduced by other VMs running on the same machine, or security issues on the host operating system itself? Chime in with your opinion on this issue in this thread. 6. ISA Firewall Links of the Month
ISA Firewall fans and writers! If you publish an article or a blog post about the ISA firewall, let me know. I'll put links to your articles and posts in the newsletter. Just send the link to tshinder@isaserver.org
7. Blog Posts
8. Ask Dr. TomQUESTION: My name is Josh Blalock. A co-worker of mine said that he has corresponded with you in the past about various ISA issues, and that you have always been extremely helpful and incredibly knowledgeable. So, I figured I would introduce myself and run an issue by you that has been baffling me for the last couple days. We have an ISA 2006 firewall on Windows Server 2003 R2 SP2 set up as an Edge firewall and proxy. Our OWA publishing rule seems to be working fine, but a couple of our Access Rules are not working the way I had hoped. I have created two web Access Rules, HTTP and HTTPS. They are both set up exactly the same, with the exception of specified source ports. They are simple: ALLOW HTTP traffic from INTERNAL and LOCAL HOST to EXTERNAL, and instead of allowing traffic on any allowable source port, I have specified FROM 80 TO 80 (443 to 443 for HTTPS). If the ports are specified, the rules do not work. If I leave the source ports UNspecified, then the traffic passes. After reviewing the ISA logging I realize that this is because when I try to hit an HTTP page from the client, the traffic arrives at the ISA server from a random source port, so before ISA can even forward the traffic on port 80, the traffic is denied by the Default Rule since it did not arrive from a source port of 80. I realize the quick fix is to just check the radio button for Any Allowable Source Port, but I would rather lock things down better than that if I can. Are you aware of any fix or workaround that would allow the ports to continue being specified from the source? Thanks so much for any and all time and help! - Josh Blalock ANSWER: Hi Josh, First, I want to acknowledge that you are trying to do a good thing by using the ISA firewall's feature set to further enhance network security. However, the problem in this case is not with the ISA firewall, its with the client applications that you are using. When client applications open a socket, they typically use a random source port. This is especially the case for client applications. Some applications can be configured to use a specific source port, such as the Microsoft RDP client. In the example of the Microsoft RDP client, you can configure the client to use a specific source port, and then configure an RDP Server Publishing Rule that requires the source port match the port number you assigned to the RDP client. However, in an outbound scenario such as yours, where you can't control the source ports on the clients, the source port control scenario that you want to enable isn't possible. Got a question for Dr. Tom? Send it to tshinder@isaserver.org. TechGenix Sites
|