CIAC NotesCIAC Notes
Bruce Oliver
Westinghouse Hanford Network Security
e-mail e40483@rl.gov
Westinghouse Hanford Company, DOE Richland, has developed software to help manage and install CIAC security patches on UNIX computer systems. Security patches defined in CIAC bulletins are obtained from computer vendors and evaluated. The security patches which are determined to be applicable to the Richland site are distributed to UNIX system administrators via an anonymous FTP server in the form of a patch install package. Install packages contain programs and documentation for the installation of patches across multiple UNIX platforms using one standard automated process.
The patch manager programs provide an easy-to-use interface, that is common across platforms. The use of these programs has helped to increase security compliance, reduce cost, and provide better methods for the tracking and auditing of patches. System Administrators have the capability to back-out security patches and perform a patch install simulation and verification. The verification scripts allow for audits to be performed for a given system. The CIAC patches are managed by patch numbers.
The software for managing the patch install packages can be difficult to maintain and implement because of the diversity of UNIX hardware platforms and operating system levels. The software was developed specifically to meet the needs and requirements of the Richland site so it might require customizing the Patch Manager software to meet the requirements of another site.
If you are located at a DOE government site and want more details or information on the Patch Manager software contact Bruce Oliver at e40483@rl.gov. Please refer all other questions to ciac@llnl.gov.
The following are samples of the process and the steps a System Administrator would use along with the read me documentation.
Platform Patch Name Patch Number Location on systech ----------------------------------------------------------------------- SunOS 4.1.x sendmail 100224-06 pub/sun/patch/mail_100224.tar.Z SunOS 4.1.x mail 100377-08 pub/sun/patch/smail_100377.tar.Z SunOS 4.1.x loadmodule 100448-02 pub/sun/patch/ldm_100448.tar.Z SunOS 4.1.x modload 101200-02 pub/sun/patch/mdl_101200.tar.Z Solaris 2.2 expreserve 101090-01 pub/solaris/patch/101090-01.tar.Z Solaris 2.2 sendmail 101077-03 pub/solaris/patch/101077-03.tar.Z Solaris 2.3 sendmail 101371-03 pub/solaris/patch/101371-03.tar.Z Solaris 2.x fsckfail E06 pub/solaris/patch/fsckfail_E06.tar.Z HP hp-ux 8.x ypbind 1707 pub/hp/patch/ypb_1707.tar.Z (NIS HOSTS ONLY) DEC xterm 4034 pub/dec/patch/xterm_4034.tar.Z (ULTRIX 4.3 ONLY)Check the file pub/patch.lst for a complete listing of CIAC patches.
NOTES:
There currently are no patches required for SGI (IRIX) or IBM (AIX)
systems. The SunOS sendmail and loadmodule patches are updated
versions of existing patches. The new versions must be installed in
place of the old.
% ftp systech Connected to systech.rl.gov. 220 systech FTP server (SunOS 4.1) ready. Name (systech:e6b564): anonymous --> Enter anonymous for user account 331 Guest login ok, send ident as password. Password: --> Password is entered. 230 Guest login ok, access restrictions apply. ftp>Example of getting a tar file off of systech:
ftp> cd pub/sun/patch ftp> bin --> set binary mode for binary type files ftp> get exp_101080.tar.ZExample of how to untar the file on your workstation:
% zcat exp_101080.tar.Z | tar xf - % rm exp_101080.tar.Z --> once untarred you can delete the tar file.A directory named patch is created by the zcat command and contains documentation and scripts for installing the patch.
The script patch_ins (pi) is used to install patches, while patch_deins (pd) is used to deinstall patches. The following arguments can be used when executing the scripts:
-d (simulate install of the patch) -o filename (specify an output file) -f (force install, no confirmation prompt)Example:
pi (patch name) -d -o /tmp/patch.log
pub/patch_process.doc Process for implementing security patches on
UNIX workstations.
pub/patch_policy.doc Policy for implementing security patches on UNIX
workstations.
This is summary documentation for a given patch:
Quick Readme file, sun CIAC patch 101665-02, OS 4.1.3_U1 sendmail patch a) Purpose Fix security problems with the sendmail daemon b) Scripts patch_ins (pi) (install the patch) patch_deins (pd) (deinstall the patch) c) Output Files Default output file: log/patch_ins-(host)-(YYMMDD).log example: log/patch_ins-systech-931012.log You can optionally specify your own output file. Examples: # patch_ins sendmail -o /tmp/patch.log d) Simulation Simulate patch install: # pi sendmail -d Check for errors output by the script (messages with a -E or -W). Check the commands that would be executed by the patch if it were running in live mode. e) Install Install the patch: # pi sendmail The force option can be specified to disable the confirmation prompt. # pi sendmail -f Check for errors output by the script (messages with a -E or -W). If there were problems use patch_deins to deinstall.Detail Readme file for a given patch install scripts:
NAME patch_ins, pi - patch install script patch_deins, pd - patch deinstall script SYNOPSIS patch_ins [patch name] [-d ] [-f] [-o outfile] DESCRIPTION The patch install scripts provide an automated means of installing CIAC and functional patches on unix workstations. Platforms supported: sun 4.1.x , sun (solaris) 5.x, hp, sgi, ibm, dec, dg OPTIONS patch name Name of the patch to be installed. This argument must be first on the command line ($1). The Patch name can be abbreviated. The file patch.lst contains a list of patch names and descriptions for the different unix platforms. You can not specify a patch which is not valid for your platform and architecture. Examples: # patch_ins expreserve # pi lpd -d Run the install script in simulation or dummy mode. Commands are echoed out but not executed. Confirmation prompts are ignored. Example: # patch_ins lpd -d -f Force the install or deinstall of the patch. No confirmation of the install or deinstall of the patch is performed. The -f option is ignored if -d is specified. Example: # pi exp -f -o output file Specify a script output file. This overrides the default script file. The file name must be specified and can be a relative or full pathname. Default output file format: log/(script name)-(host)-(YYMMDD).log example: log/patch_ins-systech-931012.log Example: # pi exp -o /tmp/patch.log MENU MODE If no options are specified then patch_ins and patch_deins run in menu mode. In menu mode you are prompted to use the default script log file. Entering "y" or pressing RETURN takes the default. If you enter "n" you are prompted to enter a new log file. You then enter the Patch Install Menu where you are prompted to select a patch to install. After you specify a number from the menu then you are prompted on whether to simulate the install. The default response is "y" if simulation has not yet been run for the patch. The default is "n" if simulation has already been run. Example of menu mode on a Sun system: # patch_ins Use script log file: log/pi-systech-931012.log [y] **** pi, version 1.5, 09/30/93 14:36:12 **** Host: systech, sun4c, OS 4.1.3 Patch install Menu (ver 1.5) ----------------------------- 1. expreserve patch, #101080 2. loadmodule patch, #100448 3. lpd patch, #100305 4. mfree patch, #100567 5. nfs patch, #100173 6. permissions patch, #100103 7. /bin/mail patch, #100224 Enter your selection or press RETURN to exit 1 Simulate install (y or n) [y] Entries are only listed in the Patch Install Menu if files exist for the patch in the patch directory. MESSAGES If no patches are found which are valid for your platform and architecture then the patch install script exits with the following message: No patches found which are applicable for host (hostname) If valid patches are found but no corresponding install directories or files exist then the patch install script exits with the following message: Valid patches were found for host (hostname) but NO corresponding install directories were found If a patch is already installed and you try to install it, you get the following message: Warning: (patch name) patch appears to be already installed on host (host name) If a patch is not installed and you try to deinstall it, you get the following message: Warning: (patch name) patch DOES NOT appear to be installed on host (host name) ERRORS Errors while executing the patch install scripts have the following format: (script name)-(error code), (function name) error message Example: patch_ins-E, (pat_ins) error executing patch install commands Error codes are "E" for errors or "W" for warnings. All error and warning messages are written to the script log file. If errors or warnings occur installing a patch then the patch_deins script can be used to back out the patch.
The greatest and worst characteristic of the Internet is that any single user is capable of making as little or as much noise as he/she pleases. While free discussion and communication is the trademark of a free society, its abuse can create severe problems for the Internet community.
Monty Python's Flying Circus has a humorous sketch on the abundance of foods that spam goes with, from eggs and bacon to lobster. No matter what the main dish was, spam was the side dish.
While Monty Python's sketch is amusing, the "spamming" that occurs on the Internet is considerably less so. Spamming, in Internet terms, is the practice of distributing a message to anyone who could possibly read it, utilizing email, but more commonly, Usenet groups. Spamming is the Internet equivalent of junk mail.
Several famous spammings have occured in recent years. The "Green Card Lottery" message, an advertisement for a law firm, was distributed to thousands of Usenet groups. The numerous angry responses that resulted made the drain on bandwidth and disk space even greater. Another incident, with the posting of a message titled "MAKE.MONEY.FAST" was an electronic chain letter.
One DOE site was recently spammed with an inappropriate message to over 5000 users. So many messages were received that the mail queue filled up completely, and no legitimate mail was allowed through.
Spamming is not the only communication problem encountered on the Internet. Several "urban legends" have made considerable waves in the electronic community. The most recent example is the "Good Times Virus" hoax. A few students sent out a few messages warning of dangerous email messages containing viruses in their body. These mail messages would supposedly have a subject of "Good Times". The hoax took on a life of its own, as concerned system administrators forwarded the warning to all their users. The result was wasted time and resources, and angry Internet users.
Spamming on the other hand, can be protected against in several ways. First, always put the mail queue on a separate partition. If the mail queue fills up, at least the entire system won't be brought to its knees.
Another, more severe protection, is to filter out mail from unknown sites. This can be done by having inetd control sendmail, and then using tcp_wrappers around sendmail to control which sites execute it. While this won't help all problems and can be overkill, it will at least insure that mail is coming from the proper router. The package tcp_wrappers can be found here.
Netware 3.1x has some very powerful security features built in, although many of these features are disabled by default. Out of the box, Netware is not a very secure Network Operating System (NOS). Immediately upon installation, the SUPERVISOR account has no password, and will never be required unless actions on the system administrator's part are taken. This was most likely done to simplify the installation of a Netware system and make it a viable option for small organizations where security is not an issue. I have seen several Netware LANS with a handful of nodes where every user account had full rights to everything on the server. This may be alright (although not very wise) for some organizations, but intolerable in areas where information must be kept secure from any one of hundreds of potential problems. Don't throw out your Netware servers just yet! I said that out of the box, Netware was not a secure very secure NOS. User account defaults can be changed very to make Netware as tight a NOS as you wish. We'll discuss some of the security features that should be changed before creating user accounts. All the security features discussed are set within the SYSCON utility, and most are found on the Default Account Balance/Restrictions screen.
The front line in any security system is the password. While debate continues as to the effectiveness of passwords, their use as the primary means of authentication will continue for many years to come. When changing the Require Password option from NO to YES, other password options become available. Minimum Password Length has a default of five characters. This is probably sufficient for most installations. The next option is Days Between Forced Changes. This, along with the length of the password, determine much of the security of your system. Short passwords that are kept for long periods of time are security threats. No better are long passwords that are required for short periods of time; their users will undoubtedly write their frequently changing password on a post-it note and paste it on the screen. A balance of the two must be determined, and that factored in with the sensitivity of the information being protected. Require Unique Passwords should be set to YES to ensure that the same password is not reused over and over again.
Login restrictions on accounts may be imposed to prevent both authorized users and intruders from gaining access to the system. The most obvious is the Intruder Detection/Lockout feature. After a certain number of invalid login attempts, that user's account will be locked for the specified amount of time. The user, or intruder, will be unable to login to their target account until that time has passed, unless the system administrator removes the lock from the account. The Default Time Restrictions will prevent users from accessing the system after hours, or when they are not supposed to be, such as during a backup. You can set the Limit Concurrent Connections option to prevent an authorized user from logging in to multiple workstations. And if a user is to login to certain workstations, the Station Restrictions can be set for each individual user to limit the which workstations the user can login to.
These are some of the features available to Netware 3.1x preventing access to a Netware server. These are by no means the end to Netware's security structure. Once logged in, the user is still subject to directory and file restrictions, as well as auditing. Although it comes out of the box a very passive and insecure system, Netware can be brought up to acceptable levels of security, with a small amount of effort on the system administrator's part.
Topics to be discussed include preventive meaures, tools for incident handling, awareness building, and legal issues with specific emphasis on international issues. More information can be found at FIRST.
F-01
Advisory SGI IRIX serial_ports Vulnerability
Oct. 4, 1994
1600 PDT
F-02
Bulletin Summary of HP Security Bulletins
Nov. 17, 1994
1300 PDT
F-03
Bulletin Restricted Distribution
F-04
Bulletin Security Vulnerabilities in DECnet/OSI
for OpenVMS
Nov. 28, 1994
0900 PDT
F-05
Bulletin SCO Unix at, login, prwarn, sadc, and
pt_chmod Patches Available
0800 PDT
Dec. 06, 1994
F-06
Bulletin Novell UnixWare sadc, urestore, and suic_exe
Vulnerabilities
Dec. 14, 1994
0800 PDT
F-07
Bulletin New and Revised HP Bulletins
Jan. 20, 1995
1300 PST
F-08
Advisory Internet Address Spoofing and Hijacked
Session Attacks
Jan. 23, 1995
1100 PST
F-09
Bulletin Unix /bin/mail Vulnerabilities
Jan. 27, 1995
1030 PST
F-10
Bulletin HP-UX Remote Watch
Feb. 6, 1995
1200 PST
F-11
Advisory Unix NCSA httpd Vulnerability
Feb. 14, 1995
1030 PST
F-12
Bulletin Kerberos Telnet Encryption Vulnerabilty
Feb. 21, 1995
1000 PST
F-13
Bulletin Unix Sendmail Vulnerabilities
Feb. 22, 1995
1600 PST
F-14
Bulletin HP-UX Malicious Code Sequences
Feb. 23, 1995
1200 PST
F-15
Bulletin HP-UX "at" and "cron" vulnerabilities
Feb. 23, 1995
1200 PST
F-16
Bulletin SGI IRIX Desktop Permissions Tool Vulnerability
Mar. 8, 1995
1500 PST
subscribe list-name LastName, FirstName PhoneNumber subscribe list-name LastName, FirstName PhoneNumberas the E-mail message body, substituting CIAC-BULLETIN, CIAC-NOTES, SPI- ANNOUNCE or SPI-NOTES for list-name and valid information for LastName FirstName and PhoneNumber. Send to: ciac-listproc@llnl.gov (not to: ciac@llnl.gov) e.g.,
subscribe ciac-notes O'Hara, Scarlett W. 404-555-1212 x36 subscribe ciac-bulletin O'Hara, Scarlett W. 404-555-1212 x36You will receive an acknowledgment containing address, initial PIN, and information on how to change either of them, cancel your subscription, or get help. To subscribe an address which is a distribution list, first subscribe the person responsible for your Distribution list. You will receive an acknowledgment (as described above). Change the address to the distribution list by sending a second E-mail request. As the body of this message, send the following request, substituting valid information for list-name, PIN, and address of the distribution list:.
Send E-mail to ciac-listproc@llnl.gov:
set list-name address PIN distribution_list_addresse.g.,
set ciac-notes address 001860 rE-mailer@tara.georgia.orb
To be removed from this mailing list, send the following request:
unsubscribe list-name
For more information, send the following request:
help
If you have any questions about this list, you may contact the list's
owner: listmanager@cheetah.llnl.gov.
Use FTP to access it either by name or IP address (128.115.19.53). The operation and prompt will depend on which vendor's FTP you are running. Usually, you must first log in before you can list directory contents and transfer files. Use "FTP" or "anonymous" for Name or Foreign username unless given a general prompt such as ciac.llnl.gov> or FTP>. In that case, enter the keyword "user" or "login" before "FTP" or "anonymous" (e.g., user FTP). Use your Internet E-mail address for the Password. Once logged in you may type a question mark to find out what key-words are recognized. The file 0-index.txt (in the top level directory /FTP) is a document explaining the directory structure for downloadable files. The file whatsnew.txt (in directory /FTP/pub/ciac) contains a list of the new files placed in the archive. Use the command get [for single files] or mget [for multiple files] to download one or more files to your own machine.
No. E P TITLE
2300 x x Abstracts of the CIAC-2300 Series Documents
2301 x x Computer Virus Information Update
2302 Accessing The CIAC Computer Security Archives
2303 x x The Console Password Feature for DEC Workstations
2304 Data Security Vulnerabilities of Facsimile Machines
and Digital Copiers
2305 x Unix Incident Guide: How To Detect A Unix Intrusion
2308 x Securing Internet Information Servers
CIAC x Incident Handling Guidelines
LLNL x User Accountability Statement, E. Eugene Schultz, Jr.
SRI x Improving the Security of your Unix System, David
A. Curry
LLNL x Incident Handling Primer, Russell L. Brand
ORNL x Terminal Servers and Network Security, Curtis E. Bemis
& Lynn Hyman
To obtain further information, contact CIAC at 510-422-8193 or send
E-mail to ciac@llnl.gov. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes.
End of CIAC Notes Number 95-06 95_3_22
UCRL-MI-119788
[Notes Index]
[CIAC Home Page]
[Disclaimer]
Last modified: Thursday, 23-Mar-1995 17:40:17 UTC