UNIX Computer Security Checklist

The Australian Computer Emergency Response Team has developed a checklist which covers common and known security holes under the UNIX Operating System. It is based around recently discovered security vulnerabilities and other checklists which are readily available.

In order to make effective use of this checklist, readers will need to have a good grasp of basic UNIX system administration concepts. Follow the checklist closely and amend any problems that you encounter. We recommend that you use the checklist on a regular basis as well as after you install any patches or new versions of the operating system.

Where applicable, references will be made to points under discussion that relate to a specific vendor’s operating system, such as SunOS. In general, code examples have been written with SunOS 4.1.x in mind. Full directory paths and program options may vary for different varieties of UNIX. If in doubt consult your vendor documentation.

For ease of use, the checklist has been split into separate, loically cohesive sections. All sections are important. An abbreviated version of this checklist can be found in Appendix D.

* Retrieve the latest patch list from your vendor and install any patches not yet installed that are recommended for your system. Some patches may re-enable default configurations. For this reason it is important to go through this checklist AFTER installing ANY new packages.

NOTE: Be certain to verify the checksum information to confirm that you have retrieved a valid copy. This is important in any anonymous ftp transaction. If checksums are provided – use them! That said, it should be noted that checksums produced by /bin/sum should not be considered secure. Other more cryptographically strong methods such as md5 should be used. Refer to B.10 for md5 access information.

—————————————————————————— 2.0 Network security —————————————————————————— The following is a list of UNIX features that can be used to help prevent attacks from external sources.

* DO disable all “r” commands (rlogin, rsh etc.) unless specifically required. This may increase your risk of password exposure in network sniffer attacks, but “r” commands have been a regular source of insecurities and attacks. Disabling them is by far the lesser of the two evils. Refer to section 2.8 for details on how to do this. * DO filter ports 512,513 and 514 (TCP) at the router if you do use any of the “r” commands. This will stop people outside your domain from exploiting them but will not stop people inside your domain from exploiting them. To do this you will need to disable them (see above).

2.3 /etc/hosts.equiv

* CHECK that this file does not exist. It allows other hosts to be trusted by your system. Programs such as rlogin can then be used to log on to the same account name on a trusted machine without supplying a password.

If you must have such a file: * ENSURE that you keep only a small number of TRUSTED hosts listed. * DO use netgroups for easier management if you run NIS(also known as YP). * DO only trust hosts within your domain or under your management. * CHECK that you use fully qualified hostnames, i.e. hostname.domainname.au * ENSURE that you do NOT have a ‘+’ entry by itself anywhere in the file. * ENSURE that the first character of the file is not ‘-‘. (Refer to the CERT advisory CA-91:12 (see C.7)). * ENSURE that the permissions are set to 600. * ENSURE that the owner is set to root. * CHECK it again after each patch or operating system installation.

2.4 $HOME/.rhosts

* CHECK that no user has a .rhosts file in their home directory. They pose a greater security risk than /etc/hosts.equiv, as one can be created by each user. There are some genuine needs for these files, so hear each one on a case-by-case basis; eg. running backups over a network unattended. * DO use cron to periodically check for, report the contents of and delete $HOME/.rhosts files. Users should be made aware that you regularly perform this type of audit.

If you must have such a file * ENSURE the first character of the file is not ‘-‘. (Refer to the CERT advisory CA-91:12 (see C.7)). * ENSURE that the permissions are set to 600. * ENSURE that the owner is the same person who owns the account. * ENSURE that the file does NOT contain the symbol “+” on any line.

2.5 NFS

