Hardening UNIX Applications (draft notes)

Secure installation of UNIX Server Applications

By Seán Boran

This article discusses securely installing well known applications like FTP, DNS and Email.  For each category, a list or tips and products are provided. General guidelines for all applications are also presented.

1. Preparation
2. General Guidelines
3. FTP servers (ftpd)
4. DNS servers
5. HTTP servers
6. Email Clients
7. Email servers (SMTP): sendmail, postfix, smap
8. Additional Notes: IDS | saveit | ntp

References
Changes to this article

1. Preparation

• Keep things simple: it is expected that only one or two services will run on a host. Use several machines, rather than one superserver that does everything. It's easier to isolate applications, harden, troubleshoot and upgrade hw/sw. Be minimalist, only run what is absolutely necessary.
• Hardware: Consider installation via the serial port console, get rid of the keyboard, screen and framebuffer. i.e. avoid using X11 and get to know the command line. Have an isolated, trusted network available for testing.
• It's important to understand how the applications work (how they use ports, devices, files), to judge what hardening is possible and to assess the risk posed.
• As a prerequisite to this article we assume the following has already been done. See also XXX.
  • OS installed, and hardened.
  • Relevant patches installed.
  • Routing, DNS, logging, filesystem mount options, integrity checking is configured
  • We assume that all this has been already done for the rest of this article.

If you use the C-Shell, the following will make editing easier and enable history functions:

csh;
setenv TERM vt100; setenv VISUAL vi; setenv EDITOR vi;
set filec; set history=40; alias h history; alias ls 'ls -aF \!*';

General Guidelines

The following is a general checklist to consider daemons/applications :

• Is the umask set restrictively (e.g. 022) by or before the application starts?
• Does it run as a non root user with minimum privileges? Is it's password "blocked" and shell set to a dummy value such as /dev/null ? If the password is really needed, is it set to min 8 chars with numbers, letters and punctuation?
• If it runs as root, to bind to a low port, does it immediately fork to a non privileged user to minimise risks?
• Are file permissions set so that only the application user can read/write files are there are no world read/writeable files?
• Does the application write log and temporary file permissions securely? Does it write passwords in the install log (don't laugh - it's common!).
• Does it chroot to a special directory? A good article on general chroot environments, also called "padded cells" can be read at Sunworld [2].
• Consider installing applications on a separate partition, to separate the OS from major apps.
• Also consider separating data from programs, so that the programs filesystem can be mounted read-only after the installation is completed, providing a protecting against attackers and Trojans. Note that an attacker with root access can easily remount a filesystem read-write, without rebooting.

FTP servers (ftpd)

Which FTP server should you use?

• The system probably comes with an FTP daemon. Most UNIX systems have a simple one that is not very flashy, but the reduce complexity means better security.
• One of the feature rich ones is wu-ftpd from Western University. It also happens to be almost as notorious as sendmail for security bugs. Be  wary.
• Proftpd (www.proftpd.net)? It's got virtual ftp users, anonymous, support for PAM on Solaris, etc. Plus the config looks just like an Apache httpd.conf file so it's a cinch.
• If you're going to use a third party ftpd, choose one that is secure, like ncftpd. (see http://www.ncftpd.com)
• If the ftp server will only serve/allow downloading, consider:
  • Wietse Venema's read-only FTPD, which is part of the logdaemon package  ftp://ftp.porcupine.org/pub/security
  • Or the ftpd  at http://cr.yp.to/publicfile.html . It does basic http serving, too.

Tips for FTPD configuration:

