Originally Published: Saturday, 21 August 1999 Author: Jim Hewlett
Published to: enchance_articles_security/Advanced Security Articles Page: 1/1 - [Printable]

Post Installation Security part two - by Jim Hewlett

In the follow up to David Jericho's Post Installation Security, Jim has written about the dangers of setuid zero software; the benefits of TCP wrappers; securing the system, and thousands of other topics to help you keep your machine going after you've popped the installation CD out of the drive.

   Page 1 of 1  

This article is part 2 of Post Install Security (part 1/2) by David Jericho. If you haven't read that yet, please take the time to read his article before reading mine.

OK, on with the show.

  • The first thing to do now is trek over to your nearest distro site and download/install any updates for your system. This is an important step, be sure and check for updates often.
  • Next, find those pesky suid files and give them a bit of pruning. We can accomplish this with find.
~[root(christine)10]#: find / \( -perm -04000 -o -perm -02000 \) -exec ls -ald {} \; The output of this may be something like (comments in italics):
drwxr-sr-x 3 root root 3072 May 19 22:49 /usr/doc/G2player-6.0/RealHelp drwxr-sr-x 2 root root 1024 May 19 22:49 /usr/doc/G2player-6.0/RealHelp/graphics drwxrwsr-x 2 zeppelin zeppelin 1024 May 25 15:42 /home/zeppelin/doc/ipchains-HOWTOs-1.0.6 drwxrwsr-x 2 root games 2048 Aug 6 13:57 /var/lib/games drwxrws-wt 2 root root 1024 Jul 18 01:00 /home/ftp/incoming
Suid directories allow any file put in these directories to become user or group owned by whoever is set on the suid bit. Linux ext2 however doesn't honor these bits. A patch ran across bugtraq not too long ago from Henrik Nordstrom that adds this support. If you're interested in this and don't know how to apply a patch, usually cd /usr/src/; patch -p0 </path/to/patch will work fine. Otherwise man patch for more info
-r-sr-xr-x 1 root root 75232 May 1 02:15 /sbin/pwdb_chkpwd
Seems like something you might need, but i've never had that need.
-rwsr-xr-x 1 root root 1454252 Dec 11 1998 /usr/bin/dos -rws--x--x 1 root root 6116 Jun 14 10:40 /usr/X11R6/bin/Xwrapper -r-sr-xr-x 1 root root 5604 May 6 1998 /usr/X11R6/bin/XConsole -rwsr-xr-x 1 root root 56852 May 7 1998 /usr/X11R6/bin/rxvt -r-sr-xr-x 1 root root 2044124 Apr 9 21:28 /usr/local/bin/vmware
For these i would make a group "console" (groupadd console) and make the modes 4550, then add anyone that would use such things (usually at the console) to the "console" group. See about rxvt below.
-rwsr-xr-x 1 root root 20328 May 5 1998 /usr/bin/crontab
If you want your users to be able to setup cron jobs, leave this suid. You could optionally make a group "cron" and put those users you want to do cron jobs in that group. chmod 4550 and chown root.cron. Also look into man 1 crontab for allow/deny
-r-xr-sr-x 1 root lp 22452 May 5 1998 /usr/sbin/lpc -r-sr-sr-x 1 root lp 14164 May 5 1998 /usr/bin/lpq -r-sr-sr-x 1 root lp 15164 May 5 1998 /usr/bin/lpr -r-sr-sr-x 1 root lp 14860 May 5 1998 /usr/bin/lprm
If you don't have a printer, zap these. I would put these in their own group too if wanted to leave them suid. I suggest trying "LPRng" over the default. It's got some nifty features.
-rwxr-sr-x 1 root slocate 22096 May 6 16:04 /usr/bin/slocate
slocate is installed default in RH6.0 as opposed to earlier versions which didn't include it. Leave it suid group so it can read the locate database.
-r-sr-xr-x 1 root bin 15613 Apr 27 1998 /usr/bin/passwd -rwsr-xr-x 1 root root 121040 Apr 25 04:22 /bin/su
You'll definitely want to leave these suid. If you have PAM you can setup su so the user trying to run su has to be in a certain group. Add the following to /etc/pam.d/su (order makes a difference, try adding this at the top of your config):
auth required /lib/security/pam_wheel.so group=group_user_must_be_in debug auth sufficient /lib/security/pam_rootok.so debug

