UCS Toolkit - Windows Patching and Security

MSSG | UCS Toolkit |

WINDOWS PATCHING AND SECURITY

Windows is a popular operating system on campus but sometimes poses some specific administrative challenges. This section identifies some of the more important ones for system administrators to focus on.

For more information and some specific and step-by-step instructions, see also MSSG's recommendations.

Security

A great deal of the Rutgers IP space is directly on the internet. Though the University perimeter is protected by a firewall, the academic culture of openness at Rutgers tends to foster filtering policies that are relatively unrestrictive. In addition, the internal network is sufficiently porous (with unmanaged student and faculty machines connecting and disconnecting all the time) that administrative caution and a focus on security are imperative.

Stay patched Patching your systems in a timely manner is probably the most important thing you can do to maintain secure, stable machines. This is true for any operating system, but Windows' pervasiveness makes it a prime target for abuse.

Fortunately, modern Windows OS's make this easy by providing a built-in mechanism for automatically installing critical patches: the Automatic Updates service. At the very least, you should configure your machine to notify you when there are critical patches available and make sure these patches make it to the machines you manage. However, wherever possible, it is recommended that machines be configured to automatically download and install patches and reboot immediately if necessary. (Tip: 12pm-1pm may be an ideal time to schedule automatic updates to occur since machines are likely to be online but not in use.) For instructions on how to manually configure the Windows Automatic Update service, you may refer to MSSG's documentation. To automate the process, you may use Active Directory group policy (if your machines are part of a Windows domain) or possibly script it. If you wish to have complete control over which updates are applied and when, running your own Software Updates server in conjuction with Automatic Updates is also a possibility.

Remember that computers are especially vulnerable while they are being set up for the first time. If you are not installing from a fully patched set of source files (like a Windows XP distribution folder with the latest service pack and hotfixes slipstreamed in), you need to take extra care that the machine is not compromised before setup is complete and all patches applied. In this scenario, you have a few options:

Build offline, install and/or enable a host-based firewall, and then patch.
Connect the machine to the network via a NAT device (like a personal linksys router) or to a similarly restricted network while building and patching.
Take steps ahead of time to be sure the built-in Windows Firewall will be enabled during the build/patching process: e.g., for WinXP machines, integrate XP SP2 into your source directory so that the firewall is enabled by default. This is probably the easiest method but requires that you install machines from the same source every time. (This is a good idea anyway for consistency reasons.)

Maintain updated antivirus software The extensive presence of viruses and worms on the internet makes antivirus software an absolute necessity. Every machine connecting to the University network should therefore be running updated antivirus software.

Fortunately, the University has a site license for McAfee antivirus software. Since this software is "available for free use by Rutgers faculty, staff, and students," it is easy to meet this requirement. Please see the University Software Portal for licensing details, download options, and configuration information.

The University also offers a customized McAfee option nicknamed RADS: the Rutgers Antivirus Delivery System. This package takes all the guesswork out of antivirus protection by automatically providing regular and emergency definition file deployments and scanning schedules. It is the preferred method of protection on campus.

Block unwanted traffic You can significantly reduce the surface area of attack on the workstations you manage by limiting the traffic they accept. There are several mechanisms for doing this. Host-based firewalls are a popular one, especially since the latest Windows operating systems have one built-in.

With the advent of Windows XP SP2, the Windows Firewall (WF) is enabled by default. However, if you want to selectively allow some traffic (e.g., you want to manage your machines using Microsoft file sharing, WMI, or the Microsoft Management Console), there are a variety of mechanisms for managing WF settings. Besides Group Policy, the netsh command line tool is available for a scripting approach, or you can set the appropriate registry settings via script. See the Sample Scripts page for some ideas or read Microsoft's documentation.

