Windows Update Services slips into 2005

Posted on By Mark Wilson

Microsoft Windows Update Services (the successor to Software Update Services) looks to have slipped into 2005. In an e-mail sent from Microsoft to registered users for the Windows Update Services Open Evaluation Program, Microsoft state that:

“There are two primary drivers behind this schedule change:

  • The March release of the Windows Update Services closed beta has spurred overwhelming interest from customers and partners evaluating the product. We have assessed this input as part of the beta cycle, and are committed to incorporating the feedback before releasing the next beta release for the Windows Update Services Open Evaluation Program.
  • The Windows Update Services team is developing a new Automatic Updates agent which will be included in XPSP2. The new agent is used both to improve the updating experience for XPSP2 users connecting directly to Windows Update and for users who will leverage Windows Update Services in their corporate environments in the future.

This decision to include the new Automatic Updates technology in XPSP2, and perform the necessary integration and testing, also contributes to the development schedule for Windows Update Services being staggered behind the XPSP2 release.”

Another interesting note in the e-mail is that:

“The final production release of Windows Update Services will include a migration toolkit that will simplify the migration from Software Update Services (SUS) 1.0 with SP1 to Windows Update Services, so if you are holding off on implementing SUS because of concerns about migrating to Windows Update Services, we encourage you to go ahead and implement SUS 1.0 with SP1”.

For further information on Windows Update Services, including a Windows Update Services (Beta Version) datasheet, refer to the Windows Update Services area on the Microsoft website.

Preventing denial of service attacks on an ADSL router

Posted on By Mark Wilson

Since about April 2004, I’ve been having problems with my ADSL router at home (a Solwise SAR 110). As the hardware was just over 12 months old (and hence just out of warranty), the cynical side of me was resigned to the fact that it had just “broken”. Not wanting to lose my configuration settings through a firmware upgrade, I got used to resetting the router each day (sometimes several times a day) when it seemed to just drop off the network. Because I couldn’t access the box, I couldn’t check any logs and find out what was happening.

This all changed when I spotted a posting on my ISP’s support forum, directing me to Chris Marsh’s excellent SAR 110 and 130 Guide. Using Chris’ advice I have been able to stealth my router (as tested using the GRC Shields UP! port prober). The SAR Guide website also included interesting information on other configuration items that were not always clear from the Solwise manuals and help text.

Now that my router is no longer visible on the Internet, it seems to stay up as it did for the first year I was on ADSL (just under 13 days and counting as I write this). I can only assume that the problem was a denial of service (DoS) attack, that has now been prevented through the stealthing of the router.

Obviously, there are many types of router out there, but by following the same steps, it should be possible to stealth most ADSL routers, even if the user interface is slightly different.

Microsoft Scripting Host (Monad)

Posted on By Mark Wilson

A few weeks back I published a post about Microsoft’s plans to withdraw support for VBscript. One of my clients tipped me off a couple of days back with some more information about the new Microsoft Scripting Host (MSH) shell – codenamed Monad, which will be included in the Windows Server product codenamed Longhorn.

Windows and .NET Magazine reports that:

“Monad is a new administration scripting and automation solution for Longhorn. Although the technology is roughly 2 years away from being released, Monad appears to be Microsoft’s long-awaited comprehensive, consistent, and unified systems administration model designed from the ground up for Windows IT professionals…Monad will be the technology through which Microsoft and Independent Software Vendors (ISVs) will enable their Windows applications to be managed from the command line and automated using shell scripts.”

Why physical access to a PC is so useful for a hacker

Posted on By Mark Wilson

This week, I’ve been attending a (Microsoft-sponsored) training course, looking at Windows security. Now, what happens when you get a bunch of techies together in a room and talk about security? Exactly! We all start to think of ways around things. Like the classroom PCs with locked-down configurations…

…the guy sitting next to me (who will remain anonymous, as will the training provider) had a Winternals ERD Commander 2003 boot CD.

Using this, we were quickly able to reboot, launch the Locksmith utility and reset the administrator password to one of our choice, following which we had unrestricted access to the PC.

It was all just a bit of harmless fun within a classroom environment, but it goes to show why physical access is such an important part of a defence in depth strategy.

Problems with Microsoft clusters

Posted on By Mark Wilson

A few weeks back I was trying to configure a Windows 2000 cluster for a client. Nothing too unusual about that, but we still came across a couple of issues:

Firstly, the shared disk was on a SAN, with Veritas Volume Manager providing dynamic multi-path support. Veritas’ document describing how Volume Manager works with Microsoft Cluster Server suggests that once the Microsoft Cluster service is installed, it is possible to modify an existing Volume Manager installation to install the Volume Manager DLLs. We found that it is not enough for the Cluster service to be installed (i.e. present but without the Cluster Service Installation Wizard having been run) – the cluster has to be fully configured before the Volume Manager MSCS Support will install correctly;

The second issue was far more difficult to diagnose. We had a problem whereby the first cluster node would install without issue; however when we attempted to join the second node to the cluster it would fail and report the following message in %systemroot%\cluster.log:

[JOIN] Unable to get join version data from sponsor xxx.xxx.xxx.xxx using NTLM package, status 5.

The problem turned out to be related to the password length for the Cluster service account. When you set or change a password, Windows generates both a LAN Manager Hash (LM hash) and a Microsoft Windows NT hash (NT hash) of the password. These hashes are stored in the local Security Accounts Manager (SAM) database or in Active Directory; however LM hashes are relatively weak and are often disabled for security reasons, as described in Microsoft Knowledge Base article 299656.

Our Active Directory was running under Windows Server 2003 (albeit in Windows 2000 mixed mode), and because Windows Server 2003 is more secure by default, it does not store LM hash values for passwords.

According to Microsoft Knowledge Base article 272129, all cluster authentication is handled internally to the Cluster service. The only time the Cluster service contacts a domain controller for authentication is to validate the Cluster service account when the cluster is first formed. Every node that requests to join a cluster is validated using RPC communication over the private network by the node that owns the quorum resource. Only LM or NTLM authentication is used for this (i.e. not NTLM v2 or Kerberos).

According to Microsoft Knowledge Base article 828861, if a password of less than 15 characters is used for the Cluster service account, the setup process generates an LM hash to build a session key to authenticate whilst attempting to join the second node to the cluster. Because no LM hash is stored in Active Directory, the domain controller cannot build a matching session key and access is denied; however, when a password that has 15 or more characters is used for the cluster service account, the setup process cannot generate an LM hash and a Windows NT password hash is used to derive the session key instead. The domain controller is able to generate a matching session key and authentication succeeds.

The result of all this is that the Cluster service account must use a password that contains 15 characters or greater.

Incidentally, there is a really useful best practice guide for installing the Microsoft Cluster service on the Microsoft website. Microsoft Knowledge Base article 278007 describes some of the new features in Windows Server 2003 clusters in comparison with Microsoft Windows 2000 Advanced Server and Microsoft Windows 2000 Datacenter Server.

Clustered SQL Server dos, don’ts and basic warnings

Posted on By Mark Wilson

I don’t know much about SQL, but I recently worked with a colleague in to produce a standardised SQL Server 2000 installation (clustered and standalone) for a client and came across some Microsoft advice which gives dos, don’ts and basic warnings for clustered SQL Server installations.

The article is basically a roll-up of information regarding running SQL on a Microsoft cluster for versions 6.5, 7.0 and 2000.