\\\\WINDOWS NT, AND GENERAL TCP/IP ISSUES////
          
          
          
          
          
Windows NT Security Issues


------------------------------------------------------------------------

This whitepaper was originally written in 1994, when NT was first 
released. It still contains some useful information, but is gradually 
becoming obsolete. 

------------------------------------------------------------------------


These issues are listed in no specific order. Some of these are general 
security issues for all computers, some are unique to Windows NT. This 
list is not all inclusive. The emphasis is on more obscure issues, since 
the general topic of computer security is already well addressed by many 
books. Suggestions for additions to this list are welcome.  

Internet issues


NT supports several types of networking: 

*	Standard TCP/IP services (such as FTP, WWW, SMTP) 
Most of the books on Internet security address TCP/IP issues exclusively 
and very well. Since NT machines (especially not Internet gateways) do 
not normally support NFS, NIS, Sun RPC, r* commands, telnet server, and 
so on, it is not difficult to plug most of the holes in TCP/IP with 
respect to NT. The biggest risks are likely to be the SMTP and HTTP 
servers, so make sure you run these services under an ordinary user 
account, and not the System account. 

The HTTP protocol is very simple, but nevertheless the NT web server IIS 
had some gaping security holes in its initial implementation. The 
security hole would allow anyone who had remote access to an IIS Web 
server (anyone on the Internet if the server was connected to the 
Internet) to delete any files for which the server had delete 
permission. Also, these actions wouldn't even have been logged! Read a 
discussion of this bug. The specific holes listed at that site have been 
fixed in the version of IIS included in NT 4.0. 

The concern is that if the programmers writing IIS opened such an 
enormous security hole even when working with a very simple protocol, 
there is reason to anticipate that other security holes will be 
introduced in products that, like IIS, are being rushed to market for 
competitive reasons, especially when these products are more complex 
than the first version of IIS. Examples of such products include various 
ISAPI DLLs used with IIS, Java implementations, ActiveX. 

Visit the  World Wide Web Security FAQ for more information about Web 
security. 

HTTP CGI scripts can be a grave security risk if the person writing them 
doesn't know what they are doing. Don't let unskilled users write CGI 
scripts! The Unix oriented security books provide good guidance on this 
subject, since there is nothing NT specific about CGI scripts. 

*	Remote procedure calls 
NT programs use remote procedure calls (RPCs) to allow various system 
services to be performed on a remote computer (i.e. a computer other 
than the local computer where the program is executing). RPCs can run 
over a NetBios/SMB session or they can run directly over TCP/IP or other 
transport protocol. 

There is no good documentation on what services (if any) NT provides via 
native RPC. Server type programs (such as Microsoft Exchange) can 
provide their own RPC services in addition to any provided by NT itself. 
TCP/IP port 135 is used as a port-mapper port. In some cases, client 
programs must access this port before accessing the RPC service itself. 
So if you are concerned about Internet access to RPC services, it might 
be advisable to block this port. However, an RPC server can also use a 
fixed TCP/IP port and thus the client wouldn't be required to access the 
port-mapper before accessing the RPC service itself. 

*	SMB services (native Windows file/print sharing, named pipes) 
Few books on Internet security even acknowledge the existence of SMB, 
because this session level protocol is not a Unix standard (though there 
are some implementations of the SMB protocol for Unix, such as Samba for 
Unix). SMB is used by Windows 3.1, Windows 95, Windows NT and OS/2. 

The SMB protocol is important since it allows remote access to shared 
directories, the registry, and other system services. The exact number 
of services accessible via the SMB protocol is not well documented. Nor 
is the method of controlling access to these services well documented. 
It is possible to set permissions on shares, files, registry keys and 
printers. But the procedure for controlling access to the event log, for 
example, is not well documented. There is a way to prevent all remote 
access to the registry (other than to administrators) but this is not 
well documented. There are many services accessible by the SMB protocol 
whose existence itself is not well documented, and the procedure for 
controlling access is also not well documented, or there may not be any 
procedure for controlling access. 

The section on remote registry access shows the sorts of problems that 
can result from the SMB protocol. 

At the level of the SMB session itself, access is controlled by username 
and password. The Guest account does not have a password. In NT 3.51 
workstation, the Guest account is enabled by default. In NT 4.0, the 
Guest account is disabled on both workstation and server. It is 
advisable to keep the Guest account disabled on machines that are 
exposed to the Internet or any other unprotected environment. 

Even if all accounts have passwords, it is possible for a malicious user 
to try to guess usernames and passwords. You can and should require 
users to choose passwords that are at least 8 characters long, and also 
set a limit on failed logon attempts for all accounts other than 
administrator. Once this limit is reached, the account will be disabled 
for a time interval (for example 10 minutes). This will make it severely 
limit the ability of a crack program to guess username/password 
combination. You cannot set a limit on failed logins for the 
administrator account. This is to avoid the possibility of denial of 
service attacks, where all accounts on the computer are disabled due to 
repeated login failures. However, you can and should rename the 
administrator account to something obscure, and also make the password 
for the administrator account long and obscure. You might also want to 
disable the administrator account from logging on over the network. NT 
4.0 resource kit includes the passprop.exe utility, which allows 
limiting failed network login attempts for the administrator. 

The best solution is to disable access to SMB services from the 
Internet. If you have a router, you can disable udb/tcp ports 137, 138, 
139 (the NetBios over TCP/IP ports). 

*	Appletalk and Netware services (various products) 
There is no reason to be running these services on an NT gateway machine 
connected to the Internet, so this is not an issue. 






Remote registry access


NT installs by default with Everyone given write access to much of the 
registry. To see just how much, use the Somarsoft DumpAcl program. In NT 
3.51, this was a major problem due to the remote registry access feature 
of Registry Editor. Any user could manipulate the registry on any server 
or workstation on which this user has an account (normally this means 
all servers in a domain environment), or on which the guest account is 
enabled. 

NT 4.0 fixed this problem by introducing the following registry key: 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg

This key is present by default on NT 4.0 server. It is NOT present on NT 
4.0 workstation, but can be added. The presence of this key disables 
remote registry access, other than to administrators. 

In order to understand the importance of protecting the registry, 
consider some potental attacks on an unsecured registry: 

*	Denial of service. A malicious user changes a few registry entries so 
that various services begin functioning strangely, but not so strangely 
that it is obvious what has happened. The problems are not reproducible 
at other sites. The sysadmin reinstalls and the problems go away. The 
malicious user makes the changes again after a few weeks and the 
problems reappear. If audit logging is enabled, the sysadmin might 
eventually track the problem to the user who made the changes, but in 
reality, most sysadmins will just reinstall NT. The sysadmin eventually 
comes to the conclusion that NT needs reinstallation every few months to 
keep things running properly. 
*	Full break in. Malicious user installs a break-in program into their own 
home directory, then modifies a key in the registry to point to this 
break-in program instead of some other original program. The break-in 
program does the following: 
1.Passes command line parameters to original program that the registry 
key pointed to. This way the user notices nothing suspicious happening. 
2.Gives malicious user administrative privileges, if possible. It will 
be possible if the account under which the program is executing is an 
administrator. If not possible, then exit. 
3.(optional) Notify the malicious user of success. 
4.Perform registry cleanup to erase all traces of itself. 

A previous version of this whitepaper listed 
HKEY_LOCAL_MACHINE\SOFTWARE\CLASSES\txtfile\shell\open\command as an 
appropriate registry value to change. This hole was detected during the 
C2 evaluation process (according to  Alva Nimsof the Aerospace 
Corporation) and now the NT 3.51 resource kit recommends making the 
HKEY_LOCAL_MACHINE\SOFTWARE\CLASSES tree read-only. The resource kit 
also shows how to close most of the other holes of this sort. But there 
is still the PathName value under the 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RasMan\CurrentVersion key. And if 
this key doesn't exist on your system, then just use Somarsoft DumpAcl 
and Somarsoft DumpReg together to find some other key which Everyone can 
write and which has a .exe or .dll file as one of its values. 



Permissions set improperly


If the file system has a large number of files (say 500,000), it is 
impractical to examine the permissions on each file using file manager. 
Somarsoft DumpAcl produces a report of permissions which groups files 
and directories with the same permissions, so the report of file system 
permissions is much shorter. Permissions are only shown for the root 
directory and files and directories below the root whose permissions 
differ from those of the root. If all files and directories have the 
same permissions, a report of permissions consists of a single item. 

One of common ways for files to get "wrong" permissions is due to 
differences between the way permissions are treated when copying versus 
moving a file. Copying a file causes the file to inherit permissions 
from the directory into which the file is copied. Moving a file 
preserves existing permissions on the file. So, a user might create a 
file in a temporary directory whose initial permissions give Everyone 
full control. This user then decides to add some data to the file that 
they don't want other users to change. So they move the file to a 
directory where only they have write permission. However, the file will 
still have the original permissions, giving Everyone write permission. 
If the user had copied the file and then deleted the original, the file 
would have the same permissions as the directory. The Somarsoft DumpAcl 
report makes it very easy to spot files with "wrong" permissions.  

Securing a shared workstation


Many users have asked how to secure a shared workstation so users cannot 
do any damage to the machine. For example, a workstation in a computer 
lab at a university. As described above, there is no way to secure the 
registry. For NT 3.51, the file system can be secured by setting the 
entire drive to the following permissions: 

    SYSTEM                full control
    Administrators        full control
    Everyone or Users     read only