* DO disable NFS if you do not need it. Check your vendor supplied documentation for details on how to do this. * DO apply all available patches. NFS has had a number of security vulnerabilities. * DO filter NFS traffic at the router. Filter TCP/UDP on port 111 TCP/UDP on port 2049 This will prevent machines not on your subnet from accessing file systems exported by your machines. * DO enable NFS port monitoring. Calls to mount a file system will then only be accepted from port < 1024(root access). You should check your vendor’s documentation to see if this is an option for your version of UNIX. Under SunOS, to enable NFS port monitoring add the following commands to /etc/rc.local /bin/echo “nfs_portmon/W1” | /bin/adb -w /vmunix /dev/kmem > /dev/null 2>&1 rpc.mountd * DO use /etc/exports to ONLY export file systems you need to export. If you aren’t certain that it needs to be exported, then it probably doesn’t. * DO run fsirand for all your file systems. Firstly, check that you have installed any patches for fsirand. Then ensure the file system is unmounted and run fsirand. Predictable root handles assist crackers in abusing NFS. * CHECK that you never export file systems to the world. Use a -access=host.domainname.au option in /etc/exports. * DO export file systems read-only (option ro) whenever possible. See the man page for “exports”. * DO use the secure option if it is available. * DO use showmount -e to see what you currently have exported. * REMEMBER that changes in /etc/exports will only take effect after you run /usr/etc/exportfs. * CHECK that the permissions of /etc/exports are set to 644. * CHECK that /etc/exports is owned by root.

2.6 /etc/hosts.lpd

* ENSURE that the first character of the file is not ‘-‘. (Refer to the CERT advisory CA-91:12 (see C.7)). * ENSURE that the permissions on this file are set to 600. * ENSURE that the owner is set to root.

2.7 /etc/ttytab (BSD UNIX systems)

* CHECK that the secure option is removed from all entries that don’t need root login capabilities. ie. all entries with the possible exception of console. It should also be removed from console if you do not want users to be able to reboot in single user mode. * CHECK that this file is owned by root. * CHECK that the permissions on this file are 644.

2.8 /etc/inetd.conf

* ENSURE that the permissions on this file are set to 644. * ENSURE that the owner is root. * DO disable any services which you do not require. – To do this we suggest that you comment out ALL services by placing a “#” at the beginning of each line. Then enable the ones you NEED by removing the “#” from the beginning of the line. In particular, it is best to avoid “r” commands and tftp, as they have been major sources of insecurities. – For changes to take effect, you need to restart the inetd process. Do this by issuing the following commands. # /bin/ps -aux | /usr/bin/grep inetd | /usr/bin/grep -v grep # /bin/kill -HUP <inetd-PID>

2.9 Trivial ftp (tftp)

* Read the AUSCERT Advisory SA-93:05 (see A.1) and follow the recommendations. * If tftp is not needed, comment it out from the file /etc/inetd.conf and restart the inetd process (as above).

2.10 /etc/services

* ENSURE that the permissions on this file are set to 644. * ENSURE that the owner is root.

2.11 tcp_wrapper (also known as log_tcp)

* ENSURE that you are running this program. – Refer to section A.5 on how to obtain tcp_wrapper. – Customise and install it for your system. – Deny all hosts by putting “all:all” in /etc/hosts.deny and explicitly list trusted hosts who are allowed access to your machine in /etc/hosts.allow. * DO wrap all TCP services that you have enabled.

2.12 /etc/aliases

* Comment out the “decode” alias by placing a “#” at the beginning of the line. For this change to take effect you will need to run /usr/bin/newaliases. # /usr/bin/newaliases If you run NIS (YP), you will then need to rebuild your maps: # (cd /var/yp; /usr/bin/make aliases)

* ENSURE that all programs executable by an alias are owned by root, have permissions 755 and are stored in a systems directory eg. /usr/local/bin.

2.13 /etc/sendmail.cf

