\\\\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