Permissions should then be reset on the %SYSTEMROOT%\SYSTEM32\CONFIG 
dirctory as follows: 

    SYSTEM                full control
    Administrators        full control
    CREATOR OWNER         full control
    Everyone or Users     add permission only



These settings allow users to create a profile, but prevent them from 
reading other users profiles, to avoid the security issues described in 
the section on Profiles contain sensitive information. 

Permissions should also be reset on the TEMP directory (C:\TEMP or 
whatever) as follows: 

    SYSTEM                full control
    Administrators        full control
    CREATOR OWNER         full control
    Everyone or Users     read/write/execute access to directory
                          no access specified for files



These settings allows users to use the TEMP directory, but avoid 
problems with users being able to read temporary files containing 
sensitive information that were created (and never deleted) by other 
users. Even if user remove files with sensitive information from the 
temporary directory, there is the issue of permissions being retained 
when a file is moved instead of copied (discussed in the section on 
Permissions set improperly). So the permissions on the TEMP directory 
should be set so initial permissions on a file are restrictive. Users 
can later make the file world-readable if they want to. 

There are other files and directories to which users of a shared 
workstation may need write access: 

*	Some applications require write access to the application directory to 
store data. 
*	Many older Windows applications require write access to the %SYSTEMROOT% 
directory to store .INI files. Newer 32 bit applications should use the 
user registry instead of .INI files. 
*	DOS graphic programs require write access to 
%SYSTEMROOT%\SYSTEM32\CMOS.RAM. 
*	The builtin NT backup program requires write access the 
%SYSTEMROOT%\SYSTEM32 directory to store temporary files. 


The above list is not all-inclusive. You can enable failure auditing on 
all files and then examine the audit logs after making the most of the 
file system read-only to determine what files users need write access 
to. You can also use the Somarsoft DumpAcl program to dump and print 
file permissions prior to making any changes.  

Macro runs when document is opened 


Various application programs (including Microsoft WinWord, Excel and 
Access) contain very powerful macro languages which can perform file 
i/o, call Win32 API's, and otherwise do anything a virus written in 
assembler language or C could do. These macros can be configured to run 
automatically when a file is opened in the application program. So, the 
old distinction between data and programs is now blurred. In the past it 
was possible to tell users "feel free to exchange data files with 
untrusted users, since these never carry viruses, just don't exchange 
.EXE, .DLL, .COM and other executable files". Now users have to be told 
to suspect all files. This severely impacts users ability to get their 
jobs done. 

Also, Postscript files have file i/o capability. So if you open a 
postscript file in an interpretor, it might go out and modify any files 
to which you have write access. Some interpretors have explicit options 
to disable file i/o. 

Also, Windows Help files (.HLP extension) can call DLLs (typical use is 
to customize the Help program in some way). So, suppose you receive a 
package containing a .HLP, .EXE and a .DLL file all together. You want 
to browse the .HLP file to see what this package is all about and 
whether you trust it enough to run the .EXE file. You assume the .DLL is 
called by the .EXE only. When you open the .HLP file, the .DLL is 
executed and it's too late if you decide the package is untrustworthy. 

Some Internet Web browser are setup to automatically start up the 
application associated a document suffix. So if you click on an URL 
ending in .DOC, that file will be fetched and WinWord will be started 
with that file as the command line. If that file contains a macro, it 
will be run. If that macro is malicious, too bad for you. 

WinWord and Access both allow the user to hold down the shift key when 
opening a document to prevent any macro from running. It is difficult to 
get in the habit of doing this (I am speaking from experience), 
especially when most of the Word or Access documents you open are your 
own, and therefore known to be safe. 

WinWord 7.0 contains a feature which appears to warn users of macros 
which run during document loading, and give the user to option to not 
run the macro. This feature is enabled by default.  

File sharing issues


The SMB file and print server protocol used by NT is much more resistant 
to impersonation and session hijacking than the NFS file sharing 
protocol used on Unix. This is significant since NFS is one of the 
biggest security weaknesses on Unix. 

It is remotely conceivable that a gateway machine could hijack an SMB 
session and then read/write any files to which the true user of that 
session had access. However, the likelihood of this happening is very 
small, since true gateway machines are seldom used on LANs due to 
performance reasons. If the machine attempting the impersonation or 
hijacking is merely a node on the same Ethernet or Token Ring as the 
client and/or server, then it would probably be very difficult to 
perform the impersonation or hijacking. In particular, it would be 
difficult to get packets routed to the impersonating machine instead of 
the true destination machine. 

In any case, the much more relevant security risk is that user data is 
transmitted in the clear and so can be easily read by any computer on 
any LAN over which the data passes. Remember that if you connect to a 
remote network drive over the Internet or other insecure connection, you 
are passing data back and forth whenever you read or write a file on the 
network drive. File manager gives the illusion of the data being local, 
which makes remote files easy to use, but which can also lead to 
security breaches. 

This risk of eavesdropping does not exist for logons passwords, since 
these are never transmitted in the clear over the network, but rather a 
challenge-response protocol is used instead. 

In the long run, it would be nice if Windows NT were designed so that 
all SMB protocol data passed over the network was automatically 
encrypted, using a key which was randomly chosen for each NetBios 
session. No directly competing operating systems have this feature and, 
until some do, it is unlikely NT will. If you have a need to transmit 
data over an insecure network and you want to be protected from 
eavesdroppers, you will need to use some sort of encryption. For 
example, there are router boxess that can encrypt all TCP data, but not 
the IP header which is used for routing. Put one of these routers at two 
sites and configure with the same key all data passed between those 
sites with be secure. You are still open to traffic analysis, however. 
Traffic analysis is a concern, for example, when an undercover spy wants 
to send reports back to the home office, or similar scenarios. 

There may be some special network cards (with NT drivers, please) which 
perform on-the-fly encryption, to avoid the problem of eavesdropping on 
a LAN. Presumably the netcards would have to be configured by an 
administrator to contain a shared key. Manufacturers of such netcards 
who would like a link, please drop me a note.  

Profiles contain sensitive information


Some users put their userid and password on the command line of the 
program manager item, for example for Microsoft Mail. This way they can 
start mail by just double-clicking the mail icon, without having to type 
in their password. This password will be embedded in the user profile. 

The local user profile is stored in %SYSTEMROOT%\SYSTEM32\CONFIG and 
also on a file server share, if a named, domain-wide user profile has 
been assigned for the user. Permissions on these directories should be 
like: 

    SYSTEM                full control
    Administrators        full control
    CREATOR OWNER         full control
    Everyone or Users     add permission only



This is how permissions are initially set on 
%SYSTEMROOT%\SYSTEM32\CONFIG. Since CREATOR OWNER has full control, each 
user will have full control of their own profile. Since Everyone and 
Users have only add permission, they will be able to create a profile,
 but won't be able to read other users profiles. 

In some cases, such as with 3270 emulator programs, passwords are 
included in keyboard macros (so the user can use F12 or whatever to 
initiate the entire logon sequence). These macros may be stored in the 
user profile or a file. If a file, users should be warned to make sure 
the directory where this file is stored is not world-readable. This is 
primarily a concern on shared workstations.  

Ctrl-Alt-Delete does NOT protect against all trojan horses


Supposedly, requiring a user to press Ctrl-Alt-Delete to bring up the 
login screen protects against application level trojan horses, since the 
operating system always traps this key sequence. However, it does not 
protect against a trojan horse which has some cooperation from the 
keyboard device driver nor from a DOS program, masquerading as NT. 

A DOS trojan horse would be particularly easy to write and install, 
provided the NT workstation allows booting from the floppy drive without 
a hardware password, or this hardware password can be circumvented, 
somehow. Once the DOS trojan horse program had captured the user's 
password and transmitted it over the network to the malicious user, it 
could throw up a fake blue screen of death, alleging some driver 
problem. The user would call the network administrator, the problem 
would go away after a cold reboot, and the incident would be dismissed 
as an NT or hardware fluke and would soon be forgotten.  

Passwords in general


If a password is short and obvious, then it can be guessed. If it is 
written down in a notebook, it can be discovered. So pick a long 
password, consisting of a mixture of upper and lower case letters and 
punctuation, never write it down, and change it often (but not so often 
you feel the need to write it down). This is all well-known, but so 
important that it is worth repeating nonetheless. Finding someone's 
password written down is the lowest-tech way to break into a system, but 
unfortunately also the most common.  

Special shares


NT shares the %SYSTEMROOT%\SYSTEM32\REPL\IMPORT\SCRIPTS directory, so 
that users can read their login script during login. Normally, all of 
the scripts are readable by Everyone. So be careful what you put in 
these scripts and this directory. Other special shares are created by 
other installed services, such as SNA server or SMS. Use Somarsoft 
DumpAcl to dump a list of shares and their permissions. And examine the 
permissions on the directories underlying the shares. Remember that the 
final access permission on a shared directory is the intersection of the 
share and NTFS permissions. So while you are setting permissions to 
restrict access, be careful you don't unintentionally completely remove 
access.  

Win32 services default to running under SYSTEM account