i use "debug" because i like to know what's going on.

-rwsr-xr-x 1 root bin 19230 Apr 27 1998 /usr/sbin/traceroute -rwsr-xr-x 1 root root 14340 May 5 1998 /bin/ping
I used to leave these alone, but these two bins have had buffer overflows in the past and have been sources of problems on my machines due to moron users. I now add these to my admin group and no one else has any access. Other users may complain, but hey, you're fascist.
-rwxr-sr-x 1 root utmp 15587 Jun 9 08:30 /usr/sbin/utempter
(From rpm -qi utempter) "Utempter is a utility which allows programs to log information to a privileged file (/var/run/utmp), without compromising system security. It accomplishes this task by acting as a buffer between root and the programs." With this things like rxvt, screen, or anything else that writes to the utmp/wtmp will no longer need the suid bit. You should also use /dev/ptmx (UNIX98) support with the new 2.2 kernels.
-rwsr-sr-x 1 root mail 276044 May 5 1998 /usr/sbin/sendmail
This doesn't need to be suid unless you're running a mail server. In that case i suggest going out and getting the latest version of sendmail, or my personal favorite, Qmail.
-rwsr-xr-x 1 root root 34131 Apr 1 13:09 /usr/libexec/pt_chown -rwxr-sr-x 1 root utmp 8504 Jul 21 14:40 /usr/sbin/gnome-pty-helper
These two are similar to utmpter. I however am paranoid and don't trust them.
-rwsr-xr-x 1 root root 58428 Apr 19 01:57 /bin/mount -rwsr-xr-x 1 root root 31516 Apr 19 01:57 /bin/umount -rwxr-sr-x 1 root root 7940 Jun 29 18:29 /sbin/netreport -rwsr-xr-x 1 root root 8952 May 8 1998 /sbin/cardctl -rwsr-xr-x 1 root root 23704 Apr 19 01:57 /bin/login -rwsr-xr-x 1 root root 30520 May 5 1998 /usr/bin/at -rwsr-xr-x 1 root root 34748 May 27 15:11 /usr/bin/chage -rwsr-xr-x 1 root root 34568 May 27 15:11 /usr/bin/gpasswd -rwxr-sr-x 1 root man 31356 Jun 2 1998 /usr/bin/man -rws--x--x 2 root root 615016 Feb 21 03:02 /usr/bin/suidperl -rwxr-sr-x 1 root mail 9372 Apr 27 1998 /usr/bin/lockfile -rwsr-sr-x 1 root mail 54740 Apr 27 1998 /usr/bin/procmail -rwsr-xr-x 1 root root 189672 May 3 00:57 /usr/bin/ssh1 -rwsr-xr-x 1 root root 13876 Apr 24 1998 /usr/bin/rcp -rwsr-xr-x 1 root root 10352 Apr 24 1998 /usr/bin/rlogin -rwsr-xr-x 1 root root 7044 Apr 24 1998 /usr/bin/rsh -r-xr-sr-x 1 root tty 10456 May 27 15:12 /usr/bin/wall -rws--x--x 1 root root 18032 Apr 19 01:57 /usr/bin/chfn -rws--x--x 1 root root 17840 Apr 19 01:57 /usr/bin/chsh -rws--x--x 1 root root 9688 Apr 19 01:57 /usr/bin/newgrp -rwxr-sr-x 1 root tty 12476 Apr 19 01:57 /usr/bin/write -r-s--x--x 1 root root 123988 Jun 9 1998 /usr/bin/zgv -rwsr-xr-x 1 root root 61412 Jan 3 1999 /usr/bin/tconf -rws--x--x 2 root root 615016 Feb 21 03:02 /usr/bin/sperl5.00554 ---x--s--x 1 root games 67372 Jul 8 13:41 /usr/bin/gnibbles ---x--s--x 1 root games 28408 Jul 8 13:41 /usr/bin/gnobots ---x--s--x 1 root games 75900 Jul 8 13:41 /usr/bin/gnobots2 ---x--s--x 1 root games 52592 Jul 8 13:41 /usr/bin/gnome-stones ---x--s--x 1 root games 71424 Jul 8 13:41 /usr/bin/gnomine ---x--s--x 1 root games 25972 Jul 8 13:41 /usr/bin/gnotravex ---x--s--x 1 root games 231096 Jul 8 13:41 /usr/bin/gtali ---x--s--x 1 root games 24156 Jul 8 13:41 /usr/bin/gturing ---x--s--x 1 root games 47612 Jul 8 13:41 /usr/bin/iagno ---x--s--x 1 root games 39620 Jul 8 13:41 /usr/bin/mahjongg ---x--s--x 1 root games 21268 Jul 8 13:41 /usr/bin/same-gnome -rwsr-x--- 1 root root 225583 Apr 4 23:15 /usr/local/bin/nessusd -rwsr-xr-x 1 root root 9980 Jun 29 18:29 /usr/sbin/usernetctl -rwsr-xr-x 1 root root 26273 Jun 9 1998 /usr/sbin/userhelper -rwsr-sr-x 1 root root 187036 Jun 16 11:15 /usr/bin/screen
The rest of these can lose the suid bits.
When finished, you'll have something similar to: drwxrws-wt 2 root ftpadm 1024 Aug 5 20:02 /home/ftp/incoming -r-sr-x--x 1 root bin 15613 Apr 27 1998 /usr/bin/passwd -r-sr-x--- 1 root cron 26156 Feb 12 1999 /usr/bin/crontab -r-sr-x--- 1 root admin 30244 Feb 12 1999 /usr/local/bin/ping -r-sr-x--- 1 root admin 27684 Feb 12 1999 /usr/local/sbin/traceroute -r-sr-x--- 1 root su 124279 Apr 20 02:03 /bin/su
  • "Who can it be now?" (sort of makes you want to sing that The Police song.)