While the WF is a powerful tool, it has some limitations: it can not block outgoing traffic and offers no choice between the "block all except some" and "accept all except some" approaches to traffic filtering. If you desire more flexibility, or if you are still using Windows 2000 Professional, IPSec is another possibility. IPSec filters are not stateful (dynamic) but they allow for very flexible configurations and can control both incoming and outgoing traffic (useful, for instance, in slowing the spread of viruses or software that "phones home"). IPSec policies can be managed via Group Policy or by using the ipseccmd.exe command line tool from the XP Support Tools. (Windows 2000's corresponding tool is ipsecpol.exe.) The Sample Scripts page also has some ipseccmd.exe syntax examples. Note that IPSec and WF are not mutually exclusive: they can be used to complement each other.

What if you are using a version of Windows that does not include IPSec filtering or a built-in firewall, or if you simply don't like these mechanisms? You'll have to use a third party utility like McAfee Desktop Firewall or Zone Alarm, both of which are available from the Software Portal. However, please note that the use of the latest operating systems is strongly recommended in most cases.

Some useful links:

Disable unnecessary services

Another simple but effective way to help protect your workstations is by turning off functionality you don't need. Disabling unnecessary services reduces the surface area of attack. Windows XP has over 75 services running on it by default. You can surely disable at least a handful of those to both boost performance and reduce the means through which the machine could be compromised.

A good starting point for deciding which services you can safely disable can be found here:

These services might be good first candidates for disabling: Alerter, ClipBook, Error Reporting Service, NetMeeting, Remote Desktop Sharing, Performance Logs and Alerts, Portable Media Serial Number, Portable Media Serial Number Service, QoS RSVP, Smart Card, Smart Card Helper, SSDP Discovery Service, System Restore Service, Telnet, Uninterruptible Power Supply, Universal Plug and Play Device Host. Refer to the sample scripts section for a script that disables these services.

Desktop Management A systematic approach to workstation configuration, deployment, and ongoing management is necessary to maintain an organized, controlled environment.

Standardize!

It is best to configure all of your machines to have a common settings base. That is, while each machine will undoubtedly be unique in some ways, there should be certain files and configurations that you can rely on being present to more easily manage the machine later.

Here are some examples of ways to approach standardization:

standard local administrative username and password (in non-domain environments especially) that do not change. It should be dedicated to system administration; users should NOT be allowed to use this account. Since the password will be the same on all your machines, users should NEVER be given the password since doing so would effectively give them access to all workstations in your environment.
standard set of utilities. For instance, certain resource kit utilities are very useful to include in your standard build. These are some good ones: ipseccmd.exe, linkd.exe, sleep.exe, soon.exe, windiff.exe (and supporting files), depends.exe (and supporting files), robocopy.exe. There are also some very handy free utilities on the web. Sysinternals offers quite a few. The pstools collection in particular is valuable from a system management point of view.
standard options. For instance, you might decide to disable Simple File Sharing on all your computers so that you can connect to the workstations' administrative shares (C$, etc.). (Of course, if you do this, you probably also want to set up some sort of IPSec policy to allow connections only from your administrative workstations.) You may also want to customize the Default User profile so that all users receive a common profile to start with, disable the same unecessary services on all the machines, ETCETERA. You must decide on the specifics; the idea is to be systematic in your implementation.
standard build process. For best results, build all your machines via the same mechanism: e.g., an "unattended" installation (good if your hardware is very diverse) or a machine "image" (efficient if your hardware is fairly homogeneous). For ideas, read the deploy.chm help in the DEPLOY.CAB file on the Windows XP cd. Though it may be tempting to use the OEM configurations that come pre-installed on new machines, you'll probably achieve greater control, consistency, and stability if you rebuild these with your standard mechanism.

Lock it down

If you support more than a handful of machines, you will probably want to build your machines so that non-system administrators can not modify criticial aspects of the configuration. This is especially true in lab environments. The only way to keep the machines stable is to prevent unauthorized changes from occuring. If you do not take steps to prevent ordinary users from randomly changing the configuration, you will likely find yourself in a reactive cycle of fixing problems rather than proactively designing better solutions.

Therefore, wherever possible you should "lock down" the machines and withhold administrative access from the people who ordinarily use the machines. For those environments where it is politically troublesome to restrict users' rights, you can invoke the "best practices" explanation for why it is necessary: e.g., besides limiting "accidental" damage, computing in a restricted security context limits the damage that viruses and other malware can do. It also promotes a more stable and therefore reliable computing environment.

Some recommenations for achieving and maintaining lock-down:

Use the NTFS filesystem. Besides being more stable than FAT32 on Windows XP, NTFS will give you the ability to set permissions on directories and files. Unless you wish to give everyone full control over every area of the filesystem, you will need to use NTFS and modify permissions appropriately. (See fixACLS.cmd on the Sample Scripts page for an example of how to automate permission-setting.) Some people fear that using NTFS will make data recovery more difficult in the case of hard drive failure. Given the wide array of tools and techniques that are now available (from Linux with NTFS support, to BartPE [see Special Tools below], to simply accessing the drive from another XP box), this is not an issue and should not deter you from leveraging the benefits of using NTFS.
Put accounts in the Users group. There is no way to leverage NTFS permissions if the users are part of the Administrators group anyway. To limit unwanted changes, ordinary users should be just that -- Users. Unfortunately, some applications assume the user has administrative rights and might therefore produce some error messages when run in a restricted context. However, using tools like Sysinternals' Filemon and Regmon, you can often pinpoint exactly where permissions need to be loosened without giving the users total control. While annoying and sometimes time consuming, these efforts will ultimately save you a lot of aggravation. If at all possible, also avoid putting accounts into the Power Users group. While doing so is often convenient technically and politically, Power User rights, though not quite "administrative," increase the number of things that can go wrong.

If you are not able to withhold administrative rights, you might still help maintain system stability by implementing various Group Policy settings. From a user's point of view, these are not easily modified (accidentally or otherwise) since they tend to override the more accessible graphical control panels. On XP Pro, try running gpedit.msc for some ideas.

Automate

It's a good idea to automate and/or centralize software installation and configuration changes wherever possible. While there is always some "development" involved, investing time in building automated solutions to common tasks will ultimately save time and hassle by promoting a more standardized environment. It will also help you keep agonizing repetition of tasks to a minumum and allow you to focus on being proactive in your approach to problems.

For instance, learn a scripting language like VBScript, JScript, or even just NT-style shell scripting, or use an installer product like InstallShield or InnoSetup (free) to create a customized set of changes that work without user intervention. Then deliver those "packages" to the machines with a professional management suite like ZENworks or SMS, or even more humble methods like the AT command line scheduler (at.exe), Task Scheduler (schtasks.exe), or WMI. See the Sample Scripts page for some examples.

Resources for System Administrators

There are many tools available for approaching the task of systems administration, far too many to completely document here. On the Windows Utilities page you'll find a list of some useful resources and information about where to learn more.