* ENSURE the line starting with “OW” only has a “*” next to it. * DO use Eric Allmans’s sendmail v8.6.10 (or greater), as it currently contains no KNOWN vulnerabilities. This is available via anonymous FTP from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu /ucb/sendmail/sendmail.8.6.10.* Note: If you don’t already run Eric Allman’s sendmail.8.6.*, then it may take you some time to build, install, and configure the system to your needs. Other sendmail(8) configuration files may not be compatible with sendmail(8) 8.6.10. * CHECK that you have installed the latest patches. This is VERY important as sendmail(8) has been a source of a number of security vulnerabilities. (Refer to AUSCERT Advisory SA-93:10 (see A.1) and CERT Advisories CA-94:12 and CA-95:05 (see C.7)) * TRY the following tests: % telnet hostname 25 wiz debug kill quit % You should see the response “500 Command unrecognized” after each of the commands ‘wiz’, ‘debug’ and ‘kill’. If not, your version of sendmail is vulnerable and should be updated. * DO increase sendmail(8) logging to a minimum log level of 9. This will help detect attempted exploitation of the sendmail(8) vulnerabilities. To do this, include the following line in the options part of the general configuration information section of the sendmail configuration file: # log level OL9 * DO increase the level of logging provided by syslog. Enable a minimum level of “info” for mail messages to be logged to the console and/or the syslog file. For example, include the following lines in the syslog.conf file: mail.info /dev/console mail.info /var/adm/messages syslog will then need to be instructed to reread the configuration file. This can be done by issuing the command # /bin/kill -HUP `/bin/cat /etc/syslog.pid` Sample error messages to look for include mail to or from a single pipe (“|”), or mail to or from an obviously invalid user (for example, bounce or blah). * REMEMBER that if you are running a frozen configuration file – sendmail.fc, you will need to rebuild it and restart sendmail(8) before any changes will take effect. To rebuild the frozen configuration file, the command is: # /usr/lib/sendmail -bz To restart sendmail(8) you should kill *all* existing sendmail(8) processes by sending them a TERM signal using kill. Then startup sendmail(8). Sample commands are: # /usr/bin/ps -auxw | /bin/grep sendmail | /bin/grep -v grep # /bin/kill <pid> #pid of every running sendmail process # /usr/lib/sendmail -bd -q1h

2.14 majordomo

* Check that your version is greater than 1.91. See AUSCERT Advisory SA-94.03 (see A.1) for more details.

2.15 fingerd

* If your version of fingerd is older than than 5 November 1988, replace it with a newer version.

2.16 UUCP

* DO disable the uucp account, including the shell that it executes for logging in, if it is not used at your site. uucp may be shipped in a dangerous state. * REMOVE any .rhosts file at the uucp home directory. * CHECK that the file L.cmds is owned by root. * ENSURE that no uucp owned files are world writable. * CHECK that you have assigned a different uucp login for each site that needs uucp access to your machine. * CHECK that you have limited the number of commands that each uucp login can execute to a bare minimum.

* ENSURE you are using the most recent version of the ftp daemon that you use. * DO consider installing the Washington University ftpd if you don’t already have it. This can log all events and provide users with a login banner. Do not install any versions prior to wu-ftp 2.4. (Refer to the CERT advisory CA-94:07 (see C.7)). It is available via anonymous ftp from ftp://ftp.auscert.org.au/pub/mirrors/wuarchive.wustl.edu /packages/wuarchive-ftpd/* [Warning: versions of wu-ftp prior to 2.4 are extremely insecure and in some cases have been trojaned.]
* For BSDI systems, patch 005 should be applied to version 1.1 of the BSD/386 software. It is available via anonymous ftp from: ftp://ftp.bsdi.com/bsdi/patches/README ftp://ftp.bsdi.com/bsdi/patches/?U110-005 (? will be B or S for the Binary or Source version)

3.2 SITE EXEC

* CHECK to make sure your ftp server does not have the SITE EXEC command Do this by telneting to port 21 and typing SITE EXEC. If your ftp daemon has SITE EXEC make sure you have the most recent version of the daemon (eg, wu-ftp 2.4). In older versions of ftpd SITE EXEC allows anyone to gain shell via port 21. * CHECK that any commands from ~ftp/bin, ~ftp/usr/bin, ~ftp/sbin or similar directory configurations that can be executed by SITE EXEC DO NOT contain system commands or include a shell (eg., ~ftp/bin -> /bin) If they do contain system commands it is possible for local users to gain root access. (See AUSCERT advisory SA-94.01 (see A.1))

3.3 Configuration of your ftp server

* CHECK all default configuration options on your ftp server. Not all versions of ftp are configurable. If you have a configurable version of ftp (eg. wu-ftp) then make sure that all delete, overwrite, rename, chmod and umask options (there may be others) are NOT allowed for guests and anonymous users. In general, anonymous users should not have any unnecessary privileges.

