Geek News
Linux Security News

[IL]

Introduction
References
Post-install customization
Security
Reliability
Performance

2000-11-11
Network layer models
History of Ethernet
IP mechanics, including the
ever-popular three-way handshake!
Packet filtering strategies
ipchains packet filtering

2000-09-09
Compiling Apache with mod_perl and FastCGI
Virtual servers for Apache
Top 5 security tips for casual Linux user

A perl module that parses dirty
XML from content syndicators.

Get some content from XMLTree,
preferably in OCS format,
then parse it with RSSLite.

I built the Lazy LFS Make System
to help automate the (re-)build
of my own linux distro. LFS stands
for Linux From Scratch. Many
thanks to Gerard Beekmans
for creating this fine work!

pgcc optimizations
pgcc main site

Security
    Obscurity
        Change login text
        Change "passwd" prompt
        Make Sendmail less chatty
    Minimize risk
        Disable NFS
        Use secure daemons
        Eliminate FTP daemon
        Encrypt POP passwords
        Secure telnet access
        Secure DNS
        Disable Apache symlinks
    Minimize access
        Strong PAM default policy
        Restrict login access
        Limit root access
        Password-protect physical access
        Defining acceptable IP traffic
            Default TCP Wrapper policy
            Selectively permit access
            Configure your internet super-server (inetd)
            Check your inetd.conf
    Passwords
        MD5 encryption
        Password policy
        Password length, part II
        Prevent password re-use
        One-time passwords
    Super-user accounts
        Create alternate super-user account
        Booby-trap root logins
        Hide uid 0 command history
    Restrict privileges
        Execution permissions
        Restrict cron to root
        Limit user resource consumption
        Limit certain programs to console
        Tighter umask

Security

Although you should never rely solely on security through obscurity to protect your systems, it is still an important first hurdle in the implementation of security in depth. Here are some ways to hide info crackers might use against you.

Your login screens should contain static text that does not reveal what system you are running. Unfortunately, /etc/rc.d/rc.local broadcasts the OS and version by modifying /etc/issue & /etc/issue.net at start-up. Remove this functionality, and just put your preferred legalese text in /etc/issue & /etc/issue.net instead.

Change the options on pam_cracklib.so in /etc/pam.d/passwd; see doc in /usr/doc/pam*/html/pam-6.html. Add 'type=system' to password/pam_cracklib.so parm list to replace phrase 'Unix' with 'system' when changing passwords.

Add this line to /etc/sendmail.cf to disable sendmail's SMTP EXPN/VRFY commands:

    O PrivacyOptions=authwarnings,noexpn,novrfy,goaway
    

If you use m4 to configure Sendmail, the statement you need is:

    define('confPRIVACY_FLAGS','authwarnings,noexpn,novrfy,goaway')dnl
    

Broadcast less by adding these lines:

    O SmtpGreetingMessage=No unsolicited mail allowed: C=US, L=WI
    O HelpFile=
    

Some programs are just plain prone to exploitation. Disable or remove them using these tips.

Make sure /etc/exports is empty to disable accidental use of NFS. If you don't need NFS, remove it from your system altogether.

Replace fptd or wu-fptd with proftpd. Better yet, don't run an ftp server at all, just set up a directory under your webroot and let the files be downloaded via HTTP. If you do run an ftp server, disallow anonymous access. Make sure root has no access and that any attempt by root to access the ftp server triggers an alarm.

Eliminate need for ftp uploads by using scp instead (part of the SSH package). It's easier to use than an ftp session anyway. FTP downloads can be replaced by HTTP.

Use encrypted POP so username/password is not transmitted in the clear. This helps prevent hijacking accounts to store and use cracking tools. Unfortunately, this isn't as easy as it might seem, however, some clients like Outlook and Eudora do support it on the client side.

I know of three stepping-stones on the quest to secure POP3:

