Server and Domain Isolation vs NAC

When discussing network access control (NAC) products with customers, we usually define two clear goals. Firstly, ensure that all devices accessing the network are compliant with a set of policies defined by the administrator – and secondly, ensure that any unknown devices are prevented from communicating with those that are known.

Assessing known machines is usually relatively straight forward. We can use installed or web-based agents to ensure that these machines comply with our standards (are patched, have Anti-Virus etc), but how do we isolate other devices?

DHCP enforcement is great, and does a very good job of preventing the majority of unauthorised devices from obtaining an IP address. This is mainly because most unauthorised access is not malicious, and in fact is more likely to be a staff member/contractor/visitor innocently connecting to your network, and generally they’ll be configured to use DHCP.

The obvious problem with DHCP enforcement is that we’re assuming that all devices will request an IP address from our corporate DHCP server. So what if they don’t?

802.1x enforcement is one potential answer, and is a very effective way of protecting your network from unknown devices. There are a few complications with 802.1x though, which can often make administrators reluctant to go down this road. Obviously all switches must support the technology in the first place, and even when they do will need to be configured. This can seem quite daunting, especially to smaller businesses, and it’s often the case that 802.1x enforcement is placed on the “to do list”. Another way of dealing with this issue is to implement “Server and Domain Isolation” (SDI).

SDI is the term Microsoft use to describe the use of IPSec policies deployed via Active Directory. By assigning IPSec policies to your domain, you can create a barrier between members of your domain and all other devices.

When two devices on your domain wish to communicate, they first authenticate and all packets transferred between them are encrypted. When a non-domain member tries to initiate communication with domain members, the authentication fails and your domain member is protected. IPSec policies can be flexible enough to allow unsecured connections where necessary, and define different requirements for different network segments and devices.

I should stress, SDI is not a new technology and is not a security silver bullet. SDI provides a logical barrier between your trusted network and everything else, but of course it’s just as important to ensure that devices on the trusted network comply with the relevant security policies. This is where endpoint assessment comes into its own, and why combining technologies like SDI with NAC can be an incredibly efficient way of securing your network.

Microsoft have a few interesting whitepapers explaining SDI in more detail, which I’ve linked to below. For anyone interested in playing with SDI, Microsoft have also provided an excellent downloadable demo environment which I strongly recommend taking a look at.

As always, Microsoft themselves have demonstrated their total confidence in a solution by implementing it on their own network. They’ve also provided a comprehensive explanation of how they deployed SDI, which is well worth a read: http://technet.microsoft.com/en-us/library/bb735174.aspx

The video demo below is a brief demo of SDI in action. Initially SDI is not enabled, and a packet capture with Wireshark clearly shows clear text packets. Once SDI is enabled, IPSec policies encrypt all packets and the Wireshark capture shows only ESP (Encapsulating Security Payload) packets.


http://www.youtube.com/watch?v=nXhfEaUPZSI

Server Isolation Explained: Click
Domain Isolation Explained: Click
Demo Environment: Click

If you'd like to discuss SDI with us please leave a comment or get in touch via the normal routes (http://www.foursys.co.uk/)

Patch Assessment with NAC

The recent outbreak of the Conficker worm has certainly kept our support department busy. Although the vulnerability was patched (MS08-067) by Microsoft on 23 October 2008, reports seem to suggest that in late January 2009 around 30% of systems remained unpatched.

By claiming a number of high profile victims such as the UK Ministry of Defence and hospitals in Sheffield (http://www.theregister.co.uk/2009/01/20/sheffield_conficker) it seems clear that as things stand, virus writers will continue to exploit one of the biggest problems faced by those responsible for security – patching.

Patch management systems, be it WSUS or another commercially available solution, are only effective when they’re working. If a patch hasn’t been approved and deployed, or fails to deploy on even a small number of systems, an entire network can become vulnerable.

Experience from the field shows us that even when a company invests significant funds in patching, there’s no guarantee that it will be effective. There are so many potential points of failure, ranging from failed client installs and inaccurate reporting, to GPO’s not being applied.

Installing a solution to proactively and independently assess for patches is a good way of keeping on top of this problem. It ensures that required patches are installed successfully, and prevents a system from accessing the network if not. Such products also help to ensure maximum ROI on patch management systems, and the resources used to manage and maintain them.

Network Access Control (NAC) solutions are typically thought of as being purely concerned with preventing unknown systems from accessing your network, and that’s to be expected given the name used. Increasingly though, NAC products not only control who can access the network, but perhaps more importantly ensure that the systems you already know about and manage remain secure.

Conficker also emphasises the need to use strong passwords, as it spreads itself via network shares protected with weak passwords. Sophos recently posted a list of the passwords used by conficker when trying to infect these shares (http://www.sophos.com/blogs/gc/g/2009/01/16/passwords-conficker-worm), and they’re all pretty appalling – but clearly commonly used. This highlights the fact that even having one vulnerable system on the network is going to cause your administrators a headache.

So, to effectively protect your environment from threats such as conficker, there are several important aspects to consider. All systems must receive critical patches, Anti-Virus must always be enabled and current, and any system that does not meet these requirements must be prevented from accessing the network until compliant. Combine this with regular vulnerability assessments of your infrastructure, and you stand a fighting chance.

The videos below show how we’ve been using Sophos NAC Advanced to help with this. The first video shows an administrator creating a NAC policy that requires the relevant patch (MS08-067) to be installed on a system. The second shows what happens if the patch is missing, and how the system is prevented from accessing the network until it complies.


http://www.youtube.com/watch?v=B7qE_7xaI58




http://www.youtube.com/watch?v=tf3xzNX1nSw

NAC Agent Quarantine Demo

One of the great things about Sophos NAC's installed agent is its ability to continually assess the endpoint post-admission. If a compliant machine's posture changes, the NAC agent detects this and places the endpoint into quarantine.

So, if your Anti-Virus application becomes inactive, or another critical service fails, NAC will place the endpoint in quarantine and alert the user or administrator. The end user can be given instructions to call IT Support or for fixing the problem, whilst ensuring that if the endpoint has been compromised it is unable to spread the infection to other computers.

The below clip shows a PC becoming non-compliant with a Sophos NAC Advanced policy. When the Anti-Virus application becomes inactive, the Sophos NAC agent places the PC into quarantine and restricts its network access.




http://www.youtube.com/watch?v=g3PFur0lxW8