* CHECK that you have set up a file /etc/ftpusers which specifies those users that are NOT allowed to connect to your ftpd. This should include, as a MINIMUM, the entries: root, bin, uucp, ingres, daemon, news, nobody and ALL vendor supplied accounts.

* CHECK that you use an invalid password and user shell for the ftp entry in the system passwd file. It should look something like: ftp:*:400:400:Anonymous FTP:/home/ftp:/bin/rubbish where /home/ftp is the anonymous ftp area.

* CHECK that you DO NOT have a copy of your real /etc/passwd file as ~ftp/etc/passwd. Create one from scratch with permissions 444, owned by root. It should not contain the names of any accounts in your real password file. It should contain only root and ftp. These should be dummy entries with disabled passwords eg: root:*:0:0:Ftp maintainer:: ftp:*:400:400:Anonymous ftp::

* Similarly, CHECK that you DO NOT have a copy of your real /etc/group file as ~ftp/etc/group. Create one from scratch with permissions 444, owned by root.

* ENSURE the files ~ftp/.rhosts and ~ftp/.forward are zero length, have permissions 600 and are owned by root.

3.4 Permissions

* ENSURE NO files or directories are owned by the ftp account or have the same group as the ftp account. If they are, it may be possible for an intruder to replace them with a trojan version. * ENSURE that the anonymous ftp user cannot create files or directories in ANY directory. * ENSURE that the ftp user can only read information in public areas. * ENSURE that the permissions of the ftp home directory (~ftp/) are set to 555 (read nowrite execute), owner set to root (NOT ftp). * ENSURE that the system subdirectories ~ftp/etc and ~ftp/bin have the permissions 111 only, owner set to root. * ENSURE that the permissions of files in ~ftp/bin/* have the permissions 111 only, owner set to root. * ENSURE that the permissions of files in ~ftp/etc/* are set to 444, owner set to root. * ENSURE /usr/spool/mail/ftp is owned by root with permissions 400. If you need email for the ftp admin (eg. for problem reporting) use an alias.

3.5 Writable directories

* CHECK that you don’t have any writable directories. It is safest not to have any writable directories. If you do have any, we recommend that you limit the number to one. * CHECK that writable directories are not also readable. Directories that are both writable and readable may be used by unauthorised persons to trade pirated software. * CHECK that any writable directories are owned by root and have permissions 1733. * DO put writable directories on a separate partition if possible. This will help to prevent denial of service attacks. * DO read the CERT document which addresses the many problems associated with writable anonymous ftp directories. It can be obtained via anonymous ftp from: ftp://ftp.auscert.org.au/pub/cert/tech_tips/anonymous_ftp

3.6 Disk mounting

* NEVER mount disks from other machines to the ~ftp hierarchy unless they are read-only.

—————————————————————————— 4.0 Password and account security —————————————————————————— This section of the checklist can be incorporated as part of a password and account usage policy.

4.1 Policy

* CHECK that you have a password policy for your site. See the AUSCERT Advisory SA-93.04 (see A.1). * ENSURE you have a User Registration Form for each user on each system. Make sure that this form includes a section that the intending applicant signs, stating that they have read your account usage policy and what the consequences are if they misuse their account.

4.2 Proactive Checking

* DO use npasswd or passwd+ to proactively screen passwords as they are entered. These programs run a series of checks on passwords when they are set and can help to screen out poor passwords. They were not designed to work with shadow password systems. (Refer to section B.3 for how to obtain these.) * DO check passwords periodically with Crack. (Refer to section B.4 for how to obtain Crack.) * DO apply password aging (if possible).

4.3 Root Password

* DO restrict the number of people who know the root password. These should be the same users registered with groupid 0 (eg. wheel group on SunOS). Typically this is limited to at most 3 or 4 people.

4.4 NIS and /etc/passwd entries

* DO NOT run NIS if you don’t really need it. * CHECK that the only machines that have a ‘+’ entry in the /etc/passwd files are NIS (YP) clients; i.e. NOT the NIS master server! There appears to be conflicting documentation and implementations regarding the ‘+’ entry format and so a generic solution is not available here. It would be best to consult your vendor’s documentation. Some of the available documentation suggests placing a ‘*’ in the password field, which is NOT consistent across all implementations of NIS. We recommend testing your systems on a case-by-case basis to see if they correctly implement the ‘*’ in the password field. To do this, follow the steps below: . Try using NIS with the ‘*’ in the password field for example; +:*:0:0::: If NIS users cannot log in to that machine, remove the ‘*’ and try the next test. . With the ‘*’ removed, try logging in again. If NIS users can log in AND you can also log in unauthenticated as the user ‘+’, you have a problem! Your vendor needs to change their version of NIS. If NIS users can log in AND you cannot log in as the user ‘+’, your implementation should not be vulnerable to this problem. * CHECK that /etc/rc.local is set up to start ypbind with the -s option. This may not be applicable on all systems. Check your documentation.

4.5 Password shadowing and C2 security

* DO implement C2 security if possible. Consult your vendor documentation for details. * DO implement vendor supplied password shadowing or a third party product if you cannot run full C2 security. Password shadowing restricts access to users’ encrypted passwords. * DO periodically audit your password and shadow password files for unauthorised additions or inconsistencies.

4.6 Administration

* ENSURE that you regularly audit your system for dormant accounts and disable any that have not been used for a specified period, say 3 months. Send out account renewal notices and delete any accounts of users that do not reply. * CHECK that all accounts have passwords. * ENSURE that any user area is adequately backed up and archived. * DO regularly monitor logs for successful and unsuccessful su attempts. * DO regularly check for repeated login failures. * DO regularly check for LOGIN REFUSED messages. * Consider quotas on user accounts if you do not have them.

4.7 Special accounts

* CHECK that there are no shared accounts other than root; i.e. more than one person should not know the password to an account. * Disable guest accounts. Better yet, do not create guest accounts! * DO use special groups (such as the “wheel” group under SunOS) to restrict which users have access to root. * DISABLE ALL default vendor accounts shipped with the Operating System. This should be checked after each upgrade or installation. * Disable accounts that have no password which execute a command, for example “sync”. Preferably, remove these accounts entirely. Check that they do not own any files before you do so.

4.8 Root account

* Make sure root does not have a ~/.rhosts file. * Make sure “.” is not in root’s search path. * Make sure root’s login files do not source any other files not owned by root or which are group or world writable. * Make sure root cron job files do not source any other files not owned by root or which are group or world writable. * DO use absolute path names when root. i.e. /bin/su, /bin/find, /bin/passwd. This is to stop the possibility of root accidentally executing a trojan horse. To execute commands in the current directory, root should prefix the command with “./”, eg. ./command.

* CHECK that there are no .exrc files on your system that have no legitimate purpose. These may inadvertently perform commands that may compromise the security of your system if you happen to start either vi or ex in a directory which contains such a file. To find .exrc files: # /bin/find / ( -fstype 4.2 -o -prune ) -name ‘.exrc’ -exec /bin/cat {} ; -print

* CHECK that any .forward files in user home directories do not execute a command or run a program. The mailer may be fooled into allowing a normal user privileged access. The following command will locate and print .forward files: # /bin/find / ( -fstype 4.2 -o -prune ) -name ‘.forward’ -exec /bin/cat {} ; -print (Refer to AUSCERT Advisory SA-93.10 (see A.1))

5.2 /etc/rc.local

* CHECK /etc/rc.local does not chmod 666 motd. This allows users to change system message for the day. * ENSURE that the line “rm -f /tmp/t1” (or similar) exists in /etc/rc.local to clean up the temporary file used to create /etc/motd. This should occur BEFORE the code to startup the local daemons.

5.3 /usr/lib/expreserve

* DO replace versions of /usr/lib/expreserve prior to July 1993 with a recommended patch from your vendor. If this is not possible, then remove execute permission on /usr/lib/expreserve: # /bin/chmod 400 /usr/lib/expreserve This will mean that users who edit their files with either vi or ex and have their sessions interrupted, will not be able to recover their lost work. If you implement the above workaround, please advise your users to regularly save their editing sessions. Refer to the CERT advisory CA-93:09 for advice on fixing this problem for the SunOS and Solaris environments.

* CHECK that the permissions of /etc/utmp are set to 644. * CHECK that the permissions of /etc/sm and /etc/sm.bak are set to 2755. * CHECK that the permissions of /etc/state are set to 644. * CHECK that the permissions of /etc/motd and /etc/mtab are set to 644. * CHECK that the permissions of /etc/syslog.pid are set to 644. * REMOVE setgid priveleges on /usr/kvm/crash. A group of kmem allows users to read the virtual memory of a running system. # /bin/chmod g-s /usr/kvm/crash * DO consider removing read access to files that users do not need to access. * ENSURE that the kernel (eg. /vmunix) is owned by root, has group set to 0 (wheel on SunOS) and permissions set to 644. * ENSURE that /etc, /bin, /usr/etc, /usr/bin and /tmp are owned by root and that the sticky-bit is set on /tmp. ie. permissions on /tmp should be: drwxrwxrwt. You should implement COPS or Tiger to check for this. Refer to section B.2 for information where to obtain these.

* CHECK the umask value for each user and ensure it is set to something sensible like 027 or 077. Refer to section E.1 for a shell script to check this.

5.6 Files run by root

AUSCERT recommends that anything run by root should be owned by root, should not be world or group writable and should be located in a directory where every directory in the path is owned by root and is not group or world writable.

* CHECK the contents of the following files for the root account. Any programs or scripts referenced in these files should meet the above requirements: – ~/.login, ~/.profile and similar login initialisation files – ~/.exrc and similar program initialisation files – ~/.logout and similar session cleanup files – crontab and at entries – /etc/rc* and similar system startup files

* If any programs or scripts referenced in these files source further programs or scripts they also need to be verified.

5.7 Bin ownership

Many systems ship files and directories owned by bin. This varies from system to system and may have serious security implications.

* CHANGE all non-setuid files and all non-setgid files and directories that are world readable but not world or group writable and that are owned by bin to ownership of root, with group id 0 (wheel group under SunOS). Anything else should be verified with the vendor.

5.8 Tiger/COPS

* Do run one or both of these. Many of the checks in this section can be automated by using these programs. For information on where to get these programs see B.2.

—————————————————————————— 6.0 SunOS specific security —————————————————————————— The following is a list of security issues that relate specifically to SunOS 4.1.x. This is not necessarily a complete list.

6.1 IP forwarding

* CHECK that IP forwarding is disabled. You will need the following line in the kernel configuration file: options “IPFORWARDING=-1” For information on how to customise a kernel, see the file: /usr/sys/`arch`/conf/README

6.2 Framebuffers /dev/fb

If somebody can log in to your Sun workstation from a remote source, they can read the contents of your Framebuffer, which is /dev/fb. Sun provides a mechanism which allows the user logging in to have exclusive access to the Framebuffer, by using the file /etc/fbtab. A sample /etc/fbtab file: # # File: /etc/fbtab # Purpose: Specifies that upon login to /dev/console, the # owner, group and permissions of all supported # devices, including the framebuffer, will be set to # the user’s username, the user’s group and 0600. # Comments: SunOS specific. # Note: You cannot use to continue a line. # # Format: # Device Permission Colon separated device list. # /dev/console 0600 /dev/fb /dev/console 0600 /dev/bwone0:/dev/bwtwo0 /dev/console 0600 /dev/cgone0:/dev/cgtwo0:/dev/cgthree0 /dev/console 0600 /dev/cgfour0:/dev/cgsix0:/dev/cgeight0 /dev/console 0600 /dev/cgnine0:/dev/cgtwelve0 # /dev/console 0600 /dev/kb:/dev/mouse /dev/console 0600 /dev/fd0c:/dev/rfd0c

After the above file has been created, reboot your machine, or log out fully, then log back in again. Read the man page for fbtab(5) for more information.

6.3 /usr/kvm/sys/*

* CHECK all files and directories under /usr/kvm/sys/ are not writable by group. In SunOs 4.1.4 the default mode is 2775 with group staff, allowing users in group staff to trojan the kernel.

6.4 /dev/nit (Network Interface Tap)

* DO run the CERT tool cpm to check if your system is running in promiscuous mode. For access details for cpm see B.6.

* DO disable the /dev/nit interface if you do not need to run in promiscuous mode. For SunOS 4.x and Solbourne systems, the promiscuous interface to the network can be eliminated by removing the /dev/nit capability from the kernel. Once the procedure is complete, you may remove the device file /dev/nit since it is no longer functional.

Apply “method 1” as outlined in the System and Network Administration manual, in the section, “Sun System Administration Procedures,” Chapter 9, “Reconfiguring the System Kernel.” Excerpts from the method are reproduced below: # cd /usr/kvm/sys/sun[3,3x,4,4c]/conf # cp CONFIG_FILE SYS_NAME [Note that at this step, you should replace the CONFIG_FILE with your system specific configuration file if one exists.]

# chmod +w SYS_NAME # vi SYS_NAME # # The following are for streams NIT support. NIT is used by # etherfind, traffic, rarpd, and ndbootd. As a rule of thumb, # NIT is almost always needed on a server and almost never # needed on a diskless client. # pseudo-device snit # streams NIT pseudo-device pf # packet filter pseudo-device nbuf # NIT buffering module

[Comment out the 3 “pseudo-device” lines; save and exit the editor before proceeding.]

[This step will reboot the system with the new kernel.]
[NOTE that even after the new kernel is installed, you need to take care to ensure that the previous vmunix.old , or other kernel, is not used to reboot the system.]

See CERT Advisory CA_94.01 (see C.7)

6.5 SUN recommended and security patches are available via anonymous ftp from ftp://ftp.auscert.org.au/pub/mirrors/sunsolve1.sun.com/*

—————————————————————————— 7.0 IRIX specific security —————————————————————————— The following is a list of security issues that relate specifically to the IRIX operating system. This is not necessarily a complete list.

7.1 /usr/lib/vadmin/serial_ports The /usr/lib/vadmin/serial_ports program is used to initialise the data files for the serial ports on your system.

(This only be applies to IRIX Version 4 systems, or Version 5 systems that still contain the serial_ports program.)

* DO DISABLE this program 1)If you are not using the serial ports on your IRIX Version 4 system. 2)If you are using serial ports and do not wish to change the configuration of those ports. 3)If you are using version 5 and the serial_ports program is present. This program has been superseded by /usr/Cadmin/bin/cports on Version 5 and therefore, is no longer required. /usr/lib/vadmin/serial_ports can be disabled by the command: # /bin/chmod 700 /usr/lib/vadmin/serial_ports

* If you intend changing the serial port configuration, you can still disable the serial_ports program as above. To change the serial port configuration, run the serial_ports program as root.

(Refer to AUSCERT Advisory AA-94.05a (see A.1))

7.2 Some IRIX patches are available via anonymous ftp from ftp://ftp.auscert.org.au/pub/mirrors/ftp.sgi.com/security/* ftp://ftp.auscert.org.au/pub/mirrors/sgigate.sgi.com/*

—————————————————————————— 8.0 X windows security —————————————————————————— Access to your X server may be controlled through either a host- based or user-based method. The former is left to the discretion of the Systems Administrator at your site and is useful as long as all hosts registered in the /etc/Xn.hosts file have users that can be trusted, where “n” represents your X server’s number.

This may not be possible at every site, so a better method is to educate each and every user about the security implications (see references below). Better still, when setting up a user, give them a set of X security related template files, such as .xserverrc and .xinitrc. These are located in the users home directory.

You are strongly advised to read the section on X windows security referred to in C.4 below.

8.1 Problems with xdm

Note: Release 6 of X11 is now available and solves many problems associated with X security which were present in previous releases. If possible, obtain the source for R6 and compile and install it on your system. Source for R6 is available via anonymous ftp from: ftp://munnari.oz.au/X.V11/R6

xdm bypasses the normal getty and login functions, which means that quotas for the user, ownership of /dev/console and possibly other preventive measures put in place by you may be ignored.

You should consult your vendor and ask about potential security holes in xdm and what fixes are available.

8.2 X security – General

* DO Read the man pages for xauth and Xsecurity. Use this information to set up the security level you require. * CHECK that the permissions on /tmp are set to 1777 (or drwxrwxrwt). i.e. the sticky bit should be set. The owner MUST always be root and group ownership should be set to group-id 0, which is “wheel” or “system”. If the sticky bit is set, no one other than the owner can delete the file /tmp/.X11-unix/X0, which is a socket for your X server. Once this file is deleted, your X server is gone forever!

If the permissions or ownership are not set as above, then type the following commands: # /bin/chown root.wheel /tmp # /bin/chmod 1777 /tmp

Note: This will NOT recursively set the sticky bit on sub-directories below /tmp, such as /tmp/.X11-unix and /tmp/.NeWS-unix; you may have to set these manually or through the system startup files.

There are many good tools available for checking your system. The list below is not a complete list, and you should NOT rely on these to do ALL of your work for you. They are intended to be only a guide. It is envisaged that you may write some site specific tools to supplement these.

B.1 Crack Crack is a fast password cracking program designed to assist site administrators in ensuring that users use effective passwords. Available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/cert/tools/crack/*

B.2 COPS and Tiger These packages identify common security and configuration problems. They also check for common signs of intrusion. Though there is some overlap between these two packages, they are different enough that it may be useful to run both. Both are available via anonymous ftp. COPS: ftp://ftp.auscert.org.au/pub/cert/tools/cops/1.04 tiger: ftp://ftp.auscert.org.au/pub/mirrors/net.tamu.edu/tiger*

B.3 npasswd and passwd+ These programs are proactive password checkers. They run a series of checks on passwords at the time users set them and refuse password that fail the tests. Note that these programs are not designed to work with shadow password systems. Both are available via anonymous ftp. npasswd: ftp://ftp.auscert.org.au/pub/mirrors/ftp.cc.utexas.edu /npasswd/npasswd.tar.Z passwd+: ftp://ftp.auscert.org.au/pub/mirrors/dartmouth.edu /security/passwd+.tar.Z

B.4 tcp_wrapper This software gives logging and access control to most network services. It is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl /tcp_wrappers_7.2.tar.gz

B.5 Tripwire This package maintains a checksum database of important system files. It can serve as an early intrusion detection system. It is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/coast/COAST/Tripwire/*

B.6 cpm cpm checks to see if your network interfaces are running in promiscuous mode. If you do not normally run in this state then it may be an indication that an intruder is running a network sniffer on your system. This program was designed to run on SunOS 4.1.x and may also work on many BSD systems. It is available via anonymous ftp from: ftp://ftp.auscert.edu.au/pub/cert/tools/cpm/*

B.9 smrsh The smrsh(8) program is intended as a replacement for /bin/sh in the program mailer definition of sendmail(8). smrsh is a restricted shell utility that provides the ability to specify, through a configuration, an explicit list of executable programs. When used in conjunction with sendmail, smrsh effectively limits sendmail’s scope of program execution to only those programs specified in smrsh’s configuration. It is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/cert/tools/smrsh

B.10 md5 md5 is a message digest algorithm. An implementation of this is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/cert/tools/md5/* ftp://ftp.auscert.org.au/pub/cert/tools/md5check/*

It is intended that this short version of the checklist be used in conjunction with the full checklist as a progress guide (ie. check the sections off as you go so that you remember what you have done so far).

for dir in $HOMEDIRS do for file in $FILES do grep -s umask /dev/null $dir/$file done done

—————————————————————————– The AUSCERT team have made every effort to ensure that the information contained in this checklist is accurate. However, the decision to use the tools and techniques described is the responsiblitiy of each user or organization. The appropriateness of each item for an orgaization or individual system should be considered before application. AUSCERT takes no responsibility for the consequences of applying the contents of this document.

About Us

W3ctrl is all about Software Development and Web Development on a larger perspective and more emphasis is given to Customize Business Software Development and Web Development. We are providing the best E-commerce solution for your business with the latest technology and marketing strategy.