Ten Practical Security Steps
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 email@example.com 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
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
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
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
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 -
Copyright © 2000 - 2014 by George Shaffer. This material may be
distributed only subject to the terms and conditions set forth in
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