Happy April Fools!

If you believe what you read in the press, then you may be surprised to learn that even after all the hype surrounding the Conficker worm, the UK Houses of Parliament are today reported to have been infected.

Allegedly computers used by MP’s have been affected, and according to Chanel 4 News, staff have since been told not to use unauthorised computers on the network, implying that previously this was deemed acceptable.

The Houses of Parliament have opted not to comment on this incident, but C4 claim to have seen an email sent to MP’s outlining the above.

It’s almost beyond belief that three months after Microsoft patched the exploit, and after all of the column inches devoted to Conficker, such a high profile institution could be caught out in such a way. Assuming all is as reported, it’s shocking that unknown computers are allowed to access the network, especially given that the managed computers seem to have been unpatched and quite possibly not running up-to-date AV. I’m not convinced that this one can be pinned on the credit crunch!

The bad news for those still infected is that Conficker is due to attempt a “call home” on 1st April, although many within the industry are speculating as to what the outcome will actually be. The payload may not necessarily be downloaded on April 1st; the infected computers will simply attempt to contact one of the thousands of call home domains. If the domains aren’t registered for a few days or weeks, nothing will happen. Even then, the payload may not necessarily execute immediately.

If you’re still in the unfortunate position of trying to clean-up after Conficker, then next week may be a little nerve-racking. One way of minimising the impact of any potential payload is to make sure your computers can’t contact those call home servers to download it in the first place.

Microsoft ISA users are fortunately able to download and run a VB script that will configure ISA to block outbound requests for Conficker, although a quick Google search for a few other firewall vendors didn’t reveal any similar tools. If your AV vendor bundles a client firewall, then now could be a good time to make the most of it. At the very least, it could help prevent re-infection while your administrators chase Conficker around the network.

And of course, you can always call our support department if you need some friendly advice.

ISA Conficker Script:
http://blogs.technet.com/yuridiogenes/archive/2009/01/01/blocking-conficker-through-isa-server-tmg.aspx

Conficker Removal Tool (from Sophos, free but requires registration):
http://www.sophos.com/products/free-tools/conficker-removal-tool.html

Lessons Learned

It’s not especially controversial to say that if you don’t implement an effective patch management strategy, and ensure your endpoints run up-to-date and enabled Antivirus, you’re sitting on a network security incident time bomb.

We all know and understand this, yet the IT press reports high profile incidents on an almost daily basis. A review of an outbreak that affected three major London hospitals in 2008 concluded that the infection by the “Mytob” worm was “entirely avoidable”.

The infection, which affected Barts and the London NHS trust, “rapidly infiltrated” the trust’s 4,700 PC network resulting in a “very small number” of non-urgent operations being rescheduled. It seems that the Trust reacted well to the outbreak, and that “patient safety was not compromised at any time”, and at no point was confidential patient information put at risk.

The root of the issue, it would seem, was that although the Antivirus software was regularly updated, the updates did not reach all PCs. Additionally the software was found to be incorrectly configured on some PCs, leaving a “back door for the virus to infiltrate the network”. The source of the virus was not made entirely clear, but it was said to have been “introduced accidentally” and without malicious intent.

The fact the incident was well handled by the Trust, and that at no point was the well-being or confidentiality of patients put at risk, reflects positively on the IT personnel involved in responding to the incident. The report highlighted the fact that the trust had “well-rehearsed emergency procedures” in place, and ensured that key clinical systems continued to function.

What can we learn from this? Firstly, don’t rely on a reactive approach to systems such as Antivirus and patching. A daily manual check of the Antivirus server’s console isn’t good enough anymore, instead we need to restrict a devices network access the moment it has an issue.

Secondly, as highlighted by the above report, having a procedure in place for responding to incidents is critical. Instead of wasting crucial time planning how to react, the London NHS was able to respond immediately and ensure the continued smooth running of their organisation.

The report is available via the Barts and the London NHS Trust website (bartsandthelondon.nhs.uk)

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

NAC Advanced v3.0.5 Released

NAC Advanced Version 3.0.5 was recently released, but what has changed and who needs to update?

Version 3.0.5 is a "maintenance" release, and in the main resolves several known issues/bugs from previous versions. Probably the most relevant of the bugs resolved is the client install failure experienced on Windows Vista SP1 computers. We're pleased to say we have tested this on our own computers and the issue is indeed resolved.

As well as fixing this and several other bugs, 3.0.5 brings us:
- SQL Server 2005 support
- SQL Server 2005 express support
- Updates to and additional security applications and service packs

As usual, the upgrade process is documented and relatively straight forward. The required backups must be taken before the upgrade, to allow rollback should there be any issues. We've so far upgraded a number of customers as well as our own system, and have experienced no significant problems.

There's no need to jump straight into the upgrade, as it does not contain critical fixes - so this allows plenty of time to create the required backups and ensure a smooth transition to 3.0.5.

If you're a Foursys customer and would like to discuss the upgrade in any detail, please feel free to get in touch with us via the normal routes.

Full release notes are available via Sophos @ http://downloads.sophos.com/readmes/sophos-readnacadv_304_eng.html

Welcome

Hello, welcome and thank you for reading.

The Foursys Network Security blog is intended to be a resource for all, Foursys customers or otherwise, with an interest in network security.

Foursys is a specialist in security solutions, with over 15 year’s experience. This blog is not intended to be used as a glorified sales pitch, but instead is a way for us to share news and updates with you.

Our network access and security team is primarily concerned with a small number of technologies.
- Network Access Control (Sophos NAC, Microsoft NAP)
- Server and Domain Isolation
- Security Assessments (Vulnerability Assessments, Healthchecks)
- Data loss prevention

We'll be posting regular updates covering subjects such as product upgrades, new developments and interesting stories from the field.

As well as this we’ll be providing lots of chances for you to get involved and leave feedback, comments and suggestions.

Check back soon or subscribe to our RSS feed.