• Part I will deal with securing the system with the tools Linux provides. One exception to this rule is the inclusion of Secure Shell or SSH.
  
• Part II will cover additional software the sysadmin can install, such as log analyzers, port monitors, and kernel modifications. Some of the built-in firewalling capabilities of Linux will also be examined in Part II.

Disclaimer:
Properly securing a machine can be a daunting task; especially with the amount of new exploits surfacing on an almost daily basis. This paper is not meant to be a total security solution, but should instead be regarded as a guide to security through many of the measures that can be taken to protect a machine from intruders.

• Inetd services
  
  The first thing to take a look at is the /etc/inetd.conf file. Most Unix TCP and UDP services are initialized from this file. A short section is shown below:
  

  -- sample inetd.conf section --
  
  ftp     stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -l
  #telnet stream  tcp     nowait  root    /usr/libexec/telnetd    telnetd
  #shell  stream  tcp     nowait  root    /usr/libexec/rshd       rshd
  #login  stream  tcp     nowait  root    /usr/libexec/rlogind    rlogind
  
  -- sample inetd.conf section --
  
  
  
   (1)     (2)    (3)      (4)    (5)           (6)                 (7)

  
  
  
  • /etc/inetd.conf fields explained
    
    
    1. service name
    2. socket type (stream or datagram)
    3. protocol type (TCP or UDP)
    4. wait/nowait - If wait server will subsequently process all connections, if nowait server will exec a new server process for each connection
    5. user
    6. command Name
    7. arguments (Optional)
    
    Any services preceded by a pound sign (#) are commented out and therefore will not be started at boot time.
    
    Inetd is a daemon (also known as the SuperServer) whose purpose is to listen for TCP or UDP connections. When a connection is received, inetd passes that connection to the appropriate service.
    
    As an example, if a user establishes an ftp connection to a machine, inetd will answer the connection and pass it off to the ftp daemon, ftpd. This reduces overhead on the machine by having one daemon listen for connections rather than each individual service listening on their own. It is important for the admin to know their /etc/inetd.conf file intimately as this is often where an intruder will place one of many backdoors.
    
    The first step will be to open the /etc/inetd.conf file with a text editor and comment out any and all services which are not necessary to the system's purpose. In general, the admin should be able to comment-out the overwhelming majority of the services in this file. Again, this depends on what sorts of services the machine is designated to provide. And for the purpose of a service-versus-security model, less is definitely more. If the admin is not sure if a particular service is needed, it's best to turn it off. If the service is later deemed necessary, it can be re-enabled. The only caveat on re-enabling a previously disabled service is that the version being enabled must come from trusted source (eg, vendor media) and be the latest version with all applied patches. In short, the admin is strongly encouraged to do their research and know their software.
    
    After commenting out unnecessary services inetd needs to be restarted so the changes just made will take effect.
    
    # ps -auwx | grep inetd
#kill -HUP

    Note: It is generally a good idea to completely remove any packages that you will not be using. This can be accomplished in Slackware Linux using the 'pkgtool' feature .
    
  
  
• RPC / NFS Services
  
  Remote Procedure Call (RPC) and Network File Service (NFS) are a series of network protocols that allow a network of systems to operate as if they were a single machine. RPC essentially allows programs to run on a distributed basis across many machines. NFS allows a machine to share parts of its filesystem to a remote machine. Not surprisingly, both RPC and NFS are notoriously insecure and should be avoided at all costs. As an example, if NFS is set up incorrectly -- which is very easy to do -- any remote machine could feasibly mount that NFS partition and have access to the data within.
  
  RPC and NFS connections are managed by the portmapper. The portmapper is a daemon that is called from /etc/rc.d/rc.inet2 on Slackware systems. If you are using another flavor of Linux or Unix you may have to do some searching to discover from what start-up script the portmapper and rpc services are called from. To do this, issue commands such as:
  
  # find /etc -name "*map*" -print | more
# find /etc -name "*nfs*" -print | more
# find /etc -name "*port*" -print | more
# find /etc -name "*rpc*" -print | more

  The above commands should yield where the specific scripts to start these services reside in your /etc/rc.d hierarchy.
  
  Since the value of using RPC and NFS services is usually outweighed by the insecurity of the protocols, these services will be disabled. In a text editor, open /etc/rc.d/rc.inet2. Go through each section of the file and determine what services to leave and which to comment out. The specific section we are looking for should look something like:
  
  

  # Start the SUN RPC Portmapper.   
  if [ -f ${NET}/rpc.portmap ]; then
     echo -n " portmap"
     ${NET}/rpc.portmap
  fi
  

  We can comment out these lines and when the system is restarted, the portmapper will not be started. Take the time to go through this file line by line. Further down in the file is a section where the RPC services are called from, these can be commented out also.
  
  It should also be noted that many Linux and Unix variants initiate the rc.d scripts which are prefaced by an "S". Renaming these scripts so they are prefaced by a "K" will direct your server to kill said processes instead of starting them.
  

-- sample syslog.conf section --
*.=info;*.=notice                               /usr/adm/messages
*.=debug                                        /usr/adm/debug
-- sample syslog.conf section --


(1).(2)						      (3)

• /etc/syslog.conf fields explained
  
  
  1. Facility: The actual subsystem that provides the message. This may be one of the keywords listed below or an asterisk (*) for everything.
     
  2. Syslog level (priority): Determines the severity of the message
  3. Action: Determines how the information passed from syslogd will be handled.
  
  Note: The facility and priority must be separated by a period. From the example above we can see that any 'information' or 'notice' messages produced by any of the subsystems facilities are logged to /usr/adm/messages and all 'debug' messages produced by any subsystem is logged to /usr/adm/debug.
  The following tables list the facility and priority keywords available:
  
  
• Facility keywords
  
  
  • auth
    logs information regarding user authentication
    
  • authpriv
    Same as above but also provides authentication that may include privileged information such as usernames
    
  • cron
    logs information associated with the cron daemon
    
  • daemon
    logs information from system daemons
    
  • kern
    logs kernel related messages
    
  • lpr
    logs printer service related messages
    
  • mail
    logs messages related to electronic mail
    
  • mark
    used to generate timestamps in logfiles
    
  • news
    logs messages related to internet news
    
  • security
    same as auth
    
  • syslog
    logs messages generated by syslog
    
  • user
    logs messages generated by user programs
    
  • uucp
    logs messages related to uucp
    
  • local0 - local7
    used for logging by customized programs
    
  
  
• Priority keywords (from lowest to highest)
  
  
  • debug
    logs debugging information
    
  • info
    logs informational messages
    
  • notice
    a condition that should be handled in a special way
    
  • warning
    system warning
    
  • warn
    same as above
    
  • err
    system error
    
  • crit
    critical condition
    
  • alert
    condition that needs intervention
    
  • emerg
    possible system crash
    
  • panic
    system panic
    
  
  Note: By default, syslog will log the priority selected in syslog.conf and all priorities above that priority. To log only a specific priority the equal (=) operator may be used:
  
  mail.=info

  This would log only informational messages related to electronic mail
  
  
• Actions
  
  
  • file
    the path to log the information to, such as: /var/adm/messages
    
  • terminal
    log to a console, such as /dev/tty1
    
  • printer
    log to a printer, such as /dev/lp1
    
  • @hostname
    the hostname of a remote machine send logs to
    
  • username
    use 'write' to send messages to specified user
    
  • named pipe
    send logs to a FIFO file
    
  
  Armed with this knowledge we can create a better syslog.conf file that is custom-tailored to our particular system.
  
  
• Sample syslog.conf
  
  -- begin sample syslog.conf --
  

  *.=info;*.=notice;*.warn;mail.none              /usr/adm/messages
  *.=debug                                        /usr/adm/debug
  *.warn;*.crit;*.emerg                           /usr/adm/syslog
  *.warn;*.crit;*.emerg                           /usr/adm/messages
  
  auth.*                                          /usr/adm/log.auth
  cron.*                                          /usr/adm/log.cron
  daemon.*                                        /usr/adm/log.daemon
  kern.*                                          /usr/adm/log.kern
  mail.*                                          /usr/adm/log.mail
  mark.*                                          /usr/adm/log.mark
  syslog.*                                        /usr/adm/log.syslog
  user.*                                          /usr/adm/log.user

  -- end sample syslog.conf --
  
  As you can see we are still logging nearly everything to /usr/adm/messages, but we are also logging individual facilities to individual log files. Though this will increase the amount of disk space used by the log files, it will also greatly increase your logging capabilities. Notice that multiple entries may appear on the same line as long as they are separated by a semicolon (;).
  
  Part II of this article will discuss some methods and programs that can be used to easily manage these log files.
  

• Locating and Removing SUID/SGID Binaries
  
  It is a good idea to determine what binaries on our system are SUID/SGID and try to reduce that list to the bare minimum. The following command will search the entire file system for SUID/SGID files and list them in a file called /tmp/suids. We are going to use this list as a script to remove unnecessary SUID/SGID files.
  
  #find / \( -perm -4000 -o -perm -2000 \) -exec ls -ldb {} \; >> /tmp/suids
  
  Now we can examine the /tmp suids file with an editor and remove any files from the list we wish to allow to remain running SUID/SGID. Most files that are set SUID/SGID can be run with more favorable permissions. Another option to removing the SUID and SGID bits is to refine the access control to limit access to those files to a particular group.
  
  After we have determined which files we wish to remain running SUID/SGID we can use vi to convert our file into a script.
  
  
  1. cat /tmp/suids |cut -b55-200 > $HOME/remove_suid.sh
     
  2. cd
     
  3. vi remove_suid.sh
     
  4. :%s/ \//chmod -s \//g
     
  5. <return>
     
  6. Add the following to the top of the file:
     
  7. #!/sbin/sh
     
  8. :wq!
     
  9. chmod 700 remove_suid.sh
     
  10. ./remove_suid.sh
      
  
  The script will then strip the SUID and SGID bits from any files that were left on our list. After running the script run the above find command again to ensure the bits were stripped properly. Ensure these files are removed from the /tmp and $HOME directories once the script has been executed.
  

• Obtaining and Installing SSH
  
  SSH v1.2.27 may be obtained from ftp://ftp.cs.hut.fi/pub/ssh/. Installing SSH is rather straightforward. For a standard installation it is a matter of running the 'configure script', executing 'make' and then 'make install'.
  See the README for compile-time options to SSH. During installation a global configuration file will be installed in /etc/sshd_config. Some of the defaults entries for the configuration file are not very security conscious and can be tightened up a bit. Following is a description of the default entries.
  
  Port 22
  Defines what port the SSH daemon will listen on. Port 22 is the standard port for SSH.
  
  ListenAddress 0.0.0.0
  Interface to bind the SSH daemon to. Unless you are running a multi-homed host we can leave the default.
  
  HostKey /etc/ssh_host_key
  File containing the host's keys.
  
  RandomSeed /etc/ssh_random_seed
  File containing the random seed.
  
  IdleTimeout 30m
  Determines how long an idle client may remain connected before being automatically disconnected. This should be set to a reasonable number.
  This is a flexible option and can be specified in (s)econds, (m)inutes, (h)ours, (d)ays, or (w)eeks.
  
  ServerKeyBits 768
  The number of bits for the server key.
  
  LoginGraceTime 300
  Sets the time, in seconds, that the SSHD daemon will wait for a connected client to authenticate. Allowing a client 300 seconds to authenticate is a bit extreme and should be lowered.
  
  KeyRegenerationInterval 600
  Sets the interval for the regeneration of new keys. 600 seconds is a reasonable default.
  
  PermitRootLogin no
  Allow/disallow root logins. Root should never be allowed to login remotely, that is what su is for.
  
  IgnoreRhosts yes
  If set to yes all $HOME/.rhosts are ignored. The /etc/hosts.equiv file is unaffected by this option.
  
  StrictModes yes
  If set to the default of 'yes' the SSH daemon will not allow access to a user whose home directory is owned by a different user.
  
  QuietMode no
  If set to 'no' all logging will be suppressed except for fatal errors.
  Normal connection requests for SSH are handled through the syslog daemon.
  Unless you are trying to debug an error this can be set to 'no'.
  
  X11Forwarding no
  If set to 'yes' the X Windows System forwarding is allowed. I typically do not use X Windows and set this to 'no'.
  
  X11DisplayOffset 10
  Specifies the first X Windows display available to SSH for forwarding.
  
  FascistLogging yes
  If set to yes, the SSH daemon will provide extra logging that can be useful for debugging purposes.
  
  PrintMotd yes
  If set to 'yes', the /etc/motd will be displayed after a user authenticates.
  
  KeepAlive yes
  If set to 'yes', the SSH daemon will periodically check the status of a connection. If connectivity cannot be verified the connection will be closed.
  
  SyslogFacility DAEMON
  The default syslog facility.
  
  RhostsAuthentication no
  If set to 'no' does not allow .rhosts or /etc/hosts.equiv authentication.
  This should never be set to yes under any circumstances.
  
  RhostsRSAAuthentication no
  Enables or disables RSA Key Authentication. This should be set to 'no'.
  
  RSAAuthentication no
  Enables and disables RSA Authentication.
  
  PasswordAuthentication yes
  Enables or disables password authentication. For obvious reasons, this should never be set to 'no'.
  
  PermitEmptyPasswords no
  If set to 'yes' users with blank passwords may still authenticate. Obviously this should be set to 'no'.
  
  The sshd_config file also provides an additional layer of protection by allowing only specific IP addresses to connect.
  
  The following entry will allow users to connect from only the IP address listed:
  #Restrict connections to one IP address
AllowHosts 192.168.1.1
Currently our SSH daemon has not been started. Now that we have made the desired changes to the sshd_config file we may start it by invoking:
  # /usr/local/sbin/sshd
On Slackware systems, the /etc/rc.d/rc.inet2 file will start the SSH daemon automatically when the system is rebooted. If you are using a different flavor of Linux you may have to add an entry to your rc.local file.
  
  
• Using SSH
  
  Using SSH to connect to a remote host is as easy as using telnet. The general syntax is:
  
  $ ssh -l hostname

  Included with the SSH package is another incredibly handy utility, Secure Copy (SCP). SCP, as it's name implies, is a secure method to copy files from one host to another. This can all but eliminate the systems administrator's need for running ftpd to transfer files insecurely. The general syntax for SCP is:
  
  $ scp :/path/to/file /path/to file/on/local/machine

  As an example let's say we wish to copy the file /etc/foo from host spanky to host alfalfa. The following is a capture of that session:
  
  

  $ scp spanky:/etc/foo /etc/foo
  user@remotehost.com's password: 
  foo                   |          0 KB |   0.0 kB/s | ETA: 00:00:00 | 100%
  $

  SSH also contains a wealth of other features such as secure X11 Port Forwarding, and application proxying. Take the time to read the documentation that is included with the distribution. (I generally do ./configure --without-x because I do not trust X.)

                  -------
 ps ----------->  | MD5 | -------------> b38674b49f679a4ecdd47b7e0642dc85
                  -------

#!/bin/sh
#Generate a set of known-good fingerprints for important system files
#Make sure you have a blank floppy formatted with the ext2 file system
#in /dev/fd0
mount -t ext2 /dev/fd0 /mnt
md5sum /sbin/ifconfig > /mnt/database.orig
md5sum /bin/netstat >> /mnt/database.orig
md5sum /usr/bin/who >> /mnt/database.orig
md5sum /usr/bin/md5sum >> /mnt/database.orig
md5sum /bin/ls >> /mnt/database.orig
md5sum /bin/ps >> /mnt/database.orig
md5sum /usr/sbin/syslogd >> /mnt/database.orig
md5sum /sbin/ifconfig >> /mnt/database.orig
md5sum /usr/sbin/inetd >> /mnt/database.orig
sleep 5
umount /dev/fd0

00 * * * *                                      /bin/sh /usr/sbin/update.sh

--begin update.sh--
#!/bin/sh
# A customizable tripwire
# Thanks to munge@attrition.org for the shell scripting help
# Mount our known-good fingerprint database
# Change /dev/fd0 to suit your needs
mount -t ext2 /dev/fd0 /mnt

# additionally add to email to root?
if [ $? -ne 0 ]
  then echo "Aborting, perhaps disk is not in drive?"
  exit 99
fi
# this gets run in 2 situations, what the hell:
RMS() {
rm -f /tmp/database /tmp/diffs
}
# Generate a new batch of fingerprints and temporarily store them in
/tmp/database

sleep 5
md5sum /sbin/ifconfig > /tmp/database
md5sum /bin/netstat >> /tmp/database
md5sum /usr/bin/who >> /tmp/database
md5sum /usr/bin/md5sum >> /tmp/database
md5sum /bin/ls >> /tmp/database
md5sum /bin/ps >> /tmp/database
md5sum /usr/sbin/syslogd >> /tmp/database
md5sum /sbin/ifconfig >> /tmp/database
md5sum /usr/sbin/inetd >> /tmp/database
sleep 5

# DIAGNOSTICS
# An exit status of 0 means no  differences  were  found,
# 1 means some differences were found, and 2 means trouble.'
# 'create temp file of diffs:'

# Compare the newly generated set of fingerprints to the known good set
diff /tmp/database /mnt/database.orig > /tmp/diffs

# '$? is the exit code of the previous command'
EXIT=$?

# if all is well mail will be sent to root
if [ $EXIT -eq 0 ]
  then echo "Finger Prints match" | mail -s FingerPrints root
  RMS ; # run the rm function
  umount /mnt
  exit 0 ; # no need to run the rest of the program, die
fi

# rest of program assumes things have gone badly....


# Insert this as the first line of the body
# and pipe to mail:

# If fingerprints don't match mail root stating so
sed '1iBAD MATCH! SHAME ON ADMIN!
' /tmp/diffs | mail -s FingerPrints root
# 'changed rm flag to -f so your
#  program does not crap out if
#  it does not find the file'
RMS
umount /mnt

# Additionally send mail to our pager stating we have a problem
# Something bad has happened so halt the machine after the page has been
# sent.
if [ $EXIT -ne 0 ]
   then echo "Possible System Compromise" | mail -s "Badmatch!" pager@pagemart.net
   sleep 30
   shutdown -h now
fi

To read Securing Linux Part II, click here.