Many of the internet Unix breakins occurred when someone discovered a 
bug in a TCP/IP service and took advantage of this bug to break into the 
system. For example, the infamous Internet worm took advantage of a bug 
which caused the stack to be overwritten if the finger daemon received 
bad input. Obviously, you should try to only run services which do not 
have bugs. However, the danger if there is a bug is greatly reduced if 
the service runs under an ordinary user account with restricted 
permissions, instead of under the SYSTEM account (which corresponds to 
the Unix root account). So, for example, run your SMTP service under an 
smtpuser account, and give this account limited privileges, instead of 
running it under the SYSTEM account.  

Viruses and trojan horses


If you are not familiar with viruses, there are many good books on the 
subject. NT is better secured than DOS from viruses, provided you 
normally run under an ordinary user account (not administrator), and 
keep most system files protected against modification by user accounts. 
NT is also secure against boot sector viruses, which are the most 
difficult to eradicate, provided you never boot with a floppy in the 
drive, since NT does not allow non-privileged programs to write directly 
to disk. 

A trojan horse (as I define it), is a program which secretly does 
something "bad" at the same time it openly does something "good". For 
example, a program might openly provide an interface to an online 
service, but secretly transfer private files to/from your computer while 
you are logged on. 

Trojan horses are probably a much greater long-term threat than viruses. 
Viruses typically only destroy data in a fairly crude and therefore 
noticable way. Since the damage is soon noticed, the data can be 
recovered from backups (assuming the network administrator is doing 
their job properly). A trojan horse program, on the other hand, might 
perform very subtle damage, which might take years to notice. For 
example, it might search your network for files containing currency 
values, and then modify some of this values. Or the trojan horse might 
leak private data to the outside world, which might never be noticed. 

The best precaution against viruses and trojan horses, is to treat an 
unknown program similarly to how you would treat a new business partner. 
Namely, watch for subtle clues of suspicious behavior, check references, 
run a credit check, don't give the person a blank check the day you meet 
them, etc. You should treat an new program with the same degree of 
caution.  

Data on disk not encrypted


Anyone who has physical access to a machine can read file system data by 
either reinstalling NT (the installer can pick the initial 
Administrator's password and Administrator can read all files) or 
booting from a DOS floppy and reading raw sectors using a low level disk 
utility. In both cases, the user would need access to the floppy drive. 
On many machines, the floppy can be disabled via the BIOS. There are two 
ways to get around a disabled floppy: 

*	Resetting the BIOS. Typically this is done by setting a jumper which 
causes a slow discharge of the battery needed to preserve the BIOS 
settings in CMOS. Discharge might take several hours, or several 
minutes, depending on your motherboard. Don't trust manufacturer's 
specs, since this is not something anyone tests. 
*	Moving the hard drive to another machine and reading it there. 


These techniques require opening the computer case, so there should be 
no risk for machines stored in open areas where opening a case would be 
immediately noticed. 

If the case can be opened, then you will need to encrypt data on disk. 
There are various products which allow you to do this, with varying 
degress of user-friendliness and transparency. (Any manufacturers who 
would like me to list their product and add hypertext links to their Web 
pages, just drop me a note). 

If you need military grade security, it should be noted that fragments 
of any file that is stored unencrypted in memory can be written to the 
paging file. So software encryption products will not be sufficient in 
this case. What you need instead is a disk controller which encrypts 
data on the fly as it is transferred between memory and disk. Typically, 
the user would be prompted for a password by the disk controller BIOS 
during cold boot. An example of where military grade security is needed 
is a embassy which contains secret data on PCs. These PCs might fall 
into the hands of a hostile intelligence agency with adequate resources 
to extract information from the fragments of data in the paging file. 
For most users, such military grade security is not really necessary.  

Backup/Restore user rights allow reading/writing all files


It is obvious that to perform a backup, the operator needs to be able to 
read all files. What is not obvious is that tape need not be involved. 
It is trivial to write a program in C which takes advantage of the 
backup right to read any file in the system. So be careful of who you 
give the backup right to. Users who have both backup and restore rights 
can read any file, modify it and write it back, or they can give 
ownership to any user (there are several places where NT documentation 
states that administrators can take ownership but not give it-this is 
true for file manager, but other programs do allow administrators to 
give ownership). 

User Manager is used to assign rights to users. There is an option in 
User Manager to audit the use of user rights, and this should include 
the backup and restore rights. However, because of a poor design of the 
audit logging mechanism, exercise of these rights are not logged unless 
a registry value is set as follows: 

key  : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
name : FullPrivilegeAuditing
type : REG_BINARY
value: 1



This issue is further documented in the NT resource kit.  

Administrator, services, drivers are "all-powerful"


The administrator can take ownership of any file and thereby obtain 
read/write access to it. Some users have complained about this aspect of 
NT, which they view as a security hole. In fact, this same issue has 
arisen in all previous operating systems, including mainframes and other 
computers which are traditionally viewed as secure. It has been issue 
for thousands of years, in fact: "But who will guard the guards 
themselves?"-Satires,IV,Juvenal. There is no magic solution. 

Some policies that might lessen the risk from rogue administrators (and 
other users) include: 

*	Only hire trustworthy people to be administrators. In many situtations, 
an administrator can be dispensed with. For example, the owner of a 
small business might be their own administrator, instead of relying on 
some outsider. Day-to-day NT administration is sufficiently simple that 
this is a realistic option. On those occasions when an outsider is 
required, the administrator can stand by and watch that nothing 
suspicious is done. 
*	Have administrators work in teams and review one another's work. 
*	Establish a rule that says no one is allowed in the computer room alone, 
especially not after hours, but also daytimes when the office is nearly 
empty. If an administrator has to access the computers after hours due 
to an emergency, they should be accompanied by a security guard who 
should be trained sufficiently to be able to ask what the administrator 
is doing, judge whether the answer or actions sound suspicious, and who 
should always file a written report of the incident. 


These are similar to the procedures that are used in such situations as 
securing jewels in a bank vault, or guarding secret military plans. It 
goes without saying that it can be expensive to implement the procedures 
described above. 

Note that services which run under the system account and device drivers 
also have essentially unlimited powers. They can read/write any file, 
establish network sessions in the background and thereby transport data 
out of your network, create accounts, etc. See also the section on 
viruses and trojan horses.  

Data on backup tapes not encrypted


The NT backup program does not encrypt data on tape. So anyone who has a 
tape can read it on another machine on which the user has restore 
privileges, such as their personal NT workstation. 



FTP/Telnet passwords


Microsoft does a good job of warning people about the fact that FTP 
passwords are transmitted in the clear. Especially for machines 
connected to the Internet, it is probably best to allow only anonymous 
FTP, so that no one ever attempts to transmit a password to your machine 
over the internet. If you FTP or Telnet from your machine to another 
machine on the internet, the same warning applies: any password you 
enter or any data you transmit, could be intercepted by other machines 
on networks over which the data is passed.  

FTP service directory


When using the FTP server that comes with NT 3.51, the home directory 
you specify for the FTP service is only the initial current directory. 
Ftp users can change their current directory. So if you specify a home 
directory of c:\ftp, any ftp user can change to c:\ and thence change to 
any subdirectories under c:\. Normal NTFS permissions will apply, of 
course, to whatever account the ftp user is running under. If you don't 
want ftp users to be able to see the root directory of your primary 
partition, you should create a separate partition for ftp and then 
configure ftp so that it can only read and/or write to that partition. 
The IIS FTP server in NT 4.0 does not have this problem.  

Computer security in context


The possibility of outsiders breaking into a system is, for whatever 
reason, the security issue most people concentrate on. In reality, you 
are most likely to suffer serious computer related losses due to natural 
disaster (such as a hard disk failure) or from internal theft or misuse 
of data. Don't get so wrapped up with trivial issues that you neglect 
the bigger computer security context. This is obvious, but worth 
repeating nonetheless.  

Application software issues


The really valuable data on a computer system is what is produced by 
applications and stored in file and databases. It is very important to 
write and install these applications with an eye on security. It does no 
good to follow all the guidelines above and then have a database setup 
in such a way that anyone with an account can read the entire database. 
Or to have a transaction processing monitor which runs under a 
privileged account and allows unprivileged users to submit requests that 
give them access to the entire file system. 

------------------------------------------------------------------------
Return to the Somarsoft home page. 
Send comments and questions to info@somarsoft.com
All material Copyright © 1995-1997 by Somarsoft, Inc. 



Protection of TCP/IP Based Network Elements




Security Checklist




Version 1.8




by

Dale Drew



©Copyright 1995, 1996 Dale Drew 
mailto:ddrew@mci.net 


In 1994, CERT reported over 40,000 compromised sites on the Internet (
1994 CERT Annual Report). That number possibly references a much lower 
percentage of the actual problem as the Department Of Justice estimates 
that over 75% of incidents go unreported to proper authorities.

The need for effective security controls for the explosive growth of 
TCP/IP networks is now more important than ever. 

The purpose of this document is to provide an overall baseline for 
security considerations for securing TCP/IP based network elements. This 
document's intent is to provide a guideline for such considerations, and 
should not be considered a complete resource guide for implementing 
security precautions.

The problem is that many Security Administrators are faced with 
providing protection for their systems within their Corporate Network, 
without the benifit of knowing the makeup of that network. This document 
attempts to provide an overview on the ability to identify systems 
within your companies network, the exposures on those systems, who owns 
them, and how to effectively plan for the long term security strategy 
needed to keep them protected. Should you have any feedback for this 
document, please feel free to contact me.

To obtain a copy of "Security Considerations for the internetMCI 
Network", use the following URL: (
http://www.security.mci.net/sec-whit.html). 

Table of Contents


1.Identify valid internal network address numbers 
2.Identify your systems 
3.Store such information into a query database 
4.Scan systems for external vulnerabilities/exposures 
5.Obtain access to system elements 
6.Perform vulnerability assessment on internal systems 
7.Deploy Security measures and monitoring programs on systems 
8.Correct identified exposures from external scans 
9.Correct identified exposures from internal scans 
10.Deploy Security Patches 
11.Establish Password Checks 
12.Log files from systems, applications 
13.Use Telephone exchange scanners 
14.Control Group Accounts 
15.Deploy Virus Scanners 
16.Control ROOT/SUPERUSER accounts 
17.Network Security
1.Gabriel 
2.ARGUS
18.Identify gateway machines 
19.Obtain access to gateway systems to ensure firewall polices 
20.Secure gateway systems 
21.Develop a comprehensive Firewall model 
22.Develop notification mailing lists 
23.Be proactive
1.Subscribe to mailing lists 
2.Subscribe to security news groups
24.Employee Awareness Issues 
25.Obtain security related tools 
26.Other Security Sites available 
27.SECURITY PROGRAMS 
28.SECURITY RELATED BOOKS 
29.ADDITIONAL RECOMMENDATIONS:
1.1)Make use of one time password technologies 
2.2)Encryption 
3.3)File Access Policies 
4.4)MD5 Checksum File 
5.5)User access histories 
6.6)Enforce password change cycles
30.COMMON EXPOSURES
1.1)Social Engineering 
2.2)Poor Passwords 
3.3)Sendmail 
4.4)NFS 
5.5) Sniffable Traffic 
6.6) WEB Server Security 
7.7) Denial Of Service 
8.8) WEB Browser Security Iesues 
9.9) DNS Hostname Conventions 
31.OTHER CONSIDERATIONS
1.1)Network Security Policies and Procedures
2.2)Backups 
3.3)Physical Security 
4.4)Information Security 
5.5)Contractors/Vendors 
6.6)Human Resource Termination Lists 
7.7)Employee Education Issues 
8.8)Encryption 
9.9)Inventory 
10.10)Network Maps 
11.11)Prefix Scanning


