ASU-UNUG Best Practices

1.	Turn off ports that are not needed
2.	Sendmail notes 
3.	Tcp_wrapper 
4.	PGP – Pretty Good Privacy
5.	Physical Security
6.	Firewalls
7.	Linux Systems
8.	The web
9.	Setuid programs
10.	The tcpdump program
11.	CERT & Hacker Boards
12.	Vendor Patches
13.	Ssh (Secure Shell)
14.	Monitor and probe tools
15.	Kerberos
16.	The Andrew File System – (AFS)
17.	Monitor logs
18.	Xhosts command
19.	The “r” commands
20.	User Management
21.	Limit SU users and SUDO
22.	Installation Practices 
23.	Virus, worms and the Trojan Horse
24.	Filesystem security
25.	Passwords

1. Turn off ports that are not needed.
When installing a Unix system, one of the first steps that should be taken is to disable all TCP/UDP ports and only enable the ones that are really necessary.  To do this (on most Unix systems), perform the following steps from a root shell:
1.  Comment out ALL lines in /etc/inetd.conf with a text editor such as VI.  An easy command for doing this would be “:1,$s/^/#/” (w/o quotes).
2.  Comment back in only the lines for entries of services that you will need (such as telnetd and/or ftpd).
3.      Save the file and exit.
4.      Find out the PID (process ID) for inetd (e.g. ps –ef | grep inetd)
Execute “kill -HUP #” (where “#” is the PID number of inetd).  This will signal the inetd service daemon to run with the modified inetd.conf file. 
The reason for shutting off as many ports as possible is simply to minimize risk.  Programs that listen on ports can be attacked by anyone on the Internet unless your system is behind a firewall.  Devious hackers on the net can write programs that exploit known bugs or other vulnerabilities.  By shutting off the port or running tcp-wrappers, you can stop most attacks right at the entry point to your system. 
This is the most effective thing you can do to defend against network attacks.  On your most secure servers, we recommend that you turn all ports off and install only Secure Shell (Ssh) in place of telnet and ftp. 