• Use the APOP protocol instead of POP3
• Use client-side SSH port forwarding
• Use an SSL-enabled client with an SSL-wrapped server (check out http://www.rickk.com/sslwrap/)
• More info later...

Install SSH and uninstall telnet/telnetd. SSH can be found at http://www.openssh.com/portable.html. The "old" version is at ftp://ftp.fi.muni.cz/pub/linux/redhat-crypto/i386/.

In addition to encrypting remote terminal access so passwords aren't sniffed off the wire, SSH adds several other useful tools such as port forwarding over encrypted channels and a secure replacement for rcp called, strangely enough, scp.

"BIND" has it's fair share of root exploits. Using these instructions, you can install and run BIND as a non-root user from a chroot'ed "jail". This prevents a cracked BIND from giving root access to your system.

    /usr/sbin/groupadd -g 150 dns
    /usr/sbin/useradd -u 150 -g 150 -M -s /bin/false dns
    mkdir 0700 /home/dns
    mkdir 0755 /home/dns/etc
    mkdir 0755 /home/dns/lib
    mkdir 0755 /home/dns/dev
    mkdir 0755 /home/dns/usr
    mkdir 0755 /home/dns/usr/sbin
    mkdir 0755 /home/dns/var
    mkdir 0755 /home/dns/var/named
    mkdir 0755 /home/dns/var/run
    /bin/mknod -m 666 /home/dns/dev/null c 1 3
    /bin/cp /etc/named.conf /home/dns/etc/
    /bin/cp /var/named/* /home/dns/var/named
    /bin/chown -R dns.dns /home/dns/var/named /home/dns/var/run
    /bin/cp /usr/sbin/{named,named-xfer} /home/dns/usr/sbin
    /bin/cp /lib/libc.so.6 /home/dns/lib
    /bin/cp /lib/ld-linux.so.2 /home/dns/lib
    

Change line in "/etc/rc.d/init.d/syslog" that reads "daemon syslog -m 0" to "daemon syslog -a /home/dns/dev/log", then execute "chmod 0755 /etc/rc.d/init.d/syslog".

Change line in "/etc/rc.d/init.d/named" that reads "daemon named" to "daemon named -u dns -g dns -t /home/dns", then execute "chmod 0755 /etc/rc.d/init.d/named".

Disable Apache "followsymlinks" by removing it from the "Options..." line. Not only will this make Apache run faster, it will also help reduce the possiblity of exposing sensitive data to the world via symlinks outside your webroot.

Change your PAM configuration so it contains a strong default fall-thru policy with logging. In addition to denying inappropriate access, this will help you detect mis-configured PAM entries. It's contained in /etc/pam.d/other, like this:

    auth     required       /lib/security/pam_deny.so
    auth     required       /lib/security/pam_warn.so
    account  required       /lib/security/pam_deny.so
    account  required       /lib/security/pam_warn.so
    password required       /lib/security/pam_deny.so
    password required       /lib/security/pam_warn.so
    session  required       /lib/security/pam_deny.so
    session  required       /lib/security/pam_warn.so
    

Customize /etc/security/access.conf to control who can log in. This allows you to have accounts defined (for example, POP3 accounts) that won't actually be allowed to login to a shell. This needs to be enabled in PAM by adding an 'account/required/pam_access.so' line to /etc/pam.d/login' per instructions for 'pam_access' in section 6.1 of /usr/doc/pam*/txt/pam.txt. Also, as shipped the sample access.conf file contains a mistake--the phrase 'console' needs to be changed to 'tty1 tty2 tty3 tty4', etc. to specifically enumerate the virtual consoles.

Change /etc/securetty to restrict terminals root can login to. Ideally you will limit root logins to the console devices, like 'tty1'.

Add the option "restricted password=xxx" to the header section of /etc/lilo.conf. Don't forget to run /sbin/lilo to activate the change. This password is required by LILO when booting into single-user mode, and prevents someone with physical access to the server from cracking your system during a single-user boot. Make sure that /etc/lilo.conf permissions are set to u=rw,go= (600).

Require root password even when booting into single-user mode by adding "~~:S:wait:/sbin/sulogin" immediately after "si::sysinit:/etc/rc.d/rc.sysinit" in /etc/inittab.

You should restrict the nature of IP connections to your machine to those you have explicitly defined as "okay". Many internet daemons, such as telnetd, have no provisions for defining who can use the service. There are several "wrapper" systems available that can add this type of protection to existing internet daemons. I recommend one of two: TCP wrappers (tcpd) by Wietse Venema, or tcpserver by D. J. Bernstein. The first, TCP wrappers, is included with most Linux distributions and is probably the most widely known. However, you may want to consider the "tcpserver" program written by D. J. Bernstein, author of Qmail, as an alternative; it combines the functionality of both TCP wrappers and inetd in a very modular fashion that makes it easy to put into use for all kinds of TCP connections, and it is supposed to be more resistant to DOS attacks as well. I use tcpserver.

You should setup your tcpd configuration so that access is denied unless it has been explicitly allowed. To set your default wrapper policy to DENY, make /etc/hosts.deny read:

    ALL : ALL, PARANOID
    

Enable access via tcpd by adding entries to /etc/hosts.allow. See /usr/doc/tcp_wrappers*/README for specifics.

Enable/disable services in inetd.conf. There are normally many unnecessary services enabled by the default installation. A short list of unnecessary/unsafe services that you should disable include: apmd, atd, pcmcia, dhcpd, gpm, innd, linuxconf, arpwatch, autofs, bootparamd, mars-nwe, mcserv, postgresql, rstatd, rusersd, rwalld, rwhod... Also consider whether you actually need the following services: portmap, nfs, netfs, smb, dhcpd, amd, sendmail, gated, routed, snmpd, squid, xntpd, ypbind, yppasswdd, ypserv...

Better yet, uninstall inetd and replace with xinetd, which has better facilities for preventing DOS attacks, or use tcpserver as yet another alternative.

Any services that remain enabled should be restricted to authorized use via /etc/hosts.allow.

After setting up inetd.conf, hosts.deny, & hosts.allow, run tcpdchk to scan for configuration errors (only works with inetd).

Make sure you're running MD5 shadow passwords. The easiest way is to select MD5 encryption at install time. MD5 encryption allows you to have arbitrarily long passwords, which makes it easier to impose a strong password policy (because you can use easily remembered sentences).

Modify /etc/login.defs to implement password policy according to instructions in /usr/doc/shadow-utils*/HOWTO. This configuration file allows you to control the number of days before a password expires, minimum password length, and settings that control the useradd/userdel commands. If you're running Qmail instead of Sendmail, comment out MAIL_DIR and un-comment QMAIL_DIR. You should make sure your PASS_MIN_LEN is at least 8, preferably longer.

Change the options on pam_cracklib.so in /etc/pam.d/passwd; see doc in /usr/doc/pam*/html/pam-6.html. Add 'minlen=nnn' to enforce minimum length.

Use the "difok" option of pam_cracklib to require at least X number of characters to be different when a user changes password.

One-time passwords can be implemented via PAM by software available at http://inner.net/pub/opie/opie-2.32.tar.gz and http://inner.net/pub/opie/contrib/pam_opie-0.21.tar.gz

Create separate super-user account(s) with same uid/gid as root (normally 0/0), then never use root again. Any logins by user root should be a warning that someone unauthorized has compromised the server. Make sure the home directories for super-user accounts have permissions set to u=rwx,go= (700).

Booby-trap /root/.bashrc so it sends warning mail whenever a login occurs. You can do this by simply adding this line to root's /root/.bashrc file:

    echo 'Panic: root login!' | mail -s 'Panic: root login!' admin1@localhost admin2@remotehost.com
    

For super-user accounts with uid 0, set HISTFILESIZE=0 and HISTSIZE=10 in /root/.bashrc so super-user command history can't be seen outside current session.

A typical Linux installation results in many programs being set to world-executable. For servers, you probably don't need any world-executable programs. Execute this file-perms script to restrict access to binaries.

Restrict the use of cron to root by creating /etc/cron.allow and adding a single line saying "root" (see 'man crontab').

Customize /etc/security/limits.conf to place limits on resource usage. You can limit creation of core files, max processes, number of processes per user, etc. If the comments in the limit.conf file don't make it clear, you can look at section 6.11 in /usr/doc/pam*/txts/pam.txt.

Add files to /etc/security/console.apps/ to restrict programs so they can only be run from the console...for example, "reboot".

Change your umask to 077, especially for uid 0 accounts. With a umask of 077, any new files you create will have their permissions set to u=rw,go= (600). This helps prevent inadvertent access to files that should have been private by requiring you to explicitly share them.

You can change the umask for all users via /etc/profile, or individual users via ~/.bashrc.