Step 1


Identify valid internal network address numbers 

This information can be obtained from network administrators, or the 
Internet Directory (if you are using "official" network address 
assignments).
Establish a connection to or a presence on such networks for security 
functions. You must have a machine that has the ability to connect to 
the network, or a machine dedicated on the network. The firewall that 
protects the network must permit that "security" system to access any 
element. 

Identify your systems 

You need to identify the network addresses of your internal systems in 
order to run auditing programs against them. Once the range of addresses 
has been identified, you can scan these address to identify valid 
systems that are active. Once you've identified active systems, you can 
use that information to identify what types of systems they are. This 
information can be used to plan your security reviews and your 
notification programs.


Scan network elements for active systems (e.g.; "pingall" program)

The "pingall" program is a modified version of "ping" that probes each 
network address, waiting for a reply. When a system answers, it is then 
added to a network database that can be used as a listing of active 
systems. Versions of the pingall program are available on public FTP 
sites, as well as the SATAN distribution. A version of Satan can be 
found on the COAST archive ( http://www.cs.purdue.edu/coast/satan.html).
The "pingall" program can be found at the MCI FTP site (
 ftp://ftp.mci.net/pub/security/pingall).

In the following example, the user is attempting to identify all of the 
active hosts in the 204.70.128 subnet:


	user@host% pingall 204.70.128.
	204.70.128.1	ns.mci.net
	204.70.128.2	host.mci.net
	.... 
	....

This database can then be used in future runs to identify when additions 
are placed on the network. This is useful to identify new systems that 
have been added to the network that have not been added to the security 
policy.

There are several versions and models of the "pingall" program. 

Store such information into a query database 

The query database can be used to store active hosts in the network. 
This database can then be used by other programs that may perform 
routine audits, security checks, patch upgrades or to identify when new 
systems have been added to the network, as well as provide trend 
analysis on potential exposures.
The database(s) created by the  SATAN tool contain such valuable 
information, including; system name, OS type, IP address, and current 
system configuration parameters. 

These databases can be a crtitical and valuable link for being able to 
quickly identify specific types of systems in your network, who owns 
them and what applications are running on them. 

Two useage examples; 

1) Once you have a list of active addresses in your network, you could 
easily create a script that sends an email to the administrator of that 
system (root, webmaster, and postmaster for example), telling them to 
identify an owner for the system. 

We use a WEB page for this function; when our scanning software 
identifies a "non-registered" address in the internal network, it sends 
the administrator an email, telling them to connect to an intenral WEB 
page to register their system. This WEB page asks for Management chain 
information, contact information and provides accessability to internal 
security policy documents and standards.

2) Once you have a database of systems, platform types, owners and other 
useful information, you can use this to handle incident responses. For 
example, let's say CERT releases an alert about a new vulnerible version 
of sendmail (amazing but true!). You can use your databases to find out 
which systems are running sendmail, what platform they are, and who owns 
them - to ensure that exposure is corrected. 

Ensure you have a database!! 


Step 2


Scan systems for external vulnerabilities/exposures 

An assessment of this nature should be performed on some regular basis 
(e.g.; once a month). If the software allows, you should perform an 
assessment on a range of systems rather than specific systems as this is 
a good way to identify newly installed systems on your internal 
network(s).
If your assessment software supports multiple databases to store audit 
results, it is advisable to create separate databases for different 
network segments or platforms. If your assessment software supports 
email notification instead, it is recommended that you have the results 
sent to a central location email address specifically set up to receive 
such reports. This email address can then be used to automatically 
receive and review the reports for appropriate action.

Use vulnerability program(s) to identify exposures on identified system 
elements:


*	Public Domain Software: 
*	SATAN 
*	ISS 
*	NetProbe (PD) 
*	NSS 
*	Misc scripts 
*	etc. 
*	These tools are available at:  ftp://coast.cs.purdue.edu/pub/tools/unix 
*	Commercial Software: 
*	PINGWARE (Bellcore) 
*	Netprobe Commercial 
*	ISS Commercial 
*	etc 


Step 3


Obtain access to system elements 

Access to the system is a requirement in order to install security 
programs, auditing programs, and overall monitoring functions.
Work with system admins to obtain user account presence on systems 
(e.g.; "security" account) Preferably ROOT access, however not always 
needed. 

With great access, comes great responsibility. Access across all of 
these internal systems should be considered critical path access. One 
time passwords should be used to gain access to all systems if 
available. Where such functionality does not exist, secure, diverse 
password selection should be used, and the use of .rhosts and other 
"non-password" entry services should be disabled. Your access is the 
"Keys to the Kingdom" and should be treated appropriately. 

Step 4


Perform vulnerability assessment on internal systems 

Depending on the software available, and its functionality, there are 
three basic ways to accomplish the task of running security audits to be 
executed on the internal systems themselves; 1) If your auditing 
software supports a client/server model, then the server module can send 
the appropriate commands to the client to successfully run an audit and 
to send the results to some appropriate location. 2) Have a scheduled 
job (i.e.; CRON) to execute the audit software at a predefined date and 
time and to mail the results to some appropriate location and 3) have a 
security system somewhere on the network upload and execute the auditing 
code at a predefined interval.
It is recommended to always have auditing software stored off of the 
client, retained on a secure system as auditing routines can be easily 
modified to return false results.

It is recommended to have the vulnerability assessment reports sent to a 
central location email address specifically set up to receive such 
reports.

Use vulnerability program(s) to identify exposures on identified system 
elements 

*	Public Domain Software: 
*	COPS 
*	Tiger 
*	Tripwire 
*	etc. 
*	These tools are available at:  ftp://coast.cs.purdue.edu/pub/tools/unix 
*	Commercial Software: 
*	Axent 
*	Los Altos Technologies 
*	Tivioli 
*	etc. 


Step 5


Classify your systems 

Your systems information database should include some basic but 
important reference material in order to provide a quick summary of the 
system, its use within the company and the owner of that system at a 
moments notice. Having a classification of systems is also handy in 
order to determine the amount of security attention a particular system 
or set of systems should receive, dependent on its overall function 
within the company. Critical systems (e.g., Billing, Human Resources, 
etc.) may be paid close attention during anomaly scans, Firewall Policy 
creation and incident response procedures.
Your classification database should contain at least the following 
information: 

*	System IP Addresses 
*	System name 
*	Platform Type 
*	OS Type 
*	Sendmail Type (optional) 
*	System Owner 
*	System Owner Contact 
*	Classification Priority 
*	mission critical 
*	critical 
*	sensitive 
*	baseline 
*	minimal 




Step 6


Deploy Security measures and monitoring programs on systems 

Ensure that any security programs/data you have on remote systems are 
well protected from potiential or accidential tampering. Security 
programs should be in a common directory structure, protected from other 
users on the system.


Correct identified exposures from external scans 

Using the output from the external vulnerability assessment program(s), 
correct any identified security exposures.
Get help from your system administrators to get this done! 

Correct identified exposures from internal scans 

Using the output from the internal vulnerability assessment program(s), 
correct any identified security exposures. 

Deploy Security Patches 

A majority of the vulnerability assessment software can identify which 
security patches need to be implemented on the system. Obtain the 
required security patches from the vendor (a majority of the vendors 
have FTP sites), verify the supplied checksums and install as 
appropriate.
Monitor the CERT Advisory mailing list (cert-advisory-request@cert.org) 
and other appropriate vendor mailing lists to learn of newly released 
security patches. 