• If you use Washington University wu-ftpd (for it's better logging, access control and other features), be wary. It has a long history of bugs (e.g. see CERT advisories CA-93:06, CA-94:07, CA-95:16 and Auscert AA-97.03 and AA-1999.02). Use the very latest version.
• Configure /etc/ftpusers to list system accounts, so they cannot not be used for ftp e.g. to disable use of ftp by root, add "root" to /etc/ftpusers.
  One way of doing this for all system accounts on your fresh new system is:
    awk -F: '{print $1}' /etc/passwd > /etc/ftpusers
  Note: This is partially done on newer Linux and Solaris 8, Hardening tools such as Yassp, Jass and Bastille also do this.
• FTP can be selectively enabled per user via /etc/ftpusers as above or by using the following trick with /etc/shells: For users who shouldn't have ftp access to this machine, give their accounts a non-standard shell (such as bash or tcsh) and don't enter this new shell into /etc/shells. FTP access will be denied. Conversely, if a non-standard shell is required, it must appear in /etc/shells for FTP to work correctly.
• On Solaris and the OBSD ftp on (Suse) Linux, enable logging by adding the "-l" option in /etc/inetd.conf (the additional -d option adds debug output).
• FTP can be restricted on an IP address or hostname basis with the tcp wrappers.
• For anonymous ftp, be VERY careful. A chroot environment is a MUST. See Sun's in.ftpd man page which includes a script. Avoid allowing uploads. If uploads are necessary, don't allow downloads of uploaded files, hide uploaded file names and don't allow them to be overwritten (otherwise you may end up as an illegal software repository).
• For normal "user ftp", chroot is also recommended.
• Put the ftp data area on a separate file system and mount it nosuid.
• On Suse Linux 7.1
  • anonymous ftp is enabled by default. To disable, add ftp and anonymous to /etc/ftpusers.
  • If anonymous ftp is desired, enable logging by add "-S" to the command line and creating /var/log/ftpd
  • Also add "'-l" to the in.ftpd startup line in /etc/inetd.conf

DNS servers

Hardening on BIND is described in a separate paper. See [13].

HTTP servers

General notes:

• If content doesn't change often, store it on CD-ROM, it simplifies change control and provides greater resilience to the hackers favourite of "site defacing". The HTTPD server will cache pages, ensuring that access speed does not depend on CD-ROM speed.
• Separate "simple read-only" content servers from E-commerce servers.
• If the httpd server is only needed for an applications local to the server, bind Apache to localhost, so that it is not accessible from the network (Bastille can also do it as part of RedHat hardening).
• Check out the CIAC Bulletin J-042 which describes best practices for Internet web servers.
• Solaris 8 setup: Apache 1.3.9 is included in Solaris 8 and can be optionally installed.
  • Installed in /usr/apache with configuration in /etc/apache. The daemon will start if /etc/apache/httpd.conf exists. The default configuration runs as the user nobody. Server root is /var/apache, containing htdocs, logs and cgi-bin.
  • SSL, mod_perl etc. are not installed.
• On Red Hat Apache is setup as follows (Apache 1.3.9 on RH6.1):
  • Configuration files are in /etc/httpd/conf. Unusual for current Apache installations, access.conf is used for access control and httpd.conf for the rest. HTML root is /home/httpd/html (/var/www/html on RH7), Logs in /var/log/httpd, startup file /etc/rc.d/init.d/httpd
  • Runs as the nobody user.
  • Server stats and server-info links are switched off.
• Suse 7.3: Edit /etc/rc.config.d/apache.rc.config, then run /sbin/SuSEconfig
• It is suggest that apache be changed to run as apache and not nobody, which is also use for remote NFS access by root.
• Setup for a simple Apache server 
  • Create "apache" user & group with blocked password, or just use the nobody group.
    echo "apache:x:5000:99:httpd daemon:/usr/local/apache:/usr/sbin/noshell" >> /etc/passwd
    echo "apache:*LK*:10787:0:0::::" >> /etc/shadow
    echo "apache::99:apache" >> /etc/group
  • Download and install as root in /usr/local/apache, or better compile yourself and add SSL support.
  • File permissions -  by default everything will belong to bin, which is fine. Remove world access, give minimum rights to apache group:
    chgrp -R apache /usr/local/apache;  chmod -R o-rwx /usr/local/apache;
  • Disable the manual pages visible on the default home page, and all default CGI scripts delivered with apache:
    chmod 000 /usr/local/apache/htdocs/manual  /usr/local/apache/cgi-bin/*
    chmod 000 /var/www/html/manual /var/www/cgi-bin/* /var/www/nut-cgi-bin/*
• Tweaking httpd.conf :
  • Set ServerName and User & Group=apache (or default to nobody)
  • set ServerAdmin to the webmaster email
  • Disable UserDir (unless User's really are allowed host pages from their $HOME)
  • ServerSignature to Off (not Email or On) to avoid informing users of the Apache version.
  • Publish minimal version information ('Apache' as opposed to for example 'Apache/1.3.0 (Unix) PHP/3.0 MyMod/1.2'):
    ServerTokens Prod   [1.3.12 and later: delivers 'Apache' only]
    ServerTokens Min   [1.3.0 or later: delivers Apache + version]
  • Disable the /manual/ alias, unless you really want to publish the Apache documentation.
  • Disable any other aliases you don't need, such as /sdb/, /doc/, /hilfe/, /cgi-bin-sdb/. This aliases may provide access to documents outside your document tree without you realising it.
    
  • Production environments will probably not want server-info, server-status or perl-status enabled (they are disabled by default).
  • Disable the SSI "exec" command, and if possible, all Server Side Includes (SSIs).
  • Make sure that access to the root file system is disabled:
    <Directory />
      Options None
      AllowOverride None
    </Directory>
  • Don't allow viewing of .htaccess files:
    <Files .htaccess>
      order allow,deny
      deny from all
    </Files>
  • Check that the log directives ErrorLog and CustomLog point to a filesystems with enough space.
  • Ensure logs are pruned regularly, e.g. once per week:
    ## Prune logs once per week:
    TransferLog "|../bin/rotatelogs /var/apache_logs 604800"
  • Proxying
    • Switch off proxying (unless you really want it)
      ProxyRequests Off
    • Note that even if the reverse proxy features (like 'ProxyPassReverse') are needed, the ProxyRequests can be switched off. If you unwittingly leave the proxy open if will be quickly misused for attacks hiding their identities, cause you bandwidth to be eaten up and possibly your site being blocked by others.
• Testing Apache configuration files:
  % ./apachectl configtest
  Syntax OK
  
• Further reading: see [12]
  
• New resources that look interesting, but are not integrated above:
  • SANS Top20: Apache
    http://www.sans.org/top20/#U1
  • Improving Apache Security
    Gary Bahadur & Mike Shema
    http://www.infosecuritymag.com/articles/april01/features1_web_server_sec.shtml
  • Hardening HTAccess, Part One - Robert Hansen
    http://www.securityfocus.com/frames/?focus=sun&content=/focus/sun/articles/htaccess.html
    Hardening HTAccess, Part Two - Robert Hansen
    http://www.securityfocus.com/frames/?focus=sun&content=/focus/sun/articles/htaccess2.html
    Hardening HTAccess, Part Three - Robert Hansen
    http://www.securityfocus.com/frames/?focus=sun&content=/focus/sun/articles/htaccess3.html

Email Clients (SMTP)

On UNIX and Linux, sendmail is invariably installed as an email server, running as a daemon. Many users/sysadmin think that sendmail needs to run as a daemon on email clients and servers alike.

The sendmail daemon does not need to run on an 'Email Client'.

This erroneous vendor installation behaviour seems to be a default that goes back 15 years, it is difficult to understand why vendors have not corrected this. Few email servers are needed in an organisation, the default should be to only send email, since most hosts are workstations or servers that do not need an SMTP server. Running sendmail as a daemon, increase security risks:

• A weakness may be found that would permit a remote penetration. Although sendmail has not been showing many weaknesses recently, it does have a checkered history and is a very complex piece of software.
• Email relaying may be possible, if incorrectly configured.
• A proper email server needs careful configuring for anti-relaying, anti-spam, virus & content checking etc. Therefore it makes sense to concentrate SMTP servers on specific, properly configured hosts.

So how is an email client set up? Assuming we want to deliver all email from our workstation to one SMTP server, the steps are:

1. Define the mail server: add an entry with the email server name and IP address to /etc/hosts. Then add an alias 'mailhost' for this machine. There should also be an entry for the workstation, and workstation.DOMAINNAME.

2. Configure sendmail.cf (in /etc or /etc/mail), so that all email is sent via 'mailhost':

DSmailhost
DRmailhost
DHmailhost
O FallbackMXhost=mailhost

3. Stop the sendmail daemon from starting automatically

mv /etc/rc2.d/S88sendmail /etc/rc2.d/.no_S88sendmail

and kill the current daemon

4. Add appropriate aliases to /etc/mail/aliases, for example:

root: Your.Name@Yourcompany.com

5. If email cannot be delivered immediately (due to server congestion for example), add the following entry to the root crontab to check for and send queued email every hour:

## process the email Q
0 * * * 1-5 /usr/lib/sendmail -q

6. Finally, test that email is being correctly delivered, by sending an empty test email to 'root' (or some other local alias) and to your usual Email address. The '-v' option is added to mailx so that we see the complete dialog with the email server, to convince us that it really is working correctly.

mailx -v -s test_email root </dev/null
mailx -v -s test_email John.Doe@YourCompany.com </dev/null

Troubleshooting: look carefully at the output of the mailx commands above, and any error emails received in the root mailbox. Check that a 'ping' to mailhost works as expected. The SMTP server may be configured only to accept emails from known workstations or workstations with a particular domain (in which case /etc/resolv.conf - DNS must be setup correctly and the workstation must use the same hostname as is listed in DNS)

Hopefully Sun and other vendors will wake up and stop the sendmail daemon by default in future OS releases, it would certainly help reduce the number of unwitting open email relays on the Internet.

Email servers & Gateways (SMTP)

If you really need to receive Email (i.e. run an SMTP server), it's not a trivial task. Refer to [16]. Here a few brief notes are provided.

1. Configure anti-relaying, anti-spam options
2. Consider anti-virus and content checking
   
3. Use a secure front to sendmail on Internet gateways (with its anti-relaying patches) end like
   • Smap, or use replacements like
   • Postfix (see the links on Postfix further down)
   • or perhaps Qmail.
     
4. A few quick tips on Sendmail:
   • Keep the sendmail binaries up to date
   • sendmail.cf could be edited to disallow VRFY and EXPN commands.
   • To define names of machines for which we receive email, edit /etc/mail/sendmail.cw.
   • Add a specific list of hosts that may use this server as a relay in /etc/mail/relay-domains
   • Refuse access to known spammer sites can be done by adding them to /etc/mail/access
     
   • Disable "%",  "!" and double "@" addressing, by commenting the "CO" entry in sendmail.cf, e.g.
     #CO @ % !)
     
     Then test it by verifying addresses with such characters, e.g.
     sendmail -bv sean%boran.com@mydomain.com
     sendmail -bv sean at boran.com@mydomain.com
     
   • Hide version numbers (many sysadmins don't like this kind of security-by-obscurity), but it does keep some script kiddies away:
     DZ8
     V8
   • Likewise the prompt that sendmail provides to remove clients is
     O SmtpGreetingMessage=$j Sendmail $v/$Z; $b
     and can be reduced to
     O SmtpGreetingMessage=$j ; $b
     which only prints the hostname and date.
     
   • The user and group used by sendmail for message processing can be tuned:
       DefaultUser=daemon:daemon
       RunAsUser=sendmail
   • Limit maximum message size to 6MB (for example). You might as well do this since most other systems do limit size, and large messages may then waste resources with retries, errors messages and confusion. So it's better to limit the size of messages you allow onto the Internet. Typical values are 1-10MB.
        MaxMessageSize=5000000
   • When debugging, the logging level can be adjusted:
         LogLevel=9
   • Consider adding smrsh (sendmail restricted shell) which integrates with sendmail and restricts subshells and what programs can be run out of aliases, etc.
     
     
5. A few quick tips on Postfix:
   Postfix is a very interesting SMTP server, from both a security and flexibility standpoint. I waited years to move over from sendmail, I wish I had done so sooner, it really is simpler, more secure and not so painful to move over.
   
   The main configuration files are typical in /etc/postfix, the big fish is /etc/postfix/main.cf.
   To view non-default settings (i.e. out config): postconf -n
   To show default values: postconf -d
   
   Some example settings for relay and spam protection are listed in postconf-n.txt
   Most of the postfix elements can be chrooted. It worked fine for me on Solaris by running the script examples/chroot-setup/Solaris2 and then editing /etc/postfix/master.cf so that all non pipe or local daemons had 'chroot=Y'.
   

   Postfix tutorial (french)- Hervé Schauer Consultants
   http://www.hsc.fr/ressources/cours/postfix/ 

   Postfix -- the Sendmail Replacement - Martin Zahn (nice diagrams, clear instructions)
   http://www.akadia.com/services/postfix_mta.html

   Configuring Postfix as backup MX host - Martin Zahn
   http://www.akadia.com/services/postfix_mx_backup.html

   Using Postfix for Secure SMTP Gateways - Linux Journal (brief overview)
   http://www.linuxjournal.com/lj-issues/issue78/4241.html

   Postfix FAQ
   http://www.agamemnon.net/documents/postfix/faq.html

   pflogsumm.pl http://jimsun.linxnet.com/postfix_contrib.html 

   How UCE Actually Works - mengwong
   http://www.mengwong.com/misc/postfix-uce-guide.txt 

   Filtering E-Mail with Postfix and Procmail, Part Two - Brian Hatch
   http://online.securityfocus.com/infocus/1598 

Further reading

The OpenAntiVirus Project
http://www.openantivirus.org
http://www.openantivirus.org/av-unix_e.txt

Additional Notes

This article has been very specific, in the interest of making it practical. However, each security administrator has his own methods and each site has different requirements.

• Intrusion detection:
  • Regular logfile analysis can be implemented with customer scripts or tools such as logcheck and swatch [6].
  • Integrity checkers: see section above.
  • Doug Hughes has written tocsin and klaxon [4], two free tools that listen for network scans and connections to particular ports. Tocsin only needs to be installed once per subnet and klaxon is installed in inetd.conf for key services that should be closed and where you don't expect a connection (but would like to know). I've test klaxon on Solaris 2.5,2.6 and 2.7. Tocsin works on 2.5 and 2.6, but won't work on 2.7 (compiled on 2.5 or 2.6). A sample startup script for tocsin is S11tocsin [3].
  • I have written a perl script monitor_socket.pl [3] that listens to a list of sockets and notifies by email and syslog if a connection is received. Like klaxon above, but does not run from inetd. Originally written to detect Sybase and Satan connection attempts.

• It's a good idea to keep previous versions of configuration files, to allow rollback and have an audit trail. This is called versioning.  It is especially important when several administrators manage a host, changes are frequent, etc. Versioning can also be used with Jumpstart scripts & config files.  Some sysadmins use RCS (included in Yassp), some use CVS, some copy the configuration file to file.DATE before hand, some do nothing :).
  
  Francisco Mancardi [fman@uyr.com.ar] has written a simple script that can be used to save a copy of a file or directory before doing modifications.
  Saveit is a little tool to make a backup of config files before you change them. It saves a copy under /Backup.d/DATE/ and logs "who saved what file" in /Backup.d/log-DATE. The existing directory structure is preserved under the backup directory.
  It's a simple, but useful version control tool for text files. e.g.

  etc/[9]% saveit vfstab
  copying file vfstab ===> /Backup.d/20000707/etc/vfstab

  etc/[61]% saveit vfstab
  copying file vfstab ===> /Backup.d/20000707/etc/vfstab.13:37

  etc/[10]% ls -l /Backup.d/20000707/etc/vfs*
  -rw-r--r-- 1 root sys 386 Mar 14 08:31 /Backup.d/20000707/etc/vfstab
  -rw-r--r-- 1 root sys 386 Mar 14 08:31 /Backup.d/20000707/etc/vfstab.13:37
  
  ./ ../ vfstab
  etc/[11]% tail /Backup.d/log-20000707
  ----------------------------------
  Backup base directory /Backup.d
  Backup requested by root
  Date (dd/mm/aaaa) 07-07-2000
  Time 11:36
  /etc/vfstab
  --------------------------------------------------------------
  Backup base directory /Backup.d
  Backup requested by root
  Date (dd/mm/aaaa) 07-07-2000
  Time 13:37
  /etc/vfstab

  The advantage of this tool are: simplicity and no clogging up the current directory with old versions of files, rcs directories etc. The script can be downloaded [3].

• NTP

  If you are running ntpd on a machine only as a client, then refuse remote requests by adding the following to /etc/ntp.conf or /etc/inet/ntp.conf:

  # Don't allow others to connect to this NTP daemon:
  restrict default ignore

   

References

Changes to this article

18.Aug.00 sb First version pulled from RH & Solaris Hardening notes, extended with Yassp info.
 Constant minor updates since then...

Seán Boran is an IT security consultant based in Switzerland and the author of the online IT Security Cookbook.