Timothy
Parker Consulting Incorporated
|
|
|
|
Buttoning
Up Your System Windows
NT is known for its good security, and despite the odd fuss over holes
discovered through some obscure access method or utility, on the whole Windows
NT has an excellent security record. The
problem with security is that it is only as good as the weakest link, which,
unfortunately, are usually the users. Keeping tight tabs on administrative security issues is
important, but encouraging your users to keep security in mind when they work
and set permissions on their files is also vital. There
are several components to a good security installation.
These include, in no particular order, the physical security of the
system, software security, and user security.
The physical security of the system is obvious: if you leave the machine
in the open and readily accessible, it will probably be accessed.
Locate your machine where it can’t be picked up and walked off with,
especially the servers. These
machines have not only your data but also all the network access information on
them. Software
security covers issues such as viruses and Trojans, the most common of which
these days are embedded in macros. Many
NT applications like Word and Excel run macros which can call other files, such
as .HLP and .DLLs, which can harbor viruses.
Some virus checkers don’t examine these files, dealing only with the
executables. When the help file is
opened, it can call a DLL, and the virus is loose from either one of them.
Some software packages have in-built security regimes, too, especially
the more expensive toolsets for CAD, program development, and accounting.
These should be used to augment the NT security system. The
most important level of security on an NT system is the user security, and
that’s what we focus on in this article. User security applies not only to the
user and group permissions, but also to all the peripherals and drives on your
system. C2
or not C2 Windows
NT is touted as being C2 security complaint, which puts it in a high security
classification. C2 systems, when
properly implemented, impose restrictions on what you can do with the system and
the user accounts that reside on them. Maintaining C2 security on a Windows NT
workstation is pretty much impossible unless you keep the NT system off a
network, and few NT servers can be C2 compliant at all.
You can, however, keep the highest security possible on your system by
making sure of a few simple steps. First,
remove any multiple boot potentials for the machine. If you have dual boot into DOS, Windows 95, or other
operating system, your machine is vulnerable.
The NT filesystem can be accessed from the other operating system with
surprising ease, and that immediately violates C2 security (and lesser levels,
too). Remove dual boot for all
servers without a moment’s thought. Workstations
may need to be dual boot, depending on the user’s requirements, but be careful
of the potential for network access from a dual booted workstation.
Make
sure all drives on NT systems use the NTFS filesystem.
The FAT filesystem is wide open for intrusions.
You do not need to keep FAT filesystems unless you have dual boot, and as
just mentioned, that’s a really bad idea from a security point of view.
You can convert existing FAT filesystems easily enough through the
Properties window of the drive. (NTFS
filesystems can be read from DOS and Linux, but it’s much harder than a FAT
system.) Security
Rights and NT Windows
NT handles security with a simple yet powerful method.
Every Windows component, from files to devices, is treated as an object
by the system and has properties associated with it.
Users, too, have properties associated with their logins.
Windows NT’s security subsystem uses a set of descriptors for every
object and user, one a security descriptor that contains a set of flags and
access control lists (ACLs), and the other an access token which cover a
user’s rights on the system. The
security descriptor for every object on the system is made up of a number of
sections, the first of which is a set of flags for the revision number, format
of the entries, and an access control list status. The next two fields hold a security identifier (SID) number
for the owner or the owner’s group. The SID is used to identify the user or
the group throughout the network. When the group SID is filled out, multiple
people own the object. Following
the two SIDs for owner and group are two Access Control Lists, one called the
security access control list (SACL) and the other the discretionary access
control list (DACL). The SACL is
used by the auditing system, and when auditing is on, entries are recorded in
the logs. The DACL explicitly
defines who can use the object the security descriptor describes. The DACL is filled out when the administrator uses the User
and Group permissions or the User Rights Policy, which are discussed in a
moment. The
SACL and DACL are laid out in the same manner, starting with a header that lists
the number of entries in the ACL, the size, and a set of flags.
These entries are called access control entries or ACEs.
Each ACE defines the object’s rights for either a user or a group by
using three fields which differ in use depending on the type of permissions and
the object the ACE applies to. Windows
NT is smart when it uses security descriptors for operations that may be
canceled. If a group of objects
have the same rights (such as when you are or copying files), only one full
descriptor is used for one of the objects and the rest have temporary pointers
to the full descriptor until the objects are saved, copied, or written to some
device, in which case the full descriptors are written.
This saves time and memory when NT is checking access rights. A
user’s access token has a bunch of fields associated with it including a
security identifier (SID), all of the group SIDs that the user belongs to, and a
set of privilege fields that show special rights. The first field of the privilege section is a count of the
number of privileges, followed by two fields for each privilege.
The privilege fields are a locally unique identifier or LUID which is a
pointer to an object on the system, and the other field is a mask that sets the
exact permissions. Every user on the system has an access token and they are
shared across networks between clients and servers.
The LUIDs may not apply on other machines, though. Managing
User Accounts One
of the biggest problems with NT security is wide-open user permissions.
Some administrators assign each user with full permissions on the system,
able to do anything and go anywhere. The
logic for this type of arrangement is that it removes the need for the user to
hassle the administrator for permissions every time they need access to
protected areas of the system. While
the short-term hassling by users may be solved, the potential for complete
disaster is increased astronomically, really saving the administrator little in
the end. NT
has a very simple-to-use user account management routine.
It is far simpler to use than other operating systems like UNIX, for
example, in that creating users, assigning them to groups, and changing their
permissions in the future is really just a few mouse clicks away.
This ease of use is often why administrators forget the basic principle
of allowing users access only to what they need, and locking everything else up. To
manage user accounts you should be logged in as Administrator.
Ideally, there should be only one login with the ability to manage user
accounts, but many systems have several administrators assigned.
The logic behind multiple access is sound: in case of one person not
being available another can complete required tasks, and there is the remote
chance of the person with the sole administrator’s account forgetting the
password, leaving the company, or sustaining some injury.
However, the spreading of administrator rights should be carefully
restricted. On most systems, the
recommended method is to have one person who is primary administrator, and a
single backup person with access in case of problems. More than two people with wide-open access to the system
starts to present more opportunities for mischief. Managing
users properly begins with setting up logical groups. Groups are a concept taken from UNIX, where multiple logins
can share access permissions. NT is
shipped with a number of default groups, which will suffice for many systems
without modification. The key
groups that have to be limited in the number of members are Administrators
(which has no limits on access or actions) and Backup Operators (which has
access to the backup and restore capabilities).
The Power Users group can present a problem when in the hands of someone
who wants to abuse their rights as they have the ability to perform functions
such as remote shutdowns. The Power
Users group should be given to people who are very trustworthy, and not just
users who think they are heavy-duty system users.
Most
users will fall into either the Users group (which can’t alter any system
settings) or Guests (who can only log on and off). Creating other groups with special permissions is often
necessary based on application access. For
example, you may need to create an Accounting group with access to an accounting
package and its files (which you want to keep everyone else away from).
Similarly, if you have project development under way, you may want to
create a group for that project’s members with access to tools and file
systems that others can’t get to. Creating
groups is simple, but take care to set the permissions carefully to ensure abuse
is not possible. All
administrators and backup operators should have two accounts, one for the admin
or backup login used only for system work, and another for their regular work.
Use the admin and backup logins only when needed for system work.
Otherwise, use a standard Users group login for day-to-day operations.
Since the Administrator account is the one most often used for break-ins,
make sure the password is very tight. An
even better trick is to create another group which has all the administrator
group’s permissions, then disable most of the permissions on the Administrator
account and enable auditing. You’ll
be able to see when someone tries to access your system with that login.
Adding
users to an NT system is also simple and the most critical step is assigning a
group for the new users. As
mentioned above, make sure they get only the permissions that need and no more.
Along with permissions, use the Policies system to set parameters like
how often the user must change their passwords.
One
of the keys to maintaining good group and user security is to clean up
occasionally. When someone leaves
the company, immediately remove or lock out their account.
This removes any chance (however unlikely) of that person or someone else
using their login remotely. Even if
someone goes on vacation for a while (especially if they have special access
rights), lock out their account for the duration of the absence.
With NT, you can set the lockout to expire automatically, simplifying the
whole procedure. One
of the most forgotten tools in the user security component of NT is the User
Rights Policy dialog, which allows you to set different access rights for users
and groups. This can be used when a
particular user needs more access or permissions that the normal Users group
allows. For small numbers of users,
it is easier to modify their rights individually with the User Rights Policy
than to set up a new group. These
changes affect their SACL and DACL security descriptors. Make
sure the Guest account has a password, or even better remove the account
entirely. By default, there isn’t
a password on the Guest account and if your machine is attached to a network or
the Internet, anyone can log in as Guest and have immediate access to any shared
directories, files, or drives. Using
the Guest account, a knowledgeable person can even access the Registry and trash
your machine, all without special permissions.
Either disable the Guest account, add a very tight password that is given
out to only a few people on a short-term basis, or button up your sharing system
completely. (If you think this is
not a problem, a quick scan of the Internet will show several hundred different
programs that allow someone to access your NT server with the Guest account and
try logging in with password guesses thousands of times a day.
Eventually the password has to break.
Set a low number of failed login attempts for the Guest account which
then disables logins for several minutes to help foil this type of attack.) How
should you best set up user passwords on your NT system?
C2 security sets certain practices, but every system should impose
passwords that are not simple to crack. Make
sure the passwords expire after a certain amount of time.
Three months is a good interval, frequent enough to foil those who snatch
passwords and yet not too annoying for users.
Set the password length to at least eight characters, but ten or more is
better. One
of the most common tricks users use to get by remembering new passwords is to
change the password then immediately change it back to the old password.
NT gives you the ability to prevent this in two ways.
You can set a minimum amount of time that the password must be in force
(a week is usually sufficient) and you can set the number of passwords the
system remembers and forbids reuse of them.
By default, NT remembers five passwords, and that should be adequate for
most systems. While
in the User Policy areas of the system, set the lockout after bad login attempts
to three or four. If a user can’t
type their login name and password properly after three times, they have a
problem. To avoid too much hassle,
set the reset count field to about 20 minutes to avoid perpetually-locked-out
users. Finally,
one security aspect most administrators forget: set the system to log users off
the server whenever logon hours expire. Since
most intrusions over the Internet occur in the early morning hours, prevent
logons between midnight and six AM, for example.
Even the most dedicated worker at home should be finished by then, and
few people need the system before six in a typical work environment.
Of course, you will have to tailor these times to your workplace’s
requirements. Where
the Potential Problems Lie Windows
NT is a complex operating system, and there are a number of issues that an
administrator must bear in mind when buttoning up the system.
The issues depend to a large extent on the connections the NT system has
to the network and Internet, as well as the type of applications the NT system
is running, but a few generalities can be pointed out as targets for you to
consider. The
biggest security hole in most NT systems that are on a network are the TCP/IP
services such as FTP, Telnet, SMTP, and HTTP.
Buttoning up your system for standard services like FTP and Telnet is
simple (not allowing anonymous FTP logins is probably the simplest step you can
take) and there are dozens of books that cover the security aspects of these
services. If you don’t need a
service such as FTP or TFTP, disable it. It
does no good running if you don’t need it, and a wise intruder can exploit the
service’s holes. If
you do allow FTP and Telnet on your system, remember that the passwords
associated with logins to these services are transmitted with no encryption
whatsoever. Anyone can read the
packets and pick up the username and password.
It is good practice to set up specific FTP or Telnet accounts that have
restricted access. Don’t
encourage users (especially those with high permissions) to log in over the
Internet with their normal account logins. The
biggest problems to most systems are SMTP (Simple Mail Transfer Protocol, the
protocol used to transfer mail messages around a network) and HTTP (Hyper Text
Transfer Protocol, the protocol used by the World Wide Web).
HTTP is the biggest problem of all, and few administrators realize the
problems HTTP poses. For a number of years, the subset of HTTP that was used by
Microsoft in their Web server products before NT 4 provided basic security, but
that was all. Any knowledgeable
person could break the system. With
NT 4 and the latest versions of IIS, these problems have disappeared, but you
should make sure the Web server software you are running is secure.
The
biggest problem with most modern Web servers is not the HTTP server software
itself by the CGI scripts written by the users of the system to enhance the Web
pages. CGI has the potential to be
exploited with catastrophic effects, with full access to the network possible if
the CGI script is not written properly. Knowing
how to write a good CGI script is vitally important if you use them on your NT
system, and since CGI scripts are portable you should consider reading any good
book on CGI scripts (most are for UNIX but apply fully for NT) to find out what
not to do. Avoid letting users load
their own CGI scripts to your server until you have checked them out thoroughly,
or find someone who knows what to look for before opening up your system. While
on the subject of TCP/IP and the Internet, watch out for Server Message Block (SMB)
services. These are usually enabled
by default on all servers and can be easily exploited.
SMB is used for NT (and other Windows operating systems) file and print
sharing systems, names pipes, and RPC (Remote Procedure Call).
There is not a lot of information about SMB available as few people seem
to understand it properly, but a few books do cover it.
To prevent problems with SMB access, don’t put a server with file and
print sharing active as the gateway to the Internet.
Summary There’s
a lot to consider when it comes to security, and we can only scratch the surface
in this article. For information on
filesystems and user security, consult any good security book.
The principles apply even if the examples are for another operating
system. Above all, take care when
setting up your system to ensure the users and groups are properly set, and
sharing is only as necessary. Set all permissions on an absolute need-to-have basis and not
on a wide-open policy. By
far the biggest problems with security for NT systems are networks and the
Internet. Although most servers for
NT are secure, there are many that have problems.
A search of the Web for information about a particular product will often
find warnings from users, as will the Usenet newsgroups.
The Web is especially problematic as it is difficult to button up an NT
system. A little patience,
research, and frequent checks of the system should help solve the majority of
the problems. |
|
Send mail to
tparker@tpci.com with
questions or comments about this web site.
|