Establish Password Checks 

If reusable passwords are being used to access a system or resource, it 
is recommended to make modifications to the system's password program to 
enforce password selection "rules". These rules would prevent the user 
from picking easy to guess passwords that could be used by unauthorized 
personnel to gain access to a system. Poor password selection is the 
number two method for gaining access to a system.
Some operating systems, such as AIX and VMS, include these functions in 
the standard system software. They simply need to be enabled. Other 
systems require the installation of new password management software, 
such as passwd+ or npasswd, both available via anonymous FTP from 
 ftp://coast.cs.purdue.edu/pub/tools/unix/.

It is further recommended to make use of password "cracking" programs on 
sensitive systems that check password files for easy to guess entries. 
This functionality can be included in the internal auditing applications 
as a routine check, although it is recommended to make use of an offsite 
system for such attacks.

The Crack password cracking program is available via anonymous FTP from 
 ftp://coast.cs.purdue.edu/pub/tools/unix/crack/.



Log files from systems, applications 

All log files should be reviewed and analyzed for anomalies and 
exposures! It is recommended to have these log file forwarded to a 
central location (see SYSLOG). If such functionality is not available, 
it is recommended to have an application on the system that reviews the 
log data in real time - or nightly - and forwards appropriate security 
alert information to a notification system. 

SYSLOG

A majority of TCP/IP compliant systems support SYSLOG reporting of data. 
This allows the system to collect audit related data from applications, 
users, and the system itself and either store such information in 
appropriate system log files, and/or forward such information to a 
central SYSLOG server.
It is recommended to have SYSLOG clients forward security related audit 
information to a central SYSLOG server, which can receive and analyze 
such information in real time and send appropriate notification 
information when vulnerabilities are identified.

At a minimum the following parameters should be set in the network 
clients; 
auth.crit 

"auth.crit" is a SYSLOG parameter that is used to identify and record 
critical authentication messages. (e.g.; bad passwords, repeated login 
failures, etc). A typical entry in the client would look like so; 

   "auth.crit              /var/log/auth.crit

    auth.crit              @secure_system"



Where "/var/log/auth.crit" is the name of the file to store audit 
messages locally on the system and "secure_system" is the name of the 
system that the client sends "auth.crit" messages will be sent.



SYSLOG also has the capability of monitoring other applications such as 
TACACS, POP, TCPWRAPPER, FTP, TFTP, and other inetd services. Check the 
individual application to identify the SYSLOG tag to be used.

