PREVIOUS_FORMAT/security.txt

   1 TITLE:          Secured LFS
   2 LFS VERSION:    3.3 (but really any)
   3 AUTHOR:         James Smaby <jsmaby@virgo.umeche.maine.edu>
   4
   5 SYNOPSIS:
   6         Turn that shiny new LFS into a chained down fortress.
   7
   8 HINT:
   9    Most linux distros out there don't pay enough attention to security
  10 as they should.  They normally sacrifice security for ease of use.
  11 Unfortunately, LFS--though not a distro--does the same thing.  Sure,
  12 it doesn't run any services by default, and has only a bare minimum
  13 of packages installed, but even then, there's a lot that can be fixed
  14 up.  A linux system should be secured down so that even a cracker with
  15 a local account can't root the box.  It is generally accepted as being
  16 trivial to do so with linux though.  After following this hint, it is
  17 hoped that there will be a base system that will allow you to give
  18 accounts to even the most questionable friends with ease of mind.
  19
  20 _Worst Case Scenario_
  21    In the worst case, a cracker gets root on the system.  If this should
  22 happen, we want to minimize the damage that can be done.  Normally
  23 there are five things that the cracker could do:
  24 1. # nohup dd if=/dev/zero of=/dev/hda
  25   This would be a smart, though nasty cracker.  If you don't use hda
  26   very often, make it a copy of /dev/null, so that the dd won't trash
  27   the hard drive.  And, of course, make backups often.
  28 2. # rm -rf /
  29   A favorite of stupid kiddies that don't like you.  It might be worth
  30   patching rm so that this particular command doesn't work.  You could
  31   also make a very complex directory structure in /a, so that you have
  32   time to kill the rm before it gets to the system.  It's always a good
  33   idea to keep as many partitions as possible mounted read-only, and
  34   have backups of the system.
  35 3. # tar zxf my_rootkit.tgz
  36   The most common thing for a cracker to do.  Keep md5sums of all the
  37   files on the system so that you can see what has changed.
  38 4. # nmap, tcpdump, etc.
  39   If they don't really care about, they'll just start scanning for
  40   more open hosts, grab passwords, and so on.  To clean up, kill the
  41   processes, and look for an installed rootkit.
  42 5. # touch ~/haha_I_hacked_you
  43   A prankster (maybe an IRC buddy) got in, and wanted to let you know.
  44   Ask them how they got in, and close up that hole.  Check for a
  45   rootkit, just in case.
  46 For all these things, you should check your logs to try and figure out
  47 how they got in, so that you can fix the hole.  Always change your
  48 passwords if people have had access to you /etc/shadow.
  49
  50 _User-level access_
  51    Either a network daemon was compromised, or you've given out accounts
  52 to the wrong sort of people.  The things they can do to you are:
  53 1. $ rm -rf /
  54   A quite silly thing to do, as it will only delete files that exist in
  55   (non-sticky-bit) directories that are writable by that user.  If your
  56   IRC client is compromised, this will delete all of you user's files.
  57   Since this is quite unwanted, IRC as a dummy account.  Other ways into
  58   your account include web browsers (with javascript enabled), some
  59   mail clients, and compiling/installing/running untrusted software.
  60   All these things can either not be done, or done with a dummy account.
  61 2. $ find / -perm -4000 -o -perm -2000
  62   Programs with the setuid or setgid bits set run as the owner/group of
  63   that binary.  Some programs need root privileges in order to work
  64   correctly.  A couple examples are su, ping, passwd, and XFree86.
  65   These have the setuid bit set so that users can start them.  By
  66   looking for bugs in these programs (buffer overflows are a favorite),
  67   a crafty cracker can run arbitrary commands as root.  The fix is to
  68   remove the bits from any programs that don't need to be run by your user.
  69   One can change passwords as root, and start X via xdm.  One could
  70   even get rid of all setuid bits completely, and have init put a root
  71   shell on tty1 for system maintenance.
  72 3. $ ps --user=root -u
  73   Look for daemons running as root, and try to convince them to do
  74   stuff.  Many daemons can drop privileges, and run as nobody, or
  75   a specific user.  Those that can't can always bu run in chroot, so
  76   in the init script you may have
  77     cd /static && chroot . bin/daemon
  78   If the daemon is compiled statically, that makes setting up the chroot
  79   environment trivial.
  80 4. $ for PID in `seq $$ $[$$+1000]`; do ln -s /etc/shadow /tmp/foo$PID; done
  81   Some programs use mktemp, tmpnam, or just getpid() to choose temporary
  82   filenames.  If the program isn't careful, such a symlink attack as
  83   shown could lead to mangling the passwd file if the program is run
  84   by root.  One should keep a lookout for linktime warnings about mktemp
  85   usage, grep ones binaries for the string mktemp, and keep an eye on
  86   what files are in /tmp, to see if any have predictable names.
  87 5. $ echo 'main(){while(1) fork();}' > fork.c && make fork && ./fork
  88   There are many ways to DOS a box with a local account.  My favorite is
  89   the forkbomb.  To fix it, try as root killall -STOP fork; killall -9 fork
  90   To avoid the unpleasant thing from happening in the first place, set
  91   ulimit so that a user can't eat up the process table, or fill up RAM,
  92   or hog the CPU.
  93
  94
  95 _Remote access_
  96    While LFS has no daemons running, it is still accessible from the net.
  97 You may want to install sshd, a web server, or something else to make
  98 the box more useful.  Securing these services from remote attackers
  99 is extremely important.  Some things to keep in mind:
 100 1. Run network services as an unprivileged user, and preferably in
 101   a chroot jail.  Keep up to date on version releases.  Only run
 102   services that were written with security in mind (sshd, qmail, not telnet).
 103 2. LFS comes with inetd from netkit-base.  Don't use it.  Use stand-
 104   alone servers, or xinetd.  In the old days, tcpwrappers was used
 105   with this.  Now, use iptables to firewall off your service's ports
 106   from IPs that don't need to use them (i.e. ssh connections only from
 107   your own hosts).
 108 3. The disgruntled script kiddie that can't get into your box may resort
 109   to denial of service attacks.  Stop ping floods by setting an appropriate
 110   number in /proc/sys/net/ipv4/icmp_ratelimit.  You can stop SYN floods
 111   by enabling syncookies in the kernel.  And if someone is still bothering
 112   you, iptables can let you drop all packets from their IP.
 113
 114
 115 _Other hints_
 116
 117    Apply all the given patches to LFS's sources. There isn't an official
 118 home for them yet, but try downloading from
 119 < http://virgo.umeche.maine.edu/misc/security_patches.tar.gz >
 120 and send bug reports to jsmaby@virgo.umeche.maine.edu
 121
 122    Sudo is an excellent little tool which allows a user (depending on the
 123 configuration) to execute a command as root, but w/o giving them root's
 124 password.  It's great if you just want a user to be able to
 125 restart a webserver or certain daemon; http://www.courtesan.com/sudo/
 126
 127    For system accounts that people shouldn't be able to log into, use
 128 /bin/false as the login shell, and /dev/null as home.  If they are
 129 left blank (bin:x:1:1:bin::), login defaults to /bin/sh and /.
 130
 131    Make sure to enable MD5 passwords in /etc/login.defs, then change
 132 your passwords to apply it.  This will allow passwords larger than
 133 eight characters.  Try running a dictionary-based password cracker on
 134 the encrypted passwords of you and any user on the system to find
 135 week passwords that need to be changed.
 136
 137    Break the system up into multiple partitions.  The only parts of the
 138 filesystem that should be writable are /home and /var.  Some programs
 139 may complain about / being mounted read-only though (like kdm).  Parts
 140 of the filesystem could also be mounted with noexec, nosuid, nodev, and
 141 so on.
 142
 143    After getting the system setup the way you want, either use Tripwire,
 144 or just take md5sums of all the files on the system.  Try the following
 145 (really slow) script to keep track of md5sums:
 146
 147 #!/bin/bash
 148 mv /var/log/checksums /var/log/checksums.old
 149 DIRS="/bin /boot /etc /lib /root /sbin /usr"
 150 for DIR in $DIRS; do
 151   FILES=`find $DIR -type f -o -type l`
 152   for FILE in $FILES; do
 153     SUM=`md5sum $FILE 2> /dev/null`
 154     echo $SUM >> /var/log/checksums
 155     SUM=`echo $SUM | cut -d " " -f 1`
 156     OLDSUM=`grep " $FILE$" /var/log/checksums.old | cut -d " " -f 1`
 157     if [ "$SUM" != "$OLDSUM" ]; then
 158       echo $FILE
 159     fi
 160   done
 161 done
 162 echo "Old overall checksum:"
 163 md5sum /var/log/checksums.old
 164 echo "New overall checksum:"
 165 md5sum /var/log/checksums
 166
 167 Make sure to put a copy of the checksums on a floppy disk (and take
 168 the disk out of the computer), and write down the overall checksums
 169 so that you'll know if they've been tampered with.
 170
 171    Make sure to check permissions after installing everything.  Look
 172 for setuid bits, and world writable files and directories.  Use find
 173 commands similar to the second user-level access cracker's command.
 174
 175    A good replacement for syslogd is syslog-ng.  It allows for easier
 176 sorting, and is more powerful.  Either way, consider having logs
 177 sent to a log server, so that crackers can't cover their tracks
 178 by editing log files.
 179
 180    For more fine grained kernel-level security, check out the patches
 181 at < http://www.lids.org >.
 182
 183    Another kernel-level security enhancement is at
 184 < http://www.nsa.gov/selinux >, but is redhat-centered, so maybe
 185 of minimal use to LFSers.
 186
 187    A security-conscious distribution is at < http://www.openwall.com/Owl >.
 188 Their package source is distributed as SRPMs, but after unpacking them,
 189 patches to the program are given (although not always an explanation
 190 of what they do).  It is always good to take a look at what patches
 191 they're applying before installing a new package.
 192