2.   Sendmail notes 
Most, if not all, Unix systems out of the box come with a copy of Sendmail ready to go.  However, usually this version of Sendmail is old and may contain security holes.  If you will not be receiving mail on your system, Sendmail should be disabled.  Unlike other daemons, Sendmail is not controlled through inetd.  Usually, it is initiated in a system’s startup scripts.  Configuring your system to not start up Sendmail is a matter of commenting out a few lines from the appropriate script.  For example, on a Solaris 2.5 (or newer) system, edit or remove the /etc/rc2.d/S88sendmail file accordingly.
If you must run Sendmail, it is usually best to get the latest version (currently that is version 8.9).  Also, if you only send out mail and don’t receive any mail, you can run Sendmail from a cron job that checks the out-bound directory (/var/spool/mqueue) for any out-going mail.  For example, the following entry in crontab will check for mail every 30 minutes:
0,30 * * * * /usr/lib/sendmail –q 1>/dev/null 2>&1
Since Sendmail runs as root and is listening on port 25 for incoming mail, it can be dangerous if anything besides standard SMTP protocol mail is sent to that port.  A safer way to accept mail is a small program that reads the mail and stores it immediately to disk but does not process it.  Later, Sendmail can process the mail and may not have to be running as root.  For the program that does this and more information on how to set it up see the Sendmail documentation.
Sendmail 8.9 comes with a configuration that also defends against many types of spam (unsolicited junk e-mail).  If you are running an older version you may use this the following macro file and process it with m4 according to the Sendmail documentation.  This will stop spammers from using your system as a gateway to spam other sites (the default for version 8.9):
divert(-1)
divert(0)dnl
include(`../m4/cf.m4')  
# set smart host to ASU's post office
define(`SMART_HOST', smtp:smtp.asu.edu)
# set the architecture below.
OSTYPE(solaris2)dnl
# turn off uucp
FEATURE(nouucp)dnl
MAILER(local)dnl
MAILER(smtp)dnl
 # Rules to prevent spammers from using us as a relay.  Taken from the Sendmail
# site at http://www.sendmail.org.
LOCAL_RULESETS
FR-o /etc/sendmail.cR
Scheck_rcpt
# anything terminating locally is ok
R<$+ @ $=w >            $@ OK 
R<$+ @ $=R >            $@ OK 
# anything originating locally is ok
R$*                     $: $(dequote "" $&{client_name} $)
R$=w                    $@ OK 
R$=R                    $@ OK 
R$@                     $@ OK
# anything else is bogus
R$*                     $#error $: "550 Relaying Denied"
#  
For information on the latest version of Sendmail, take a look at http://www.sendmail.org.  Also, the book titled “Sendmail, 2nd Edition” by Bryan Costales & Eric Allman (ISBN 1-56592-222-0) is a very handy resource for all aspects of Sendmail.
Often times, systems with older versions (or “out-of-the-box” versions) of Sendmail are victims or break-ins or attempted break-ins.  Even if a system is running the latest version of Sendmail, it is a very good practice to have Sendmail logging turned on (and of course, for the system administrator to monitor those logs).  Sendmail uses the syslog facility to log it’s information (the default is /var/log/syslog). Through the appropriate configuration of the /etc/syslog.conf file, the amount of information and where the information should be sent to can be set.  More information on how Sendmail uses the syslog facility is available in Chapter 26 of “Sendmail, 2nd Edition” (see 2 above).

3.  Tcp_wrapper 
A tcp_wrapper is a security tool that will enable an administrator to control what IP addresses can have access to certain configurable ports.  If your system does not need to be open to the world, then one of the best practices that can be applied is to install and configure a tcp_wrapper.  The latest version of tcp_wrapper is available at ftp://ftp.cert.org/pub/tools/tcp_wrappers/.  You will need to download and compile the source (more information is available in README files).  Some administrators may consider the tcp_wrapper one of the most valuable tools since it prevents hackers from gaining login access through conventional means.
The administrator should start with a default "noone can get in" by adding an "all: all" line in hosts.deny and then specifically grant access to hosts that need it in hosts.allow.
One feature of tcp_wrapper is the ability to execute your own script just prior to the system executing a vital program like telnet or ftp.  This allows you to do a number of things.  For example, your script could log the IP address and domain name of every connection attempt.  It could send you an email if the connection attempt is not what you might expect.  Or, it could even run finger back to the IP address of the machine that is making the connection.  Obviously, this can be a very powerful tool and allows you to decide who and who can’t log into your system.

4. PGP – Pretty Good Privacy
Pretty Good Privacy (PGP) by Philip R. Zimmermann is the de-facto standard software for the encryption of electronic mail and other sensitive files. Its public-key cryptography system enables people who have never met to secure transmitted messages against unauthorized reading and to add digital signatures to messages to guarantee their authenticity. 
If you regularly send e-mail to people that contain passwords or other sensitive information, this is a good way to be sure that the person you send mail to is really the person you think it is.  When you are encrypting a message to be sent to someone, you encrypt the message with the recipient's public key. Then, the only way the message can be decrypted is with the recipient's private key. 
You can download the latest version of PGP from ftp://ftp.replay.com/pub/crypto/pgp.  For more information, see the MIT distribution site at http://web.mit.edu/network/pgp.html.

5. Physical Security
Physical security means that you can minimize security risks by only giving physical access to the system to those who need it.  Typically, users do not need access to the console if your system is a server.  And for workstations with a monitor, you can use xterm or remote telnet into the system.  
The reason you don’t want to give users access to the console is that once they have it, they can halt the system and reboot from CD-ROM.  Once the system is booted from CD-ROM, they simply mount your disks and change the root password or do anything else they care to do.  Even if they don’t have a bootable CD-ROM handy they can still get into your system.  
Here are a few suggestions that may help you keep your systems physically secure:
·        Keep the systems and peripherals in a secure area accessible by only those who must access them for administration.
·        Keep backup tapes also in a secure area.
·        Use an UPS to keep power constantly available to your systems.
·        Have a recovery plan for disaster recovery in case the worst happens.
·        Have a way to detect penetration of the physical area (e.g. swipe cards that log who comes and goes or video cameras)
·        Check your vendors – know who they are and why there are in your area.  If a vendor must have root access to work on your system, key it in for them.  Don’t be shy about asking them to turn the other way while you type.  When they’re done, change the root password anyway.  Make sure you understand what they did.

6. Firewalls
Firewalls provide a means to section off certain systems from the rest of the Internet and allow only certain types of communication through the firewall.  Typically companies use them to put a “wall” up between their company and the Internet.  Users inside the firewall may be restricted to access only systems inside the firewall.  Likewise, users and systems outside the firewall may be restricted to only certain parts of the Intranet (inside the firewall).  This greatly reduces the security threat from unknown persons out in the Internet.  
Consider using a firewall where you have sensitive data such as grades, payroll or other administrative information.  For a list of firewall software see http://www.alw.nih.gov/Security/prog-firewall.html.

7. Linux Systems
Some systems are more secure out of the box than others.  Unfortunately, Linux is not one of them.  As distributed, most Linux distributions (e.g. RedHat) have may things turned on by default that you don’t need.  Be sure to edit all of the files in the start-up directory /etc/rc.d/init.d and shut off anything you don’t need.  For example, if you don’t need your system to be a web server, rename the start-up script that executes at boot time.  If you don’t want mail to come in or out, don’t start up Sendmail.  
While Linux is a free and powerful operating system, it can be dangerous if you don’t know what you’re doing.  It is also one of the more popular systems for hackers to develop their code on because the software is free and all of the source code is available.  As a result, Linux is one of the first operating systems where users discover that there is a new security hole.  
If you run Linux, be sure to keep up with all of the latest security patches and developments.  See http://ww.linux.org for more information and be sure you know what programs are running on all ports.  If you simply install it from the CDROM and make no other changes, your system will not be very secure.

8. The web
The WWW is most vulnerable because of CGI scripts that allow an attacker to execute arbitrary commands on a WWW server under the effective user-id of the server process.  For a complete discussion of this and how to prevent it see the following CERT publication:  
ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters  
Also, a very complete explanation of the security problems related to the WWW (and there are a lot of them) can be found here:  
http://www.w3.org/Security/Faq  
We recommend that if you don’t need to run a Web server of your own, then don’t.  IT can provide AFS space to departments that want Web pages to appear under www.asu.edu.  You can save your compute power by running your Web pages on IT servers, but you’ll still have access to maintain your pages since they reside in AFS spcae.
 If you still need to run a Web server of your own at ASU, then you should carefully read and understand these documents.  Please contact ASU’s Webmaster if you have any questions regarding Web space at ASU or about how to set up your pages in AFS.

9. Setuid programs
Setuid programs typically execute with higher privileges than the person who runs the program does.  For example, the /bin/passwd program executes as root, but only while it’s running.  It does this for anyone who runs it.  So, during that time the passwd program is running, it can do whatever it wants (or needs) to do.  In this case it needs to modify the contents of /etc/passwd or /etc/shadow to change your password.  Programs like /bin/passwd, that run setuid to root must be very careful.  If a user keys in something, the program must able to handle it and not accidentally give the user a shell or anything else that root has access to.
In general, we recommend that you don’t write setuid programs at all unless it’s absolutely necessary.  Even the programs that come with your system have been hacked and are often the starting point used by hackers to attempt a break-in.  You can turn off the setuid mode bit on some programs.  For example, if you know that you don’t want users changing their passwords, you can turn off the setuid bit for /etc/passwd (e.g. # chmod 750 /bin/passwd).  However, be careful.  Some setuid programs are needed by your operating system.  
If you do write setuid programs consider not using root as the UID to change to.  Also, if you write in Perl, user the tainted switch (-T) and follow all of the guidelines carefully.  
For more information on setuid and how it works, see your man pages.

10. The tcpdump program
Tcpdump is a program that allows root to “sniff” TCP/IP packets and display the contents in a number of different formats.  This is a useful tool if you want to see exactly what is happening on an Ethernet segment. The source code and installation information can be found at ftp://ftp.ee.lbl.gov/tcpdump.tar.Z.  The output can be somewhat verbose and you really need to understand what you’re looking at.  To help with that the book “UNIX Network Programming – Volume 1, Second Edition” by W. Richard Stevens is an excellent place to start.

11.  CERT & Hacker Boards
The Computer Emergency Response Team (or CERT) is the organization that grew from the computer emergency response team formed by the Defense Advanced Research Projects Agency (DARPA) in November 1988.  The CERT website at http://www.cert.org contains a lot of valuable information on system security for Unix system administrators.  CERT also has a mailing list available that administrators can subscribe to receive the latest security-related information (usually software and system vulnerabilities in advisories, summaries, and vendor-initiated bulletins).  More information on the CERT mailing list can be obtained at http://www.cert.org/contact_cert/certmaillist.html. 

12. Vendor Patches
Hackers are constantly finding new security holes while vendors usually try to provide timely fixes for them.  Many vendors provide security patches for free and make them available on the net.  Other vendors may require a service maintenance agreement.  Here is a list of common Unix vendors that have and maintain security patches:  
·        BSDI - ftp://bsdi.com/bsdi/patches
·        Caldera OpenLinux - ftp://caldera.com/pub
·        Debian Linux - http://cgi.debian.org/www-master/debian.org/sec.html
·        DEC - http://www.service.digital.com/html/patch_service.html 
·        FreeBSD - ftp://ftp.FreeBSD.org/pub/FreeBSD
·        HP - http://us-support.external.hp.com
·        IBM - ftp://testcase.software.ibm.com/aix/fromibm
·        NeXT - ftp://ftp.next.com/pub/NeXTanswers/CompressedFiles/Patches
·        RedHat Linux - ftp://ftp.redhat.com/updates
·        SCO - ftp://ftp.sco.com/SSE
·        SGI - ftp://sgigate.sgi.com/patches
·        SUN - http://sunsolve.sun.com/sunsolve/pubpatches/patches.html

13.       Ssh (Secure Shell)
Ssh (Secure Shell) is a program that allows you to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another.  It provides strong authentication and secure communications over insecure channels.  For your most secure systems, you can run Ssh instead of telnet and ftp.  Its features include the following:
·        Strong authentication.  Closes several security holes (e.g., IP, routing, DNS spoofing, and listening for passwords from the network).  New authentication methods: .rhosts together with RSA based host authentication, and pure RSA authentication.
·        All communications are automatically and transparently encrypted. Encryption is also used to protect against spoofed packets and hijacked connections.
·        X11 connection forwarding provides secure X11 sessions.
·        Arbitrary TCP/IP ports can be redirected over the encrypted channel in both directions.
·        Client RSA-authenticates the server machine in the beginning of every connection to prevent Trojan horses (by routing or DNS spoofing) and man-in-the-middle attacks. The server RSA-authenticates the client machine before accepting .rhosts or /etc/hosts.equiv authentication (to prevent DNS, routing, or IP spoofing).
·        An authentication agent, running in the user's local workstation or laptop, can be used to hold the user's RSA authentication keys.
·        Multiple convenience features fix annoying problems with rlogin and rsh.
Secure Shell is widely used and very stable - we highly recommend it.  You can get it here: http://www.cs.hut.fi/ssh.

14.       Monitor and probe tools
Here is a list of software monitor and probing tools that may be useful.  This list was taken from http://www.alw.nih.gov/Security/security-prog.html that has a host of other important information regarding security related issues.
Argus
Argus is a powerful tool for monitoring IP networks. It provides tools for sophisticated analysis of network activity that can be used to verify the enforcement of network security policies, network performance analysis and more.
Availability: anonymous ftp at ftp.sei.cmu.edu
Arpwatch
An Ethernet monitor program that keeps tracks of Ethernet/IP address pairings.  Availability: anonymous ftp at ftp.ee.lbl.gov
Courtney - It is a program that tries identifies the use of SATAN on a subnet.  The program tcpdump will also be needed in order to run Courtney.  See below for information about tcpdump. 
Availability: anonymous ftp at ciac.llnl.gov 
Additional Info: CIAC Notes 08
Dig
Dig is a network utility which queries Domain Name Servers similar to nslookup but
it's more flexible.
Availability: anonymous ftp at venera.isi.edu
Drawbridge
Powerful bridging filter package.
Availability: anonymous ftp at net.tamu.edu
 Fping
An efficient way to test whether a large number of hosts are up.
Availability: anonymous ftp at slapshot.stanford.edu
IPACL
Filters incoming and outgoing TCP and UDP in a SVR4/386 kernel.
Availability: anonymous ftp at ftp.win.tue.nl
ISS
Checks hosts within a specified range of IP address for various security vulnerabilities
in Sendmail, anonymous FTP setup, NFS and many more.
Availability: anonymous ftp at info.cert.org
Additional Info: CERT Advisory 93:14.Internet.Security.Scanner
Klaxon
It is a daemon that is used to identify the use of port scanners like ISS and SATAN.
Availability: anonymous ftp at ftp.eng.auburn.edu
Multi Router Traffic Grapher (MRTG)
MRTG is a tool to monitor the traffic load on network-links. MRTG generates HTML pages containing GIF images which provide a LIVE visual representation of this traffic.
Availability: World Wide Web at ee-staff.ethz.ch Additional Info: MRTG: Multi Router
Traffic Grapher
Netlog
Network logging and monitoring of all TCP and UDP connections on a subnet. Netlog also includes tools to analyzing the output.  Availability: anonymous ftp at net.tamu.edu
Network Security Scanner (NSS)
NSS is a Perl script that scans one host on subnet or an entire subnet for various simple
security problems.
Availability: anonymous ftp at jhunix.hcf.jhu.edu
NFSWatch
NFSWatch monitors NFS requests and measures response time for each RPC.
Availability: anonymous ftp at coast.cs.purdue.edu
Pidentd
Identd tries to identify the remote user name of a TCP/IP connection. Identd is an implementation of RFC 1413.
Availability: anonymous ftp at ftp.lysator.liu.se or ftp.csc.ncsu.edu Additional Info: RFC 1413
PingLogger
PingLogger detects and logs ICMP ECHO REQUESTS.
Availability: World Wide Web at www.students.uiuc.edu
Rscan
Rscan is an extensible network scanner that checks for common network problems and SGI specific vulnerabilities.
Availability: anonymous ftp at ftp.vis.colostate.edu
Additional Info: Rscan: Heterogeneous Network Interrogation
SATAN
SATAN is a program that gathers network information such the type of machines and services available on these machine as well as potential security flaws.
Availability: anonymous ftp at ftp.win.tue.nl. Also see wzv.win.tue.nl for a list of mirror sites.
Additional Info: Cert Advisory CA-95:06.satan
Scan-Detector
Scan-detector determines when an automated scan of UDP/TCP ports is being done on a host running this program. Logs to either syslog or strerr.
Availability: anonymous ftp at coast.cs.purdue.edu
Additional Info: COAST Projects' Tools
Simple Key-Management for Internet Protocols (SKIP)
SKIP adds privacy and authentication at the network level.
Availability: USA and Canada--via web form
Availability: International--anonymous ftp at ftp.elvis.ru
Additional Info: SKIP Information and SKIP in Russia
Strobe
Strobe displays all active listening TCP port on remote hosts. It uses an algorithm that efficiently uses network bandwidth.
Availability: anonymous ftp at suburbia.apana.org or minnie.cs.adfa.oz.au
TCP Wrapper
Allows a Unix System Administrator to control access to various network services through the use of access control list. It also provides logging information of wrapped network services which may be used to prevent or monitor of network attacks.
Availability: anonymous ftp at ftp.win.tue.nl
Additional Info: TCP Wrapper
Tcpdump
It captures and dumps protocol packets to monitor or debug a network.
Availability: anonymous ftp at ftp.ee.lbl.gov
Traceroute
Traceroute traces the route IP packets take from the current system to a destination system.
Availability: anonymous ftp at ftp.psc.edu
Xinetd
It's a replacement for inetd that has extensive logging and access control capabilities for both TCP and UDP services.
Availability: anonymous ftp at qiclab.scn.rain.com
YPX
It is a utility used to retrieve a NIS map from a host running NIS daemon.
Availability: anonymous ftp at ftp.uu.net or WWW server at mls.saic.com

15.       Kerberos
Kerberos is a network authentication protocol.  It is designed to provide strong authentication for client/server applications by using secret-key cryptography.  A free implementation of this protocol is available from the Massachusetts Institute of Technology.  Kerberos is available in many commercial products as well.  For more information see http://web.mit.edu/kerberos/www. 

16.  The Andrew File System – (AFS)
ASU supports the Andrew File System (AFS) which in turn supports a number of useful security features.  First, all usernames and passwords are kept in a central database that all of the communication and contents to that database are encrypted.  Passwords are not kept on the client workstations.  So if a hacker looks for passwords in /etc/passwd or /etc/shadow they will be disappointed.  AFS also includes Kerberos as a built in feature of the system.  Access to any part of the file space under AFS is controlled by special tokens.  In order to get a token, a user must present a username and password at login time which is then authenticated via Kerberos.
Second, AFS make systems administration of usernames and passwords pretty easy.  Once the AFS client is installed on a system, the system administrator simply puts entries into /etc/password that have an X in the password field.  Typically, the home directory points to somewhere in AFS file space.  For example, an entry in /etc/passwd might look like this:
johndoe:X:1234:1234:John Doe:/afs/asu.edu/users/j/o/h/johndoe:/bin/ksh
Now, the user “johndoe” can log into any AFS client system using the same password.  Again, all communications between the AFS client and the AFS servers are encrypted.  So, there is little fear of Ethernet sniffing or other attempts to steal a password off the network.
To get an ASURITE userid into ASU’s Kerberos database, the user need only apply for one at the Accounts Office in the Computing Commons building. 
While AFS has many other benefits, the security benefits alone are worth considering running AFS clients.  For more information and AFS and the newer Distributed Computing Environment (DCE) see http://www.transarc.com.

17. Monitor logs
To understand better what is happening on your system, we recommend that you check your logs often.  Look for unusual entries.  See what is happening at 2AM when there is not supposed to be anyone on your system.  If you see something, make sure you know what is and why it is running at 2AM.  Here's a list of logs that can be helpful and that should be checked on a regular basis. 
System log and console messages – This is the primary system log.  Most daemons log to this file.  Vendors keep it in different places.  On Solaris, it’s /var/adm/messages. 
The ‘last’ log – The ‘last’ command will list out who has logged into your system lately.  If you’d like to keep old logs, we recommend that you have a cron job that copies them to tape or somewhere safe. 
Sendmail log – Sendmail keeps it’s log of incoming and outgoing mail in /var/log/syslog.  Check it to see how Sendmail is running and also to see if you are getting spammed.  Look for bogus mail and be sure that you relay your mail to ASU’s official post office – not some other machine that could steal your mail.  See the section above for more information about Sendmail. 
Audit Trails –In some cases, the system can create an audit trail of password usage and changes.  Also, the history log of what users type can usually be found in the .history file in the user home directory.  If you’d like to se what a user has been up to lately, look at their .history file.  Users can delete or tamper with this file, so don’t believe everything you see.
Sar – The sar set of utilities on Unix can be turned on to help monitor system usage.  This includes counts of how many times a user executes a program and how often particular programs are executed and by whom.  Sar is also the mail tool for getting statistical reports in things like memory, CPU and swap usage.  For more information on sar, check out a good Unix book or see the man pages.

18.       Xhosts command
Host level security is maintained through an xhost file (host access control list).  The xhost command is used to grant access to specific hosts or to all hosts, or it can be used to deny access to all hosts.
User level security is available through an xauthority list (user access control list). The xauth command is used to main this list.
Where possible, only trusted hosts or users should be allowed access.  Convenience is not sufficient reason to give universal access. “xhost +” gives access to all hosts; “xhost –“ removes access from all hosts.  Examples of what could happen if untrusted hosts or uses are allowed access include:
·        An x-window, mimicking a standard screen (perhaps with a password field), can be displayed on your system.  Non-authorized people could capture input in that window.
·        An invisible x-window can be placed on your system which can monitor all your keystrokes.
Review the xhost lists regularly.  Hosts are identified by IP address or by name.  The IP addresses or names can change, and the change is often likely to happen without your knowledge.  Give access only to a host that you know needs to display at your terminal screen.  For example, if I want my workstation to display X output from a remote host, I should explicitly issue an xhost command for that host only (e.g. xhost remote.la.asu.edu).  This will allow only users from that host to display at your workstation.
Some systems are shipped with “xhost +” enabled (SGI IRIX for example).  This is a serious oversight and should be corrected.  At the very least you should issue the “xhost –“ command as part of your system startup thereby making it the default for all users.
Other suggestions for X users include:
·        Review the xauthority lists regularly. Userids may be reassigned to other people.
·        If the x server can log security-related events, activate the log and then review it periodically.
·        When a specific host or user no longer needs access, remove the entry from the appropriate list

19.       The “r” commands
The “r” commands, known to be a regular source of system insecurities include rlogin, rsh, rexec, rcp, rwho, ruptime.
rlogin (for remote login)  is a client program that provides remote terminal service similar to telnet, but does not require that the user type his or her username. If a user is logging in from a remote “trusted host”, the receiving system lets the user log on without a password.
rsh (for remote shell)  is a client program that allows users to run a single command on the remote system.  rsh can only work from trusted hosts or trusted users. (See hosts.equiv)
rexec (remote execution daemon) allows users to execute commands on other computers without having to log into them.
It is recommended that you restrict the use of “r” commands that aren’t specifically needed by:
disabling
wrapper program
filtering
If you must run the “r” commands, you can use more secure versions of these commands, like logdaemon 5.6 from available from the following site:
ftp://ftp.win.tue.nl/pub/security/index.html#software
Check if you have a /etc/hosts.equiv file.
If you don’t need to run “r” commands or don’t need to explicitly trust other systems, you have no use for a hosts.equiv file and it should be removed. If you are running “r” commands, a /etc/host.equiv file allows other hosts to be trusted by your system. Programs such as rlogin can be used to log on to the same account name on your machine from a trusted machine without supplying a password.
If you do have a /etc/hosts.equiv file, you can protect yourself by:
limiting the number of trusted hosts, and/or only listing those hosts that are within your domain or under your control.
using fully qualified hostnames (for example, ws1.la.asu.edu, box2.eas.asu.edu).
checking that you do NOT have a  ‘+’ entry listed by itself anywhere in the file.
checking that the first character of the file is not  ‘ - ‘ .
checking that the permissions for the file are set to 600. (If not, chmod 600).
checking that the owner of the file is ROOT.
checking this file after installing any patches or operating system updates.
$HOME/.rhosts
Check to see that no user has a .rhosts file in their home directories. Having .rhosts files in home directories can cause a greater security risk than having an /etc/hosts.equiv file, as each user can create one.
Create a cron script that regularly checks for, reports the contents of and deletes $HOME/.rhosts files.
Decide if there is a legitimate use of .rhosts file in a user’s home directory. If so, make sure the file is owned by the user.
Make sure there are no # ‘ or ‘ ! ‘ characters in this file. There is no comment character for this file.
The Secure Shell (Ssh) can also be set up as a complete replacement for the ‘r’ commands.  The advantage here is that you get the convenience of using the ‘r’ commands, but none of the security risks.

20. User Management
Know your users, "Individual accountability is the key to securing and controlling any system that processes information on behalf of individuals or groups of individuals.
user cleanup---disable or delete accounts of those who are no longer users on your systems
The system admin should be responsible for the development of a procedure whereby prompt notification is given to him/her when a user ID and password must be removed from the system (e.g., when an employee or student leaves ASU or the unit).
All userid's should be revalidated periodically for information such as sponsor and means of off-line contact e.g., phone number, mailing address) updated as necessary.
It is recommended that this revalidation be done at least once per year.

21.  Limit SU users and SUDO
The Unix ‘su’ command allows you to become another user without logging off.  It is handy for system administrators to use if they need to telnet into a remote machine (or, better yet, Ssh into a remote machine).  Many systems will not allow you to telnet in remotely and log into root.  This is done as a security precaution.  Instead, you should telnet in as some other user, then use ‘su – root’ to log into root.  This is more secure because it will be logged into the su log file.  Failed attempts are also logged, so it is good practice to examine your su log from time to time and find out who has been trying to get root on your system.
Sudo (superuser do) allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments.  This could be used, for example, to allow a non-root user to run your backups for you.  For more information about Sudo see http://www.courtesan.com/sudo/.

22.  Installation Practices 
The person selected to do the install should be knowledgeable regarding UNIX installations and security, and should be a known, trusted person. When using assistance from an outside source (outside your immediate group), verify the source’s credentials or identity.
Review the installation procedures prior to installation and identify all security settings. The installation defaults may be insufficient or may alter existing settings. Post-installation tasks should include verification of the desired security settings.
Store the installation software (disks, cd’s) and manuals in a secure location.
Consider doing the installation on a test system, perhaps one without access to other systems on the network.
Verify correctness of the PATH before beginning installation. Avoid using “.” in PATH for root access.
Do a thorough backup before the installation. Verify the restore procedures actually work. After installation, do another thorough backup.

23.       Virus, worms and the Trojan Horse
A virus is a piece of code or program that typically attaches itself to some known or trusted program on your system and is executed when the trusted program runs.  If that trusted program is run with setuid as root, you’re in for trouble.  On Mac’s and PC’s viruses are more common because a virus can spread itself more easily on those platforms.  But, Unix is not immune to them.  Always be cautious when executing any program as root.  Make sure you know what it will do and don’t just trust the person who gave it to you blindly.  Insist on the source code whenever possible and compile it yourself.
If you suspect that some piece of software has a virus or worm – don’t run it on a system that is connected to the Ethernet.  Isolate a test system to do testing and be very careful what you put out on the network.  It may try to attack other systems on your Ethernet.
A worm is a program or piece of code attached to a trusted program that tries to copy itself over the network and imbed itself into other unsuspecting user’s systems.  The famous Morris worm back in 1988 used a Sendmail bug to copy itself all over the Internet.
To protect yourself against worms, don’t open ports on the net unless you have to and know what they are (see Item #1 above).  Also, keep abreast of the latest news from CERT about new virus or worms that have been discovered.  Keep up with the security patches from your vendors and most of your problems with worms and viruses can be kept to a minimum.
A Trojan horse is a program that allows a hacker a back way in and has usually been planted in an innocuous place that may be hard to find.  Many times a hacker may want to get back into a site once is has been compromised once already.  One way to do that is to place a Trojan horse program somewhere on the system that allows them to get access again if the main way is blocked or if other changes have been made that prevent them from breaking in the same way they came in before.  To guard against these, check all of the setuid programs on your system to be sure that the are supplied by the vendor and that the are bit-for-bit identical to the vendor’s version (e.g. use the ‘sum’ command or ‘diff’). 
If a digital signature is available for a distributed piece of software, verify that the signature is legitimate.  Sometimes software (especially security software) is digitally signed by the person or organization that wrote it.  For example, the Secure Shell has a signature file distributed with it that is signed the by the author of the program.  PGP is then used to verify the distribution.

24. Filesystem security
The standard Unix filesystem comprises of security control at the file level and directory level.  However, it is not the purpose of this document to go into details about basic Unix filesystem properties.  Some main issues relating to security are as follows:
The “setuid” bit.  If the “setuid” bit is enabled on a file, then when the file is executed, it is run under the owner’s userid instead of the userid of the person executing it.  High precautions should be taken when implementing and using setuid programs!
r-sr-sr-x   1 root     sys       356640 Oct 15  1997 Sendmail
The file above is an example of a setuid implementation.  When the file “sendmail” is executed (doesn’t matter by whom), it is run under the “root” userid.
The “write” bit set for ‘other’ mode.  If the “write” bit is enabled for the ‘other’ mode on a file or directory, then it could essentially be changed by anyone who has access to the system.
drwxr-xrwx  21 sneak    users       1536 Jun 11 15:50 /home/sneak/
The directory above is an example of this implementation.  This will enable anyone else on the system to write to that directory (and possibly change files within it).  Extra precautions should be taken on system directories such as /etc, /bin, /usr and others.  An exception to the rule is /tmp, in which typically anyone should be able to write to.  More information is available in various man pages including chmod, chown, chgrp and ls
One useful tool called tripwire can monitor changes to system binaries.  It is available at ftp://coast.cs.purdue.edu/pub/COAST/Tripwire.

25.  Passwords
Users should understand their responsibility to keep passwords private and to report changes in their user status, suspected security violations, etc.  To assure security awareness among the user population, it is recommended that each user be required to sign a statement to acknowledge understanding these responsibilities.
·        A password should be initially assigned to a user when account created on a system.  A user's password must be changed periodically
·        A user must have a valid ASUID to obtain an account students should require a faculty signature
·        Users should be able to change their own passwords.
·        Take care in delivering the password to the user---In person or via written format delivered to a mailbox 
·        Forgotten passwords
·        User must notify system admin
·        System admin needs to verify user
·        Use Shadow passwords
·        Limit su usage – keep a log of su users 
·        Require a secure terminal, perhaps just the console    
·        Set permissions for telnet usage of TTY’s (could be in /etc/ttys, security)
·        use access.conf
·        use a special group for those allowed to use su.
The simplest way to recover from the compromise of a password is to change it. Therefore, passwords should be changed on a periodic basis to counter the possibility of undetected password compromise. They should be changed often enough so that there is an acceptably low probability of compromise during a password's lifetime.
One common practice is to change a password such that it cannot be found in any dictionary and yet is easy to remember.  Two short words connected by some special character usually make a good password.  For example, “dog$heaven” would be a good password because it’s not easily guessed, can’t be found in the dictionary and is easy to remember.