If SYSLOG capability is not available for specific applications (e.g.; 
WEB, FTP, etc) a script can be used to read audit trail data from a file 
and send it via SYSLOG to the central location. Such scripts are used 
widely within the internetMCI network, and are available to this 
distribution ( ftp://ftp.mci.net/pub/securityapp-monitor.tar.Z/). 

NETWORK MONITORS 

There are several programs which can monitor network traffic for 
unauthorized, or suspicious activity. Network monitoring, along with 
audit file monitoring, provide a very good first line of defense for 
proactively monitoring the state of security on your systems. One such 
Network Monitor, NETLOG, can monitor for network problems, application 
vulnerabilties and other network based events. Other tools include; 
GABRIEL and COURTNEY. All such tools include source code to allow you to 
customize the tool for your specific environment. 


CRON JOBS

CRON JOBS (the ability to schedule commands on a system) can be used to 
regularly run commands to check the system for security functionality or 
assessment. 

TCP WRAPPERS

TCP Wrappers can be used to provide access control to specific systems, 
as well as audit unauthorized access attempts to individual system 
elements. 

Use Telephone exchange scanners 

Routinely scanning internal telephone exchanges for modem tones, enables 
the ability to identify possible unauthorized implementations of dial-up 
access capabilities to access internal systems. Such capabilities are 
often unsecured, as they bypass traditional security polices. 

Control Group Accounts 

The use of group accounts should be examined from an implementation and 
policy standpoint. Identification on who is using group accounts and for 
what purpose should be understood, as well as a clear policy guideline 
on the use of group accounts.
If at all possible, modifications should be made to group accounts so 
that a user much log in with an individual name and password, then 
obtain access to the group accounts. Groups accounts should not be able 
to access the system directly. 

Deploy Virus Scanners 

Virus scanners should be used as part of your and your employees daily 
routine. Computer virus's continue to grow at an alarming rate and have 
the capability of affecting any media that touches your computer, 
including network connections. 
Virus scanning programs should be purchased and placed on all employee 
computers. It is preferable to purchase virus identification software 
that has the capability of running automatically, without requiring user 
initialization, as the majority of user populations tend to forget about 
integrating these routines in their daily work habits.

If applicable, implement a network storage site to allow employees to 
access and download security related software, including virus scanners, 
and make them aware of the importance of such procedures and the 
availability of when updated scanning programs are available.

Destructive virus can erase or alter data, as well as make entire hard 
drive partitions inaccessible, sometimes significantly overshadowing the 
cost of deploying an effective virus control program. 

Control ROOT/SUPERUSER accounts 

Privileged accounts should be tightly controlled and monitored. The 
ability to access a privileged account via direct login should be 
disabled (user should log in with his/her individual account, then 
obtain superuser privileges).
Password policy rules should be enforced on superuser password 
selection, as well as password expiration and rotation.

If available, access rules should be applied per system so that only 
authorized individual accounts have the ability of obtaining superuser 
privileges.

A cautionary word should be provided regarding any Administrative access 
to a system. It is recommended that administrative access only be 
obtained after an individual access has been obtained (eg; logging in 
with your individual account, then obtaining administrative access). 
Remote access to administrative usernames is also a major concern.

It is recommended that one-time passwords be used to access 
administrative accounts, this prevents interception of such passwords in 
network transit. Packages such as S/KEY, or hand-held authenticators 
like SecurID can be used to elevate this concern. 

Network Security 

Additional public domain (and commercial) tools exist to aid in the 
security of networks. These tools monitor the overall status of network 
security, not necessarily individual client security. 

Gabriel

Specially designed to detect SATAN scans and attacks, but also can 
detect other types of scans, probes and system attacks. 

ARGUS

Used to monitor packet headers and traffic types. Ability to analyze 
traffic to identify possible trends, as well as traffic that bypassed 
Cisco firewall filters.
Thse tools may be obtained via anonymous FTP from 
 ftp://coast.cs.purdue.edu/pub/tools/unix/. 

Step 7


Identify gateway machines 

Special attention should be paid to gateway/firewall systems, as they 
usually control access to network elements. Such gateways should be 
identified, its function within the network should be assessed and 
owners or administrators should be identified early on to resolve 
security related issues with such elements. 

Step 8

Obtain access to gateway systems to ensure firewall polices 

If a function of the gateway is to protect elements, or such 
functionality exists and could be used to protect network elements, then 
access to the gateway should be obtained in order to review current 
Access Control policies and the security of the system itself. 
Such access can then be used to facilitate automated scripts to ensure 
the security of such machines.


Step 9


Secure gateway systems 

Security of the gateway itself is imperative to ensure the security of 
the systems behind it. A thorough examination of the gateway is in order 
to ensure security policies are being exercised. In this example, we 
will be reviewing the security precautions available for CISCO routers: 

*	Turn off unsecure services 
*	Finger 
*	IP Forwarding 
*	Loose source routing 
*	Ensure the system has appropriate security patches 
*	Cisco "established" security patch 
*	Ip route-cache patch 
*	Secure access to the gateway 
*	ACCESS-CLASS used to identify who can access the router 
*	Disable SNMP Write 
*	Enable SNMP-ACCESS class restrictions 
*	TACACS used to provide username/password authentication 
*	Ensure Access Control List policies are carefully reviewed, implemented 
and monitored. Care should be taken to ensure that the firewall policy 
takes common TCP/IP threats into account. Such threats include: 
*	IP Spoofing 
*	Protocol attacks (FTP, SNMP, etc.) 
*	TCP Fragmentation Attacks 

Once a firewall policy has been reached, the firewall should be 
monitored at all times to detect additions, modifications or deletions. 
A monitoring program could be used to audit the on-line ACL on a routine 
basis to identify any changes. An example of such a program is "pollem" 
( ftp://ftp.mci.net/pub/security/pollem). 

Step 10

Develop a comprehensive Firewall model 

Used correctly, Firewalls can provide a valuable piece to your overall 
security model. Firewalls should be used to protect your internal 
networks from untrusted networks (e.g., internal test labs, the 
Internet, etc). Firewalls can also be used to segment internal LANs to 
separate operational functionality. This allow developing internal 
firewall policies to keep Engineering employees from having access to 
the Human Resources department for example. Firewalls, however, should 
not be the only solution available in your security model. Firewalls 
provide perimeter security, and do not address security issues on 
individual systems. This is analogous to a hard crunchy outside, and 
short chewy inside. In addition, Firewalls do not completely address all 
perimeter security concerns; there are modem dialup lines and other 
internal LAN/WAN connection issues that must be addressed.
There are wide variety of firewall products available on the market 
today, a majority of which provide a wide variety of functionality, from 
standing filtering rules (Access Control Lists), to encryption to 
enhanced authentication.

Firewall administration should be centrally controlled and evaluation of 
firewall policies should be done prior to actual firewall deployment.

Authentication requirements to Firewall systems should be a critical 
concern, and it is suggested that only the use of one-time passwords are 
used to access Firewall elements. It is also suggested that a daily 
audit of all Firewall configurations is performed to ensure no 
unauthorized changes have taken place.

Some available Firewall Products available today are:

PRODUCT	Company Name	Street Address	City	State	ZIP	Phone
ANS Interlock	ANS CO+RE Systems	100 Clearbrook Road	Elmsford	NY	10523	914-789-5337
ASR 4200	ACC Network	8320 Guilford Rd suite G	Columbia	MD	21406	410-290-8775
BlackHole	Milky Way Networks	2650 Queensview Dr, suite 255	Ottawa	Ontario CAN	613-596-5549
BorderWare	Border Network Tech.	1 Yonge St, Suite 1400	Toronto	Ontario CAN	416-368-7157
CyberGaurd	Harris Computers	2101 W Cypress Creek Rd	Ft. Lauderdale	FL	33309	305-974-1700
DEC SEAL	Digital	40 Old Boston Rd	Waltham	MA	01775	508-496-8626
Eagle	Raptor Systems	69 Hickory Dr.	Waltham	MA	02154	617-487-6755
Firewall-1	Checkpoint Software	One Militia Dr	Lexington	MA	02173	617-859-9051
SunScreen	Sun Microsystems	2550 Garcia Avenue	Mountain View	CA	94043	408-255-2937
Gauntlet	TIS	2060 Washington Rd	Glenwood	MD	21738	301-854-6889
ToolKit	TIS	2060 Washington Rd	Glenwood	MD	21738	301-854-6889
GFX-94	Global Tech, Assoc	3504 Lake Lynda Dr, Suite 160	Orlando	FL	32187	407-380-0220
IRX Livingston	Livingston Enterprises	6920 Koll Center Parkway #220	Pleasanton	CA	94566	510-426-0770
Int Security Router	Atlantic Systems	Incutech Center, Bag Service	Fredericton	CAN	506-453-3505
NetGate	Smallworks of Travis	4401 Stone Meadow Lane	Austin	TX	57831	512-338-0619
NetSP Secure Net	IBM	POB 12195, MS B44A-B501	ResearchPark	NC	27709	919-254-5074
Network-1	Network-1 Software	909 Third Ave (9th floor)	New York	NY	10022	800-NETWORK1
Portus	Livermore Software	1602 Mosay Stone	Houston	TX	77077	800-240-5754
Priv Internet Ex	Network Translation	1901 Embarcadero Rd, Suite 108	Palo Alto	CA	94303	415-494-6387
Security Router	Network Systems	7600 Boone Avenue North	Brooklyn Park	MN	55428	612-424-1784
Sidewinder	Secure Computing	2675 Long Lake Rd	RoseViller	MN	55113	613-628-2700
Cisco	Cisco Systems	PO BOX 3075	Menlo Park	CA	94026	800-553-NETS
SmartWall	V-One	12300 Twinbrook Parkway, #235	Rockville	MD	20852	301-881-2297
Brimstone	Sources Of Supply	461 Fifth Ave., 16th Floor	New York	NY	10017	800-SOS-UNIX
Freeston	Sources Of Supply	461 Fifth Ave., 16th Floor	New York	NY	10017	800-SOS-UNIX

Step 11


Develop notification mailing lists 

Be prepared to respond to security incidents. Develop security 
notification lists for; HR Managers, PR Contacts, Legal, Upper 
Management, Department Heads, Project Contacts, etc.

Step 12


Be proactive 

The key to identifying security issues before they become incidents is 
to be proactive. Staying in tune and up-to-date on security related 
issues should be the single most important aspect of your security 
program.
There is a significant number of resources available on the Internent 
and within the industry that provide accessibility to this type of 
information. 

Keeping up-to-date with the flood of security topics can also be 
overwhelming if not handled in a controlled manner. 

When subscribing to security mailing lists, be sensitive to the amount 
of projected mail that is expected to originate from those lists. Deploy 
email filtering programs to automatically file this mail if possible, 
and scan such mail for concerned keywords.

There are also a number of organizations that collect this information 
and provided summaries of such. Although subscription to these services 
can be invaluable, analysis of the frequency of their distributions and 
the sources of their information is a crucial aspect of subscription. 

Subscribe to mailing lists 

Firewall Mailing List 

Send "subscribe firewalls" to majordomo@greatcircle.com 

CERT Alerts 

Send "subscribe" to cert-advisory-request@cert.org 

Coast Mailing List 

See http://www.cs.purdue.edu/coast/coast.html 

IDS Mailing List 

Send "subscribe ids" to majordomo@wyrm.cc.uow.edu.au 

CIAC Mailing List 

See http://ciac.llnl.gov/ 

Subscribe to security news groups


*	comp.security.unix 
*	alt.security 
*	comp.security.announce 
*	alt.security.pgp 
*	alt.security.keydist 
*	alt.security.ripem 
*	comp.security.unix 
*	comp.protocols.kerberos 
*	comp.virus 
*	comp.risks 
*	Create internal mailing lists 

Employee Awareness Issues 

Ensure security policies are in place and enforced. A good employee 
awareness program is crucial to ensuring that employees understand the 
risks and the reasoning for the amount of effort needed in company 
security programs.
Your security awareness program should include posters, seminars, and 
memos that provide employees with informational items on security facts, 
even including news clippings of recent security events.

Without employee involvement, security enforcement becomes extremely 
difficult, if not impossible to maintain at a high confidence level. 

Obtain security related tools 

Tripwire, SWATCH, S/KEY, Argus, SATAN, COPS, npasswd+, ISS, anlpasswd, 
binaudit, chrootuid, Courtney, crack, deslogin, dialup2.0, etherprobe, 
etherman, interman, ip_fil, ipacl, TCP Wrapper, logdaemon, netaccess, 
netlog, nfswatch, nping, tcpr, tiger, etc (see 
ftp://coast.cs.purdue.edu/pub/tools/) 

Other Security Sites available 

Computer & Network Security Reference Index 

http://www.telstra.com.au/info/security.html 

Computer Security Resources 

http://www.sparc.com/charles/security.html 

NASA 

http://nasirc.hq.nasa.gov/ 

8LGM 

http://www.8lgm.org/home.html 

Security Links 

http://www.c3.lanl.gov/~mcn/cseclinks.html 

Cryptography 

http://www.itr.ch/~pheinzma/crypt.html 

HTTP Security Group at W3C 

http://www.w3.org/hypertext/WWW/Security 

Firewall Summaries 

http://iwi.com/pubs/fwform-intro.html 

Network Security & Firewalls 

http://www.tis.com/Home/NetworkSecurity.html 

SAIC 

http://mls.saic.com 

Unix Security 

http://ausg.dartmouth.edu/security.html 

Unix Security 

http://www.alw.nih.gov/Security/security.html 

COAST 

http://www.cs.purdue.edu/coast/coast.html 

Network/Computer Security Technology 

http://www.tezcat.com/web/security/security_top_level.html 

FIRST 

http://www.first.org 

SECURITY PROGRAMS 


*	Exposure Analysis 
*	COPS 
*	SATAN 
*	ISS 
*	Tripwire 
*	Crack 
*	Securescan 
*	Authentication and Control 
*	S/Key 
*	SSH 
*	Kerberos 
*	Crack 
*	NPPASSWD 
*	Encryption 
*	SSH 
*	Kerberos 
*	STEL 
*	DESlogin 
*	PGP 
*	Access Control 
*	IPACL 
*	TIS FWTK 
*	chroot 
*	dialup2.0 
*	ip_fil 
*	portmap_3 
*	rpcbind 
*	tcpr 
*	Log monitoring 
*	Netlog 
*	ARGUS 
*	Gabriel 
*	Courtney 
*	log_tcp 
*	logdeamon 
*	nfswatch 
*	pmon 

These tools are available at:  ftp://coast.cs.purdue.edu/pub/tools 

SECURITY RELATED BOOKS 

Bill Cheswick and Steve Bellovin. Firewalls and Internet security: 
Repelling the Willy Hacker. Addison-Wesley
David A. Curry. Unix System Security: A guide for Users and System 
Administers. Addison-Wesley

Rik Farrow. Unix System Security: How to Protect Your Data and Prevent 
Intruders. Addison-Wesley

Simon Garfinkel and Gene Spafford. Practical Unix Security. O'Reilly and 
Associates

Katie Hafner and John Markoff. Cyberpunk: Outlaws and Hackers on the 
Computer Frontier. Simon & Schuster

Bruce Sterling. The Hacker Crackdown: Law and Disorder on the Electronic 
Frontier. Bantam Books

Cliff Stoll. The Cuckoo's Egg: Tracking a Spy Through the Maze of 
Computer Espionage. Doubleday

Steve Levy. Hackers: Heroes of the Computer Revolution. Dell Books

Karanjit Siyan and Chris Hare. Internet Firewalls and Network Security. 
New Riders Publishing

Nichelle Slatalla and Joshua Quittner. Masters of Deception: The Gang 
that Ruled Cyberspace. Harper Collins

Charlie Kaufman, Radia Perlman and Mike Speciner. Network Security: 
Private Communications in a Public World. Prentice Hall 

ADDITIONAL RECOMMENDATIONS: 

1) Make use of one time password technologies 


*	S/KEY 
*	SecurID 
*	Kerberos V 
*	Digital Pathways 

2) Encryption 


*	Link encryption - Encrypt sensitive data links 
*	Semaphore 
*	Cylink 
*	Data Encryption - Encrypt sensitive email 
*	PGP 
*	TIS/PEM 
*	File Encryption - Encrypt sensitive data online 
*	RSA 
*	PGP 
*	DES 


3) File Access Policies 

