ISAserver.org Monthly Newsletter of April 2010
Sponsored by: Collective Software
<http://www.collectivesoftware.com/isaserver.newsletter.201004.captivate>
-------------------------------------------------------
Welcome to the ISAserver.org newsletter by Debra Littlejohn Shinder, 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 dshinder@isaserver.org
1. DirectAccess and VPN Clients - Are They Really a Greater Risk?
--------------------------------------------------------------
I have been hearing a lot of debate lately about remote access security. I don't know if it is because my husband is now on the Microsoft "Anywhere Access Team" or the fact that the working world is going mobile and corporate IT is still trying to figure things out. Whatever the reason, it is something that comes up over and over in my discussions of top IT issues with admins.
When you think about it, it does make sense that there is a lot of talk about how to deal with the security risks that may or may not be imposed due to the increasing number of remote clients. Remember, traditionally "network security" was an issue for the networking guys, and let's face it, the networking guys are geniuses when it comes to networking, but some of them are pretty much clueless when it comes to security in the context of the exploits that exist in the second decade of the 21st century.
That's why remote access security is such an important issue to the Microsoft admin. Many network folks can not get a handle on the issue because they really do not understand the software issue and the threat models that are based on the software issues. Instead, they seem to remain hamstrung by what Tom calls the "Cisco sales guy" approach to discussions around Microsoft software security, and those arguments really haven't changed much since Windows 95 and Internet Explorer 2.0 were popular - despite the fact that Microsoft's products and its focus on security have changed immensely.
So what does this have to do with DirectAccess and remote access VPN clients? For almost two decades, the "network guys" gave employees access to corporate networks using VPN technology. While they did not like it much, business requirements trumped network edicts. However, they did have a point - remote access VPN clients could be a security risk.
If you think back to the early and mid 1990s, the typical remote access VPN client had no host-based firewall installed, had no anti-virus software installed, and was essentially an unmanaged computer. These clients were typically laptops that moved from network to network and were exposed to all sorts of exploits, both physical and logical. When these clients connected to the corpnet, they shared their exploits with the rest of the corporate network. For that reason, the network guys often made it a point to segment the remote access VPN client computers from the rest of the corpnet.
The desultory state of remote access VPN client security was even more profound because corpnet clients were just that - they were always on the corpnet and they rarely moved outside the network. They were 80 lb. desktop computers that were bolted onto the desks and they weren't going anywhere. Not many people used laptops at work at the time, so it was really only a select few employees who had the need for VPN access. The corpnet computers were always manageable, always within the reach of corporate IT, and the risk of malware exposure similar to that experienced by the promiscuous remote access VPN client was significantly lower.
That was 15-20 years ago. Things have changed significantly. The entire Microsoft security model has changed with the introduction of the Trusted Computing initiative and the Software Development Lifecycle (SDL) process and Microsoft's diligent monthly update processes and infrastructure. In addition, the "corpnet client" is all but gone. Many organizations now give employees a laptop to use at home, at work, while on the road, and anywhere else they go. Those machines move in and out of the network. Some of them stay out of the network longer than others, which can be a problem, since they are more likely to fall out of compliance with the company's security policies.
Security for remote access clients has evolved over the decades. Now the remote access VPN client can be configured with:
* NAP access controls: The TMG firewall allows you to perform NAP enforcement on remote access VPN clients
* BitLocker: You can configure BitLocker so that a PIN needs to be entered when the machine is restarted, or woken up from hibernation
* Smart Card or other two-factor authentication: You can require two-factor authentication to establish the remote access VPN connection. If the intruder doesn't have the second factor (card or biometric), he won’t be able to attack the corpnet
In addition:
* Remote access VPN clients have Windows Firewall with Advanced Security turned on and configured via Group Policy, and it works with Network Location Awareness
* Remote Access VPN clients have anti-virus and anti-malware software installed as part of a standard security configuration. The days of going "commando" are over for corporate remote access VPN clients
* The split tunneling issue that was a concern for remote access VPN clients is no longer much of an issue, since the "routing" that might have been possible for ancient VPN clients is no longer enabled in modern Windows remote access VPN clients
* Modern firewalls such as the TMG firewall enable you to perform least privilege access, using strong user/group/destination/protocol/application controls as well as application layer inspection to protect remote access VPN connections
As you can see, the remote access VPN client is much more secure than the corpnet client in the days of yore. Since those bolted-in corpnet clients hardly exist anymore, the remote access VPN client security model has taken over and seems to be the current de facto configuration.
Unfortunately, there is one major problem with the remote access VPN client. Depending on the user, the remote access VPN client might not connect to the corpnet for long periods of time. During that interim, the VPN client can slowly but surely fall outside of the corporate security compliance configuration, because it's not exposed to Group Policy updates and your other management and control technologies. If enough time passes, the VPN client may fall so far out of compliance that it might end up being vulnerable to security incidents, and then those incidents could lead to a situation where, when the VPN client does connect to the corpnet, it might end up creating a security event on your network.
This is where the beauty of UAG DirectAccess comes in. Sure, there is all the cool stuff related to seamless access for your end users, but there is one key feature that makes DirectAccess the killer security technology - it fills the security compliance gap by being always on, even if the user is not logged on. Because the DirectAccess client connection is always on, the DirectAccess client is always connected to your management, configuration, command and control systems. The UAG DirectAccess is always managed, always up to date, and always under your administrative control, so that if an emergency update needs to be pushed out now, you can do that. That is not something you can do with remote access VPN clients.
In fact, the UAG DirectAccess client redefines the de facto level of security for all your clients. The concept of the corpnet client versus the DirectAccess client is gone. The DirectAccess client is always logically on the corpnet, and is always managed, always up to date, and always configured according to corporate security compliance standards. Put that on top of all the other security technologies mentioned in the bullet list above, and it’s clear that the DirectAccess client can easily be seen as more secure than those "bolted-in" corpnet clients back in the 1990s.
What do you think? Will DirectAccess redefine security for networks in the next decade? Does the concept of corpnet client versus remote access client have any meaning anymore? And how hard will it be to decommission the network guys away from the responsibility for making network security decisions and have them do what they're good at, instead of driving network security policy based on concepts of Microsoft security as it stood in 1994?
See you next month!
=======================
Quote of the Month - "Two nice cats are too nice" - Anonymous.
=======================
2. ISA Server 2006 Migration Guide - Order Today!
--------------------------------------------------------------
Dr. Tom Shinder's best selling books on ISA Server 2000 and 2004 were the "ISA
Firewall Bibles" for thousands of ISA Firewall administrators. Dr. Tom and his
illustrious team of ISA Firewall experts now present to you , ISA Server 2006
Migration Guide
<http://www.amazon.com/exec/obidos/ASIN/1597491993/isaserver1-20/>. This book
leverages the over two years of experience Tom and his team of ISA Firewall
experts have had with ISA 2006, from beta to RTM and all the versions and builds
in between. They've logged literally 1000's of flight hours with ISA 2006 and
they have shared the Good, the Great, the Bad and the Ugly of ISA 2006 with
their no holds barred coverage of Microsoft's state of the art stateful packet
and application layer inspection firewall.
Order your copy of ISA Server 2006 Migration Guide
<http://www.amazon.com/exec/obidos/ASIN/1597491993/isaserver1-20/>. You'll be
glad you did.
3. ISAserver.org Learning Zone Articles of Interest
--------------------------------------------------------------
* TMG Enterprise Arrays Explained
<http://www.isaserver.org/tutorials/TMG-Enterprise-Arrays-Explained.html>
* Microsoft Forefront TMG – Webserver Load Balancing
<http://www.isaserver.org/tutorials/Microsoft-Forefront-TMG-Webserver-Load-Balancing.html>
* Installing and Configuring the Email Hygiene Solution on the TMG 2010 Firewall - Part 4: Configuring Virus and Content Filtering
<http://www.isaserver.org/tutorials/Installing-Configuring-Email-Hygiene-Solution-TMG-2010-Firewall-Part4.html>
* Microsoft Forefront TMG - How to use TMG network templates
<http://www.isaserver.org/tutorials/Microsoft-Forefront-TMG-How-use-TMG-network-templates.html>
* Logging Enhancements in Microsoft Forefront Threat Management Gateway (TMG) 2010
<http://www.isaserver.org/articles/Logging-Enhancement-Microsoft-Forefront-Threat-Management-Gateway-TMG-2010.html>
* Checking Out the TMG 2010 Virtual Private Network Server - Part 1: Overview of VPN Configuration
<http://www.isaserver.org/tutorials/Checking-Out-TMG-2010-Virtual-Private-Network-Server-Part1.html>
* Microsoft Forefront TMG - Role based Administration
<http://www.isaserver.org/tutorials/Microsoft-Forefront-TMG-Role-based-Administration.html>
* Checking Out the TMG 2010 Virtual Private Network Server - Part 2: Configuring the TMG Firewall as a PPTP Remote Access VPN Server
<http://www.isaserver.org/tutorials/Checking-Out-TMG-2010-Virtual-Private-Network-Server-Part2.html>
4. ISA/TMG/UAG Content of the Month
---------------------------------------------------------------
Today I am happy to announce a very important accomplishment for my family. As you might know, back in December Tom took a full-time position with Microsoft as a technical writer and "knowledge engineer". It was a big move for him, as he had to leave all his other writing assignments that he has built up over the last 15 years. But he is really happy with the work he's doing and he wanted me to tell you that his first major effort to hit TechNet was published last month. It’s an update to the UAG DirectAccess Test Lab Guide. In this version of the UAG DirectAccess Test Lab Guide, Tom added key information about how to create a UAG DirectAccess Array, how to configure NLB for the UAG DirectAccess array, how to test the UAG NAT64/DNS64 feature, and also included lots of troubleshooting and validation procedures. Tom hopes that you'll see the new Test Lab Guide not only as a lab exercise, but as a learning exercise and that you'll be able to take away new insights into how DirectAccess works after completely the lab.
Check out the new UAG DirectAccess Test Lab Guide over at:
<http://technet.microsoft.com/en-us/library/ee861167.aspx>
5. Tip of the Month
--------------------------------------------------------------
Update 1 (UP1) for UAG was released last week! OK, there wasn't a lot of hoopla, but it's still a big deal and a significant milestone for UAG. What do you get with Update 1?
* Remote Desktop access from Vista and Windows XP (before this, only Windows 7 worked, which was annoying for all those organizations that are still using older versions of Windows)
* New support for SharePoint 2010
* New support for MSOFBA. What is MSOFBA? I had never heard of it; have you? Apparently, this is some sort of Office Forms Based Authentication. If you want to know more about this, check out this link. http://technet.microsoft.com/en-us/library/dd903064.aspx
* Support for site cookies, which is helpful when publishing sites that do not support Alternate Access Mappings
* Support for large CustomUpdate files – up to 1.5GB!
* Fix for the GPO provisioning for DirectAccess client – this fixes a bad problem that could have cratered your entire fleet if it hit you at the wrong time. No problem now that it's fixed!
Download Update 1 over here! http://www.microsoft.com/downloads/details.aspx?FamilyID=A862C57F-5C27-4CD0-8528-91B3CC5CD758&displaylang=en&displaylang=en
6. ISA/TMG/IAG/UAG Links of the Month
--------------------------------------------------------------
* Threat Management Gateway (TMG) Fundamentals for Forefront UAG Administrators
<http://blog.msedge.org.uk/2010/04/threat-management-gateway-tmg.html>
* Recommended Network Card Configuration for Forefront UAG Servers
<http://blog.msedge.org.uk/2010/04/recommended-network-card-configuration_14.html>
* Configuring Syslog on ISA and TMG with Splunk Log Management
<http://tmgblog.richardhicks.com/2010/04/04/configuring-syslog-on-isa-and-tmg-with-splunk-log-management/>
* Migrating from ISA Server to Forefront Threat Management Gateway
<http://tmgblog.richardhicks.com/2010/03/20/migrating-from-isa-to-tmg/>
* Using the Windows Command-line FTP Client with Forefront Threat Management Gateway (TMG) 2010
<http://tmgblog.richardhicks.com/2010/03/18/using-the-windows-command-line-ftp-
client-with-forefront-threat-management-gateway-tmg-2010/>
* The TMG Firewall Best Practices Analyzer
<http://www.microsoft.com/downloads/details.aspx?FamilyID=8aa01cb0-da96-46d9-a50a-b245e47e6b8b&displaylang=en>
7. Blog Posts
--------------------------------------------------------------
Hardening the UAG Server
http://blogs.isaserver.org/shinder/2010/04/22/hardening-the-uag-server/
TMG Firewall Fundamentals for Forefront UAG Administrators
http://blogs.isaserver.org/shinder/2010/04/20/tmg-firewall-fundamentals-for-forefront-uag-administrators/
What is Native IPv6, IPv6 Capable and IPv4 Only?
http://blogs.isaserver.org/shinder/2010/04/20/what-is-native-ipv6-ipv6-capable-and-ipv4-only/
DirectAccess Client Location Awareness - NRPT Name Resolution
http://blogs.isaserver.org/shinder/2010/04/16/directaccess-client-location-awareness-nrpt-name-resolution/
When Good Network Location Servers Go Bad - Preparing for NLS Failure
http://blogs.isaserver.org/shinder/2010/04/16/when-good-network-location-servers-go-bad-preparing-for-nls-failure/
Beginners Guide to Troubleshooting UAG DirectAccess
http://blogs.isaserver.org/shinder/2010/04/12/beginners-guide-to-troubleshooting-uag-directaccess/
Great New Documentation on Troubleshooting TMG Firewall Web Access Protection
http://blogs.isaserver.org/shinder/2010/04/12/great-new-documentation-on-troubleshooting-tmg-firewall-web-access-protection/
ISA 2006 Enterprise Installation Fails with an ADAM Error
http://blogs.isaserver.org/shinder/2010/04/12/isa-2006-enterprise-installation-fails-with-an-adam-error/
Microsoft DirectAccess Connectivity Assistant
http://blogs.isaserver.org/shinder/2010/04/02/microsoft-directaccess-connectivity-assistant-2/
Migrating from ISA to TMG Firewalls
http://blogs.isaserver.org/shinder/2010/04/02/migrating-from-isa-to-tmg-firewalls/
8. Ask Sgt Deb
--------------------------------------------------------------
* QUESTION:
Hi Deb,
I have been reading about the TMG firewall's Network Inspection System and I am pretty impressed at the level of security it can provide my primarily Microsoft network. Seems like NIS can protect us from exploits against Microsoft systems faster and earlier than any other firewall on the market today. That is pretty cool, but we already have another firewall in place. I am wondering whether there is a way to leverage the NIS database and engine and apply it to my existing firewall or proxy system.
Thanks! - Benny.
* ANSWER:
Hi Benny,
That is a good question. First, for those of you who do not know about the NIS, you can find excellent information about it in the NIS whitepaper here http://download.microsoft.com/download/F/4/0/F40887FD-648B-40E1-B79B-AAE43CEDCA4C/NIS%20in%20TMG%20Whitepaper.docx. NIS is designed to help protect you against those nasty zero day exploits that are so problematic for non-TMG firewalls. But that’s the point of using the TMG as your outbound access firewall - to get the benefits of the TMG firewall's entire protection suite. For this reason, you need to make sure that the TMG firewall is an inline device.
Does that mean you need to replace your current firewall? Of course not. TMG firewalls are not about "rip and replace." TMG firewalls are about protection. Go ahead and leave your current firewall in place, but make sure that the TMG firewall is an inline firewall for all outbound access. You can leverage the Web proxy client and Firewall client (TMG client) configuration to help get around routing issues, so that you do not need to make your client systems use the TMG firewall as their default gateway and you do not need to configure your network so that the TMG firewall is the route of last resort for your network. That is the beauty of the web proxy and Firewall client (TMG client) configurations - take advantage of them!
* QUESTION:
Hi Deb,
I need to know something about how to handle a problem with my boss. We have an ISA 2006 server right now and we use it to publish OWA, SharePoint, CRM and some other Microsoft applications and non-Microsoft applications. It works great for us, we understand how it works, and it's been rock stable. We want to move ahead with an upgrade to TMG to take over the duties of the old ISA firewall for publishing. However, my boss has been to some meetings recently and he is getting the message that you shouldn’t use TMG for publishing, and that if we do not want to end up in a dead end technology (in terms of publishing) we need to move away from ISA and TMG and go to UAG. Is that true? UAG looks very hard to configure and we are really not interested in portals, which it looks like you need to do with UAG. Why can't we just use TMG for publishing? Also, what about outbound web proxy? How do we configure UAG to do that?
Thanks! - Jerzod.
* ANSWER:
Hi Jerzod,
I have been hearing a lot of the same thing recently, and from the information I have, your boss is right. The future of application publishing is UAG, and there is no way around that. He is right when he says that TMG is a dead end technology as a publishing solution. If you look at the changes in publishing between ISA 2006 and TMG, during the four year interim that they worked on TMG, they included nothing new in terms of publishing capabilities. It's been made pretty clear that TMG is for outbound access control and protection only.
What this means to you is that the best thing to do is to get on board with UAG. While it seems at first blush to be more difficult to publish things with UAG, you will find that the learning curve is actually flatter than it seems. Also, while it might appear that you need to publish everything through a portal, that is actually not true. If you do not want to use a portal for access, you do not have to. You can make the end user experience the same as the user had with ISA or TMG. And if you don’t want the endpoint protection capabilities, you don't have to use those either. The major drawback to this situation is that UAG is quite a bit more expensive than TMG. I don't know if this will change in the future. But if cost is an issue for you, then you can go ahead and use TMG for publishing now and hope that the cost structure of UAG changes over time.
Do you have any questions or ideas for content? Email me on dshinder@isaserver.org.
Till next month!
TechGenix Sites
--------------------------------------------------------------
MSExchange.org <http://www.msexchange.org/>
WindowSecurity.com <http://www.windowsecurity.com/>
WindowsNetworking.com <http://www.windowsnetworking.com/>
VirtualizationAdmin.com <http://www.virtualizationadmin.com/>
--
Visit the Subscription Management <http://www.techgenix.com/newsletter/>
section to unsubscribe.
ISAserver.org is in no way affiliated with Microsoft Corp.
http://www.techgenix.com/advert/index.htm for sponsorship
information or contact us at advertising@isaserver.org
Copyright c ISAserver.org 2010. All rights reserved.
Hey that's a informative blog about networking.
ReplyDelete