From time to time you should expect visitors knocking on your door. Usually they are unwanted, so here lets talk of ways to keep them out.
  1. TCP_Wrappers

    TCP_Wrappers are a godsend for access control. Using the files /etc/hosts.allow and /etc/hosts.deny you can reject connections from those whom you do not want. However, in order to do this, you need to wrap those daemons within tcpd. We'll use in.telnetd and in.ftpd for our /etc/inetd.conf example:

    ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
    Here we're wrapping in.ftpd and in.telnetd with /usr/sbin/tcpd (the tcp_wrappers binary). Now when anyone tries to connect to either of those services, tcpd will check /etc/hosts.allow and /etc/hosts.deny. Daemons listed in the hosts.allow/deny files are the actual program names instead of the service name. For example, daemon name in.ftpd instead of the service name of ftp

    A good setup for these files is as follows:

    ~[root(christine)35]#: cat /etc/hosts.deny ALL: ALL : banners /etc/banners

    This denys all tcp wrapped services to everyone.

    ~[root(christine)36]#: cat /etc/hosts.allow in.telnetd: 10.11.7. in.ftpd: 10.11.7. ALL: 127.0.0.1

    10.11.7.* is allowed to connected to in.telnetd and in.ftpd. localhost is allowed to connect to anything. banners will look for a file in /etc/banners with a corresponding name of the daemon (ie; /etc/banners/in.telnetd) and print the text inside the file to the denied client. Useful for telling the client why he or she was denied. See man 5 hosts_options for more info on this and other goodies.

  2. Firewall
    ipchains (the ipfwadm for the new 2.2 kernels) is another thing you should use for rejecting/denying connections. However, i won't be covering this here. Jason Tackaberry is doing an entire article on this. See his article sometime at the end of this month (august '99)