Ensure file access policies are established so that only authorized 
users can access files. 

4) MD5 Checksum File 

A common attack on internal systems by computer hackers is to replace 
system programs with modified versions, used to either hide their 
access, or allow them to access the system through "backdoor" methods. 
It is a good idea to compare active, critical binaries on your system 
with a master list of valid binary checksums. MD5 is the preferred 
method, as computer hackers can easily make modifications to such 
programs that fool standard checksum programs.
Several programs exist to allow this functionality, including TRIPWIRE 
and TAMU's TIGER. 

5) User access histories 

Use of the shell history feature (e.g., csh .history, or .bashistory, 
etc) provides an additional auditing feature in your security model 
arsenal. Use of this feature may allow you the ability to identity 
possible system abuse by examining these history files for any unusual 
or suspicious command sequences. 

6) Enforce password change cycles 

If you MUST use reusable, disclousable passwords, ensure that the 
passwords are maintained with an expiration date to force password 
change cycles. The more a static password is used, the more chances of 
that password being disclosed or compromised. 

COMMON EXPOSURES 

1) Social Engineering 

This, by far, is the number one exposure relating to compromise of 
information. Social Engineering is the process in which an unauthorized 
individual attempts to represent themselves as an internal employee or 
another trusted party to gain information. 

2) Poor Passwords 

Users tend to pick easy to remember passwords, which equate into easy to 
guess passwords for unauthorized users. 

3) Sendmail 

There are several older versions of sendmail that provide the ability 
for unauthorized users to gain unauthorized access to a system. 

4) NFS 

Network File System protocol attacks are very common due to poor 
security export controls of available file systems. 

5) Sniffable Traffic 

A common attack by unauthorized users is to place "sniffing" programs on 
compromised systems used to collect other account information (e.g., 
usernames and passwords). This can be used to expand the scope of an 
intruders attack to attack and compromise multiple systems within your 
network. Whenever possible, make use of one-time password schemes.


6) WEB Server Security 

There is a significant dependance on the WEB for day-to-day and mission 
critical Internet activities; Indeed the WEB is the future of the 
Internet and if we're not careful, its next downfall.
The WEB's greatest strength, its flexibility, is also its greatest flaw. 
CGI scripts that provide functionality for your users, can open the door 
to intruders. 

In addition, WEB Servers can be programmed to index available 
information, and sometimes can be accidentify configured to index too 
much information. (Ever try to search for the word "/etc/passwd" at 
www.altavista.com?). 

The following guidelines can be used to help ensure that your WEB Server 
environment is secured:


*	Limit server access to a specific area on the host. Some Web Servers, eg 
OMI, offer a chroot directive in in the configuration file. Others can 
be chrooted using the chroot utility, although this typically involves 
copying some system libraries and device files.
*	Set user ID and group ID to nobody to run HTTP server. Make sure that no 
files or directories other than WEB log data, are writable by user/group 
nobody.
*	Map document root to a specific directory, client can only access that 
area.
*	Disable directory index unless it is necessary.
*	Enforce to use secure protocal (shttp, https, PCT) to access sensitive 
documents and regions require password.
*	Set allowed hosts list, only those hosts can access private/sensitive 
documents.
*	Protect key database and server password (use to encript the server 
key), ie set file mode to 600.
*	Secure transfer all files may contain passwords (eg server core dump, 
configuration file, key file, etc).
*	Review server logs frequently for signs of misuse and attempted 
breakins.
*	Do not put script language interpreter in cgi bin.
*	Never pass user input directly to an interpreter (e.g, /bin/sh, 
/bin/perl, etc).
Scrub all input data for malicious content such as shell 
meta-characters. User input should be considered to include all fields 
in an HTML form, including hidden fields that the users weren't supposed 
to modify. User input should also include environment variables set by 
the server such as the name of the remote host or remote user.
For detail CGI script security, please visit following sites: 
*	http://hoohoo.ncsa.uiuc.edu/cgi/security.html 
*	http://www.cerf.net/~paulp/cgi-security 
*	http://www.csclub.uwaterloo.ca/u/mlvanbie/cgisec 

*	Disable other network based applications that aren't used by the server.
*	Ensure used network based applications are secured (e.g., smtp, ftp, 
etc)
*	If using a WEB based administrative tool, ensure you restrict access to 
only authorized systems (via IP address, rather than hostname). Always 
change default passwords.
*	Ensure you know what files are accessable via the WEB Server. (e.g., 
many sites unknowningly allow access to "/etc/passwd", allowing 
unauthorized users to identify guessable passwords).

This document can be obtained in updated form from 
 http://www.security.mci.net/web-security.html 







7) Denial Of Service Attacks

Denial Of Service Attacks, the most recent Internet Plauge, are having 
dramatic effects on the service and stability of its victims.

Although not new, the increased accessability of the Internet and the 
ever decreasing age and sophistication of the average computer hacker, 
is resulting in an enourmous surge in the type of attack which is 
specifically and soley intended to deny service to the system or 
application. In many cases, the exploit code to conduct these attacks 
are freely available on the Internet, and can effect the stability of 
systems by a few keystokes and mere click of the mouse.

These attacks take advantage of deficiencies in the TCP/IP protocal, 
used as the baseline of communications on the Internet, and are 
difficult, if not impossible, to trace to their source since the packets 
can be "spoofed" or "forged" as coming from any source on the Internet.

Several types of attacks exist:

* SYN ATTACK

PROBLEM:


All systems on the Internet which accept TCP connections are susceptible 
to a SYN attack. 
From CERT Alert CA-96.21: 

"When a system (called the client) attempts to establish a TCP 
connection to a system providing a service (the server), the client and 
server exchange a set sequence of messages. This connection technique 
applies to all TCP connections--telnet, Web, email, etc. 

The client system begins by sending a SYN message to the server. The 
server then acknowledges the SYN message by sending SYN-ACK message to 
the client. The client then finishes establishing the connection by 
responding with an ACK message. The connection between the client and 
the server is then open, and the service-specific data can be exchanged 
between the client and the server. Here is a view of this message flow: 


Client Server
------ ------
SYN--------------------> 
<--------------------SYN-ACK 

ACK--------------------> 

Client and server can now send service-specific data 


The potential for abuse arises at the point where the server system has 
sent an acknowledgment (SYN-ACK) back to client but has not yet received 
the ACK message. This is what we mean by half-open connection. The 
server has built in its system memory a data structure describing all 
pending connections. This data structure is of finite size, and it can 
be made to overflow by intentionally creating too many partially-open 
connections. 


Creating half-open connections is easily accomplished with IP spoofing. 
The attacking system sends SYN messages to the victim server system; 
these appear to be legitimate but in fact reference a client system that 
is unable to respond to the SYN-ACK messages. This means that the final 
ACK message will never be sent to the victim server system. 

The half-open connections data structure on the victim server system 
will eventually fill; then the system will be unable to accept any new 
incoming connections until the table is emptied out. Normally there is a 
timeout associated with a pending connection, so the half-open 
connections will eventually expire and the victim server system will 
recover. However, the attacking system can simply continue sending 
IP-spoofed packets requesting new connections faster than the victim 
system can expire the pending connections. 

In most cases, the victim of such an attack will have difficulty in 
accepting any new incoming network connection. In these cases, the 
attack does not affect existing incoming connections nor the ability to 
originate outgoing network connections. 

However, in some cases, the system may exhaust memory, crash, or be 
rendered otherwise inoperative. 

The location of the attacking system is obscured because the source 
addresses in the SYN packets are often implausible. When the packet 
arrives at the victim server system, there is no way to determine its 
true source. Since the network forwards packets based on destination 
address, the only way to validate the source of a packet is to use input 
source filtering..." 


SOLUTIONS: 


The SYN Attack rests at the very core of identified weakness of the 
TCP/IP protocal, and are difficult, if not impossible in some cases, to 
correct. 

Things you can do: 

o Deploy System Operating Patches

Several vendors have released operating system patches to compensate and 
react to SYN attacks. Check with your operating system vendor(s) to 
ensure you have patched, at least, your publically available sites.

o Deploy Monitoring Systems 

Several Intrusion Detection Systems now look for SYN attacks. Ensure you 
have a monitoring and reporting procuedure in place. Some vendors that 
sell SYN based detectors are: 
ISS: 

http://www.iss.net/RealSecure 
Checkpoint: 

http://www.checkpoint.com/fw21/syndefender/index.html 

o Report abuse to your Internet Service Providor 

When a Denial Of Service attack is detected on your systems, contact the 
Security Department of your Internet Service Providor to have them 
assist in tracking down the source of the active attack. 

More information on the SYN attack and its back ground can be obtained 
from : http://www.fc.net/phrack/files/p48/p48-13.html 





* ICMP or PING FLOOD ATTACK 



PROBLEM:


Unauthorized users can disrupt your service or consume your available 
network bandwidth by sending a constant stream of forged ICMP packets to 
your system(s). 
Known as a "Ping Flood" attack, computer hackers send a steady stream of 
PING packets (known as "echo request" packets) to your system(s). In 
many cases, this flood of traffic can consume system resources, and even 
consume significant amounts of bandwidth on mid to low speed connections 
(eg; T1 and below). 


