Ten Practical Security Steps
Security Updates

9. Apply security updates to your systems. In view of the major Microsoft Windows NT, 2000 and IIS compromises during the summer of 2001, this page has been updated accordingly.

From my introduction, you may have thought that I don't think stable systems should ever be changed; this is not so. My position has been that it's a mistake to apply many small changes as soon as they are announced but unfortunately networked computers do need to be upgraded, so they are not vulnerable to a constantly growing list of attacks.

When and how to do this will vary with the vendor and your own situation. Previously I stated "Vendors such as Microsoft, release periodic service packs in addition to numerous hot fixes. The simplest approach is to watch for service pack releases, then read the trade press for several weeks and if it's clear the new service pack is a stable one, get it." When I originally wrote this, I thought it was sufficient to follow the computer trade press but not necessary to subscribe to any security mailing lists. Recent events have changed this view.

Late July 19, 2001, The Carnegy Mellon CERT Coordination Center released an advisory stating "reports indicate that the "Code Red" worm may have already affected as many as 225,000 hosts, and continues to spread rapidly." Over the next few months, estimates reached 700,000 affected computers with clean up costs estimated at over 2 billion dollars. Affected hosts were NT 4 running IIS 4 and most versions of Windows 2000 running IIS 5.

The particular worm was benign compared to what it could have been. It defaced web pages of affected English language sites, engaged in some DDoS attacks and spread itself to other vulnerable computers. Because the Index Server buffer overflow that allowed the compromise, ran in the system context and allowed the execution of arbitrary code, a similar worm that provided remote administrative control could have been written.

The scope of this attack was such that my firewall showed 275 attempts to contact port 80 on my machines not running web servers during July 19, apparently from infected servers. My Linux and OpenBSD web error logs showed several dozen attempted infections. My NT server had already been patched so it was unaffected but error logging was broken on that server so I have no way of knowing how many attempts it received. Had my NT site not already been patched when the Code Red Worm reached it's peak, firewall logs and logs from the other systems suggest it would have been compromised many times. Because this vulnerability is exploited via HTTP (port 80), a public web server cannot be protected by a firewall. This exploit closely followed others that have allowed significant numbers of Windows NT and 2000 machines to be compromised and others followed.

On Sept 17, 2001, an new worm, Nimda, was released that left open doors to the affected system allowing anyone who knew of the compromised system to gain administrative access. I never understood why Nimda got much less press coverage than the Code Red variants because I saw (and others I spoke to) saw much more activity. At its peak soon after it was released I saw about 20,000 probes a day from several dozen infected machines. Gradually the activity tapered off but three months latter I still typically see several dozen probes from a few infected systems most days.

The first "live" worm was released in 1988. E-mail spread viruses, that have worm like behaviour, became common a few years ago; generally spreading these requried some action on the recipients part. It wasn't until 2001 that worms targeted at infrastructure, exploiting traditional weaknesses such as buffer overflows and delivering malicious payloads that would continue spreading without any operator intervention actually appeared. Instead of owner assistance to trigger the spread, these now require owner intervention to stop the spread. In view of the scope of the compromises, the seriousness of them and their automated nature and rapid spread, I now believe that even time pressured system administrators need to be more proactive in dealing with potential security threats.

Administrators need to participate in at least one of three following security notice lists. First is the CERT list. To subscribe send an e-mail to majordomo@cert.org with a message body containing only "subscribe cert-advisory" (without the quotes). This will do little to protect your systems from internal threats but major external threats are listed and especially threats where a compromised system can subsequently be used to attack others. This is typically the lowest volume of the three lists.

If you are entirely a Microsoft shop and are only interested in Microsoft products and related security announcements send an e-mail to microsoft_security-subscribe-request@announce.microsoft.com. Subject and e-mail body content don't matter. This covers only Microsoft products but covers all that Microsoft regards as worth releasing separate patches for.

SANS Institute does a weekly security notification that covers key security related developments in all areas. Subscribe at http://www.sans.org/newsletters/.

I now believe it's necessary for all Internet connected organizations to follow at least one security oriented e-mail list. Based on the reports, each administrator will need to decide if a potential risk is worth acting on. If your systems are vulnerable to a rapidly spreading worm, or any attack in which your systems may become a launching point for attacks on other systems, then you have little choice but to patch your systems as quickly as possible. This requires monitoring at least one of the above lists, or others more specific to your environment. Once the time is spent to monitor current security threats, you can gauge each threat, whether it's relevant to your environment and if so the degree of threat.

Another situation demands rapid action. If you are part of an organization with similar computers and any have been compromised then all need to patched as quickly as possible or patched and repaired if they have already been compromised.

If you are part of the audience these pages are intended for, typical small businesses and associations, don't ever do anything that brings you to the attention of the of potential intruders or all bets are off as even obscure exploits are more likely to be used against your site. Regardless of the size or sophistication of your site, if you have a prominent and controversial political or social agenda, actively attack crackers or denigrate their skills, are a site that deals heavily with security issues or makes a claim that your site is secure, attacks on your site become much more likely. Unlike random scans where your IP range just happens to be in range that someone is scanning, these attacks will start with your web site and target network of which it is part.

If you are following this advice, you're on one or perhaps more security mailing lists and aware of threats to your systems. As maintaining this awareness is a significant part of the time required to deal with these vulnerabilities, it makes sense to patch them when they become known.

In dealing with vulnerabilities that are believed to threaten your systems only, I still believe it's prudent to weigh the likelihood of an intrusion against the possibility that a patch itself may cause system problems. When a new security vulnerability is found, there are likely to be many, possibly millions, of vulnerable machines connected to the Internet. The port scans mentioned in intrusion detection (8), can automatically find some of these systems but not all due to the large number of IP addresses to be searched and the time scanning takes. The more aggressive the scanning, the greater the change of hitting a system that detects and reports the scan to the originating ISP. I would patch only systems actually vulnerable to attack and most likely start with the less important of such machines.

After dealing with worms, distributed denial of service threats, already compromised systems and vulnerable public services, there are likely to be a variety of lesser threats that some or many of your systems, including inside (LAN) systems, may actually or theoretically be vulnerable to. Examples include actively running, vulnerable services protected by a firewall, vulnerable services installed but not running, threats that require physical access to the machine, etc. Rather than dealing with these individually, I think it makes sense to wait for stable service packs or operating system upgrades if these come regularly like OpenBSD and that trying to deal with such issues individually is likely to cause as much trouble as the problems that are supposedly being fixed.

For situations where a cautions approach is appropriate, if you're fortunate enough to have test machines similar to production ones, then start with them. Otherwise, start with your less important machines. After the install, use all the interactive programs that are typically used on the machine. Don't just open and close them but perform some standard operations. Allow a few days between installs to allow backups and other scheduled processes to run and watch for any anomalies. Move on to other machines allowing the number you have and the degree of similarity (as well as your workload) to set your upgrade pace. Save the most critical for last; hopeful any problems will have shown themselves by then.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.