While we're talking about connections, lets talk about those ever so plentiful port scans you'll have the pleasure of enjoying. Port scans are a method of a gathering information about a machine and they've become quite sophisticated these days. Nmap is one such scanner. Its important to pay attention to port scans, as often they are the predecessor to an attack. However, that being said, if your machine and services are patched and up to date on the latest exploits you have nothing to worry about. Such tools to monitor your log files can be obtained at http://www.psionic.com/abacus. You can also do portscan detection with IPchains as well. It's important to note here that you should protect your log files. Once someone compromises your machine they will generally clean up after themselves and remove traces from log files and utmp/wtmp entries. One way to protect your logs is to use the "remote logging" feature of syslogd. To do this, add to your syslog.conf file:
*.*;mail.none     @scott
This will log all syslog activity (minus mail traffic) to the remote host "scott," (you'll need to start scott's syslogd with the -r option.) Note that the spaces there are TABS, you must use tabs. Firewall off scott's syslogd port so that only your other machine can communicate with it. The reason we do this is that some meanie can flood the remote log host with nonesense and fill up your syslog, thus filling up your hard drive. It also couldn't hurt to mount /var (or wherever you decide to have logs written) on its own partition. If your machine has been compromised and log files edited, its likely system binaries have also been tampered with. Frequent use of TripWire will check the integrity of your files. Version 2.0 is free. It's also wise to keep your database and TripWire binaries on read only media for obvious reasons. Lastly, while still on the subject of logs, it's a good idea to use BSD Process Accounting. This will give you a good idea about your processes and who is running them. This can be enabled in the kernel. You'll also need a user level program for this to work. I'm using psacct-6.3-10 from RedHat's distribution.
  • Security from the other side of the network. Gotta love your users!
  1. Services If you're gonna have users, they'll need to connect to you somehow. The first thing we want to do here is use secure services, ones that don't display things in clear text. Password sniffing is an easy way to bust into someone's machine. To cure that problem, we'll replace telnet/rsh/rlogin with SSH to encrypt communications. As for securing ftp, take a peek at my other article on ftp. That article will probably be rotated out to somewhere else, so just look for it by clicking on the "older articles" link if it isn't at the previous URL.
  2. Passwords Passwords shouldn't be dictionary words, and should be comprised of letters, numbers and symbols if possible. Enforcing good passwords can be achieved by using Cracklib. For RedHat this is usually already installed. Use Shadowed passwords. On RedHat this can be enabled with pwconv. Don't be lulled into a false sense of security now that your users can't actively see the passwords. Programs that can read the shadow file and act on behalf of a user, if buggy, can be tricked to displaying the contents.

    Use stronger password algorithms, such as MD5. On slackware this can be enabled by editing the /etc/login.defs file, and on RedHat adding "md5" to the following files, like so:

    /etc/pam.d/passwd: password required /lib/security/pam_pwdb.so use_authtok nullok md5
    /etc/pam.d/su: password required /lib/security/pam_pwdb.so shadow use_authtok md5
  3. weeeeeee, users! Sometimes you'll find yourself with nosey users (nothing fundamentally wrong with that, of course) and those users you want to slap their hand and say "BAD MONKEY!"
    • Less is best It's my philosophy that if a user doesn't need to do a certain thing, or view a certain file, then this user should not be able to. When giving users extra privileges, only give that user the least amount of extra privs that he or she needs to complete the task. Examples of this might be a user who only needs to read a directory, give them only the read permission. Another user needs to administrate a virtual web directory, create a docweb group and assign it the appropriate rights to only those files/directories that will be changed and add the user to it. This may sound like a "well, duh" but you'd be suprised how many users have more access than they should have. Sometimes its easy to overlook. This is the concept behind the new 2.2 kernel's "capabilities." Still not completely implemented, it's still very useful. You can, for example, give Xntpd only the ability to change the system time and strip it of anything else. Now instead of being a process often run as root that can do many things it doesn't need to do, it is a process that can only change system time. More info on capabilities can be found at ftp://ftp.guardian.no/pub/free/linux/capabilities/
    • Granny used to tell me to keep my nose out of other people's business
    I don't see any reason why users should be able to view other people's processes. Installing the restricted proc patch will only allow users of a certain group to view network connections and user processes. Be sure and read the instructions. Solar Designer has a kernel patch that includes this type of proc restrictions and other security related enhancements such as non-exec stack and restricted links in sticky directories for older 2.0 series. There is a pre non-exec patch for the 2.2 series as well. Along these same lines you may decide that there are other things your users shouldn't be allowed to see or cd into. Such things include, but certainly not limited to, configuration files (many of which live in /etc), backup archives, logs (and other various things within /var), other users home directories. You get the point. Word to the wise, don't just go around blasting permissions on files/directories if you're not sure they'll be ok like that. Try it out afterwards and make sure whatever it is still works.
    • Yipes! Bad monkey, no banana!
    Whether intentionally or by accident, users can put a hurtin' on your machine but sucking up its resources. To put a curb on that you'll want to look into resource limits. For setting limits on the command line with bash, use ulimit, and with tcsh use limit. These limits will have to be setup for the user when he or she logs in. On RedHat, edit /etc/security/limits.conf and add to any config file in /etc/pam.d/ that handles logins ("login" and "ssh" example):
    session required /lib/security/pam_limits.so
    Slackware can set these ulimits via /etc/login.defs, or you can obtain lshell from metalab.

    All of the above only concerns users who have entered through the login prompt. Other resource limits may need to be set on things that accept user input. Such items are, httpd, xdm, cron, Mail Delivery Agents (procmail/forwards), etc. You can either set the appropriate limits for your machine in your rc files or wrap them. I should also note limits are by no means perfect and have their faults. While on this note, look into xinetd, a "powerful replacement for inetd." It can place limits on the number of services started and newer versions can do per instance too.

    • miscellany

    • Pardon me, may i have some privacy please?

      Stay away from publicly writeable temporary directories. These type of directories can lead to all sorts of problems. The use of environment variables such as TMPDIR, LYNXTMP and SCREENDIR helps some. Other times it will be necessary to physically change the tmp directory. Locatedb's script for example uses/used /tmp, which can be easily changed to write to a private directory for its temp file needs. In the event a publicly writeable directory is needed, be sure to use the sticky bit (+t). Putting /tmp on its own partition is a good idea too.

    • Defaults are for the weak

      mount has some nifty options you should look into. most notably for this example is noexec, nodev, and nosuid. This can be setup either by using the -o remount option to mount on the command line, or setup in /etc/fstab:

      /dev/hda3 /tmp ext2 nosuid,nodev,noexec 1 2
      /dev/hda2 /home ext2 nosuid,nodev 1 2

      (basically just replace default with the options you want.)
    • nobody becomes somebody!

      Ever notice how for being a nobody, the nobody user sure does do alot? Lets imagine that in.identd is compromised. Now because your httpd server is also run as "nobody" the httpd server can be tinkered with by the attacker. Create a separate user and group for each daemon that has the same privileges equivalence of a "nobody."

    • Getting into the root of things.
      1. logging in as root

        A few things on root... since the root user is the most powerful user on the machine, great care should be used when logged in as root. First lets define rules for where root can log in from. Typically this will be only from the console. Edit the file /etc/securetty and add the devices root will log in from:

        ~[root(christine)229]#: cat /etc/securetty tty1 tty2 tty3
        Check your sshd_config file for PermitRootLogin and set it to "no." Also never log in as root or su to root over a unencrypted session.
      2. Root's path Check your PATH environment for . (period) and remove it. The reason behind this is because if you're in ~eviluser and you type sl instead of ls and this user has a file that executes commands, they will execute as root. bummer. While on executing files, be wary of binaries from unknown origins as they may contain trojans. Using strings on the binary may help shed some light on the subject.
      3. Pop the question. Ask yourself "what doesn't need to be run as root?" Sometimes changing the running user is as simple as a command line or config option to the binary being run, or in some cases just using su someuser -c program. Other times small modifications may be needed to get it running as someone other than root (see capabilities above or GID split privilege patch).


Well, you've reached the end. There are so many more things that could be discussed here, you'll have to be creative and think of ways to break your own machine and fix it. Remember that security is a never-ending story. Kinda like that movie, only there is no furry, flying weener dog. Remember to do your security setup in layers, you don't want to set yourself up for a single point of failure. Stay on the ball with security updates. System administrators may want to subscribe to BugTraq. Comments, suggestions, or additions are welcome. Just point them to jh@linux.com. Jim Hewlett is a freelance UNIX Systems Administrator with over 4 years of experience maintaining machines and networks throughout the south-east.




   Page 1 of 1