SOLUTIONS:




o Block Traffic 
In most cases, you can simply deny ICMP packets on your network 
firewalls to prevent the traffic from effecting your systems. However, 
since the traffic is still traversing your access line, you need to 
ensure your Internet Service Providor is involved. 


o Report abuse to your Internet Service Providor 

When a Denial Of Service attack is detected on your systems, contact the 
Security Department of your Internet Service Providor to have them 
assist in tracking down the source of the active attack. 


* MAIL BOMB 



PROBLEM:

Unauthorized users can send large amounts of large email messages to and 
through your email server, often filling up disk space on your mail 
system, denying email services to other users. 

These attacks usually involve the unauthorized user(s) sending thousands 
of large binary attachments to a single or multiple valid users on your 
server (or spooling through your server in attack against someone else, 
using your server to hide his tracks). 

Once the disk fills up, additional messages are rejected by the server. 

SOLUTIONS: 


o Deploy monitoring systems 

Ensure your monitoring systems monitor the number of messages coming 
into your server, and reporting sudden spikes in traffic. 
In addition, monitoring systems should check for active disk space on 
your systems, and reporting when your partitions are in jepordy. 


o Ensure mail spool areas are on large, dedicated disk partitions 

Ensure that your mail spool and log directories would not effect other 
aspects of the system if they where filled. 
For example, having the mail spool, queue and/or users mail directories 
on a Unix ROOT file system may effect the available of the system itself 
if the system was subject to a successfull Denial Of Service Attack. 


o Report abuse to your Internet Service Providor 

When a Denial Of Service attack is detected on your systems, contact the 
Security Department of your Internet Service Providor to have them 
assist in tracking down the source of the active attack. 


* SYSLOG and SNMP Bombs




PROBLEM:


This issue is much like the MAIL BOMB ATTACK. 
Unauthorized users can send large amounts of large log messages to your 
logging server, often filling up disk space on you system, denying 
collection of additional logging data. 

These attacks usually involve the unauthorized user(s) sending thousands 
of large log messages to your server. 

Once the disk fills up, additional messages are rejected by the server. 


SOLUTIONS:



o Deploy monitoring systems 

Ensure your monitoring systems monitor the number of log messages coming 
into your server, and reporting sudden spikes in traffic. 
In addition, monitoring systems should check for active disk space on 
your systems, and reporting when your partitions are in jepordy. 


o Ensure log directories are on dedicated disk partitions 

Ensure that your mail spool and log directories would not effect other 
aspects of the system if they where filled. 
For example, having a log message directory on a Unix ROOT file system 
may effect the available of the system itself if the system was subject 
to a successfull Denial Of Service Attack. 


o Report abuse to your Internet Service Providor 

When a Denial Of Service attack is detected on your systems, contact the 
Security Department of your Internet Service Providor to have them 
assist in tracking down the source of the active attack. 


Updated information on Denial Of Service Attacks (DoS) and identified 
corrective measures can be found at: 
http://www.security.mci.net/dos.html. 








8) WEB Broswer Security Issues 


Many people "surf the web" under the mistaken impression that their 
identity is anonymous to the sites that they visit and, in some cases, 
to the network that they surf on.

Your WEB browser may be providing information to WEB Servers without 
your knowledge, or your permission. In some cases, WEB servers may be 
uploading a "tracer" to your browser to a) track your activity on the 
WEB and b) track how many times you visit a particular WEB site. This 
activity can be used, for example, by Marketing organizations for mass 
or even individualized WEB advertising. 

This information can be obtained in several ways:


*	WEB Server Transaction Logs

PROBLEM:
When you make connections to a WEB Server, the server automatically 
collects a significant amount of information about you, including; 1) 
your IP address (eg; which can provide information on your geographic 
location, and your Internet Service Providor), 2) your browser software 
type and 3) the Operating system type and version of your computer.

SOLUTION:

Ensure that your providor is not involved in the selling or distribution 
of specific traffic analysis, including Marketing organizations and 
mailing list providors. In addition, "Anonymous Surfing" servers are 
available to hide the users origination (IP address) from the end WEB 
server. The Anonymizer is one such service.


*	Browser "cookies"

PROBLEM:
Web Servers can upload activity bookmarks or "cookies" to your browser, 
which provide information to the server on your activity on that system, 
and possibly even other systems. (Now, cookies are used for other 
purposes as well, like authentication and state information, but are 
being missused for things like Marketing tracking) Have you ever 
connected to a WEB site that had an advertisement banner on one (or all) 
of the pages? In most cases, that advertisement banner is being pulled 
from a remote advertisement web server and delivered to your browser. 
When the advertisement server delievers its ad to the browser, it also 
places a "cookie" on your system, indicating what server you visited 
when you got the banner.

If you visit a lot of web servers that use that avertisement server, 
then you'll have lots of cookies on your browser. Everytime the 
advertisement server places a cookie on your system, it will check for 
other cookies its placed there. This information is used to track your 
activity on the WEB, as well as see how many times you've visited a 
particular site.

Marketing groups use this to identify what sites are getting visited the 
most, and from what regions of the country, but its also used to provide 
individual marketing "opprotunities".

Imagine visiting your favorite web page, and seeing an advertisement 
specifically tailored to your tastes, with your name! "Hey Dale, since 
you've visited the Pepsi page so many times, click here and we'll give 
you $1 off your next case of Pepsi!". Or recieving an email from Coke; 
"Dear Dale, instead of buying Pepsi, we think you should buy Coke, 
here's $2 off!".

SOLUTION:

Most browsers provide you with the option of alerting the user about 
Server-side cookies. In Netscape, the Preferences section has an option 
for "Protocals", with the option to prompt before accepting Cookies.


*	Browser icons

PROBLEM:
Like "cookies", browser icons can be used by Marketing organizations to 
track your activity on the web.

When you connect to a WEB page, that page may be fetching icons or 
graphics which are located on other servers; in some cases, 
advertisement servers, which can use this to track your activity on the 
WEB.

SOLUTION:

There are no easy answers to this, as you are typically a "victim" 
before you know what has happened. To identify if a WEB server is 
serving you browser icons from an advertisement server, you can pull the 
raw HTML from that site (using the "document view" feature in your 
browser to see if the server is obtaining icons from other web servers.






9) DNS Naming Conventions

DNS is the service that lets you map IP addresses to hostnames, and vis 
versa. When connecting to the Internet, great care should be taken into 
how your hostnames are picked, as they can be used by "bad guys" to 
obtain potientially useful information on the makeup of your internal 
network, potiential projects that you are involved in or names of 
employees to target for Social Engineering.






It is quite trivial for an unauthorized user to pull every hostname out 
of your DNS tree. Should these hostnames represent potientially 
confidential or sensitive information, the attacker can use that to gain 
additional information about your organization.

For example: 

billspc - Would tell an attacker the owners name, and the type of 
machine.
adminstation1 - Tells the attacker that this machine is probably used 
for administrative purposes.
cisco-test-5 - Tells the attacker that you are in the process of testing 
something with Cisco.

One solution to this problem is to run two DNS servers; one external and 
one internal. However, a significant amount of administrative overhead 
comes into play with this.





OTHER CONSIDERATIONS 

The following are bulletined items of considerations that should also be 
taken into account when developing a comprehensive security status for 
your networks and systems. These items are only provided as a reference, 
and additional documentation is required to fully understand the nature 
of these concerns: 

1) Network Security Policies and Procedures 

Comprehensive security and network polices need to be developed and 
deployed widely within the company 

2) Backups 

Ensure you have appropriate backup policies, and off-site storage 
considerations 

3) Physical Security 

Ensure physical access to sensitive systems is reviewed on a regular 
basis. 

4) Information Security 

Paper based information should be properly marked and controlled, as 
well as disposal of such information 

5) Contractors/Vendors 

Policies and procedures should be taken into account for non-company 
employees. This includes restricted shells, secure access, etc. 

6) Human Resource Termination Lists 

Security and Administrative personnel must obtain the ability of being 
notified appropriately when employees, contractors, vendors and other 
users have left the company, and when such access needs to be removed 
from systems and applications. 

7) Employee Education Issues 

Routine educational awareness seminars must be provided to company 
employees to make them fully aware of security-related issues to ensure 
that they relate their day-to-day activities in association with the 
educational seminaries they have had. Emphasis should be paid to 
upper-management to ensure their support is obtained. 

8) Encryption 

Use of encryption to protect sensitive links is a valuable tool to 
ensure compromise of confidential information is not compromised. 
Encryption models can be used to protect email traffic (eg; via the use 
of PGP or TIS/PEM) as well as session data (eg; the use of software of 
hardware modules to encrypt traffic between two machines/networks). 

9) Inventory 

Make an inventory of the network elements contained in the network, what 
their purpose or function is, and who administers that system. This 
information can be invaluable when responding to security incidents or 
assessing proper network security models. 

10) Network Maps 

Ensure you are aware where all of your external interconnects are, how 
internal systems are connected, and who they are connected to. 

11) Prefix Scanning 

Routinely scan your company's local telephone prefix to identify 
unauthorized dial-up modems connected to internal systems. 


------------------------------------------------------------------------
ddrew@mci.net |Security Engineering Home | Last Modified 08-Dec-96