Eric’s Blog

January 31st, 2007 by eric

Since everyone seemed to enjoy my first round of tips and tricks to securing a linux system, I figured I would throw together a few more. Enjoy.

1. There are files that get changed very infrequently. For instance, if your system won’t have any users added anytime soon then it may be sensible to chattr immutably the /etc/password and /etc/shadow files. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.
   chattr +i /etc/passwd /etc/shadow
2. Password protect your linux install with LILO. Edit your /etc/lilo.conf. At the end of each linux image that you want to secure, put the lines:
   read-only
restricted
password = MySecurePassword
   Ensure you rereun /sbin/lilo so the changes take effect.
3. Users who have sudoer (sudo) accounts setup can have the account setup to change to root without a password. To check this, as root use the following command:
   grep NOPASSWD /etc/sudoers
   If there is an entry in the sudoers file, it will look like this:
   eric ALL=NOPASSWD:ALL
   To get rid of this, type visudo and remove the line in that file.
4. Use sudo to execute commands as root as a replacement for su. In the /etc/sudoers file, add the following lines by using the visudo command:
   Cmnd_Alias LPCMDS = /usr/sbin/lpc, /usr/bin/lprm
eric ALL=LPCMDS
   Now the user ‘eric’ can sudo and use the lpc and lprm commands without having any other root level access.
5. Turn off PasswordAuthentication and PermitEmptyPasswords in the SSH configuaration file /etc/ssh/sshd_config. This will ensure that users cannot set empty passwords or login without SSH keys.
   PermitEmptyPasswords no
PasswordAuthentication no
6. Instead of using “xhost +” to open up access to the X server, be more specific. Use the server name that you are allowing control to:
   xhost +storm:0.0
   Once you are done using it, remember to disallow access to the X server from that host:
   xhost -storm:0.0
7. To find out the .Xauthority magic cookie looks like and to send it (authorization information) to the remote host, use the following command:
   xauth extract - $DISPLAY | ssh storm xauth merge -
   Now the user who ran this command on the original host can now run xcilents on storm. xauth needs to be present on both hosts.
8. To turn on spoof protection, run a simple bash script:
   for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i done;
   Be careful to remember that it drops packets more or less ‘invisibly’.
9. A SYN-flood attack has the ability to bring the network aspect of your linux box to a snail like crawl. TCP_SYNCookies protection attempts to stop this from taking a heavy toll on the machine. To enable cp_syncookies
   protection, use the following command:
   echo 1 > /proc/sys/net/ipv4/tcp_syncookies
10. When possible use secure connection methods as opposed to insecure methods. Unless you are required to use telnet, substitute ssh (Secure SHell) in for rsh or telnet. Instead of POP3 or IMAP use SPOP3 or SIMAP (IMAPS). Both SIMAP and SPOP3 are just versions of IMAP and POP3 running over an SSL (Secure Socket Layer) tunnel.

January 29th, 2007 by eric

A while back I had been asked to write a few quick tips that as an administrator, one would find helpful. They published in one form or another and are now available here. There are MANY more, but these are just a few. Enjoy.

1. Users who may be acting up or aren’t listening can still be controlled. Using a program called ’skill’ (signal kill) which is part of the ‘procps’ package.
   Halt/Stop User eric: skill -STOP -u eric
Continue User eric: skill -CONT -u eric
Kill and Logout User eric: skill -KILL -u eric
Kill and Logout All Users: skill -KILL -v /dev/pts/*
2. Make use of security tools out there to test your server’s weaknesses. Nmap is an excellent port scanning tool to test to see what ports you have open. On a remote machine, type the command:
   # nmap -sTU

   Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2006-08-10 13:51 EST
   Interesting ports on eric (172.16.0.1):
   (The 3131 ports scanned but not shown below are in state: closed)
   PORT STATE SERVICE
   22/tcp open ssh
   113/tcp open auth

   Nmap run completed — 1 IP address (1 host up) scanned in 221.669 seconds

3. On a production server that is in a common area (although this should not be the case, some situations are inevidable). To avoid an accidental CTRL-ALT-DEL reboot of the machine, do the following to remove the necessary
   lines from the /etc/inittab file:
   # sed -i 's/ca::ctrlaltdel:/#ca::ctrlaltdel:/g' /etc/inittab
4. Two SSH configuration options that can be set to improve security should be checked on your production server. UsePrivilegeSeparation is an option, when enabled will allow the OpenSSH server to run a small (necessary) amount of code as root and the of the code in a chroot jail environment. StrictModes checks to ensure that your ssh files and directories have the proper permissions and ownerships before allowing an SSH session to open up. The
   directives should be set in the /etc/ssh/sshd_config as follows:
   UsePrivilegeSeparation yes
StrcitModes yes
5. The default umask (usermask) on most systems should be 022 to ensure that files are created with the permissions 0644 (-rw-r–r–). To change the default umask setting for a system, edit /etc/profile to ensure that you umask is appropriate for your setup.
6. Some users like to have a passwordless account. To check this you need to look at the /etc/shadow account with the following command line:
   awk -F: '$2 == "" { print $1, "has no password!" }' /etc/shadow
7. Just in case someone else who has access to the superuser account decided to alter the password file and potentially make themselves a superuser. This is a method to check:
   awk -F: '$3 == 0 { print $1, "is a superuser!" }' /etc/passwd
8. Setuid and Setgid files have the potential to be very hazardous if they are accessilbe by the wrong users on the system. Therefore it is handy to be able to check with files fall into this category.
   find /dir -xdev -type f -perm +ug=s -print
9. World writable files can be left around by users wanting to make things easier for themselves. It is necessary to be careful about who can write to which files. To find all world writable files:
   find /dir -xdev -perm +o=w ! \( -type d -perm +o=t \) ! -type l -print
10. Some attackers, prior to attacking a host, (or users nmaping a host) will check to see if the host is alive. They do this by ‘ping’ing the host. In order to check if the host is up, they will use an ICMP echo request packet.
    To disallow these types of packets, use iptables:
    iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

January 25th, 2007 by eric

When you talk to many security experts, they pretty much agree that when a vulnerability hits, that it’s necessary that it be patched and that its only a matter of time until the sh*t hits the fan and some real knowledgable black hat has put something together for the script kiddies to play with. But a lot of people seem to forget every time a patch is required on a production system that there is due process that system administrators must go through. One of the primary steps is simply evaluation.

The primary questions that needs to be evaluated are:

What is the likelihood of the vulnerability being exploited or the damage that could be caused if it is exploited?

vs.

How long will it take to apply the patch, test it, implement it, then deploy it to the production environment? What kind of impact will that have on the production servers in terms of outages/downtime? Will it break anything else?

Let’s take some time to break these down. I have always found that the easiest way for most people to understand a problem is to use an example. I don’t want to single out phpBB, but since it recently came up and spurred a necessary conversation, I will use it for my example. The advisory that I am referencing is available here from Bugtraq.

At one of the many websites I run, I administer a phpBB forum. The forum is relatively low volume, but high volume enough to attract spammers which means its likely that it also attracts hackers (of the black hat variety). The phpBB version is 2.0.21. For a few reasons, we have not only modified some of the source code of phpBB, but we have also added plugins. For anyone who has any experience adding plugins into phpBB, you know that its akin to chewing glass (to say the least). Even though we version track in CVS, it would still be somewhat of a PITA to update to 2.0.22. The process would be something along the lines of:

Import the new version into the old version with the changes into CVS. See if it makes sense to resolve the conflicts. If so, resolve the conflicts and begin testing. If not, figure out how to duplicate the changes in the previous version (2.0.21) in the new version (2.0.22). Once that’s been done, then add the plugins that were installed in the old version into the new version. Come up with a transition plan for the production server. Back up the data and do a few test runs of the transition on the development box. Then schedule the outage time and do the turnover to the new server. Then pray everything goes ok for the transition. Simple, No?

The point of going through that lengthy explanation was to demonstrate that the upgrade process may not be as simple (in a lot of cases) as:
apt-get update && apt-get upgrade

The exploit itself requires a user to create a shockwave flash file with certain parameters, then put it into a specific web page with certain parameters, and then it must be private messaged (emailed) to someone who is already signed into the board (has an active cookie).

Many security experts would tell you that, “It’s a vulnerability, it needs to be patched immediately.” Well, let’s do that evaluation thing I was referring to earlier. How likely is it that someone is going to take the time to create that flash file. And even if someone does go to that trouble, what’s to say that if a user (or the admin) receives the message in an email, that they are going to visit the site and watch the video?

My colleague was asserting that it’s out there on the internet and needs to be protected. And to that extent, I certainly agree. However, the amount of time that it would take to make all those changes, test them, and deploy the changes to the production server far outweighs the possibility of the application being exploited.

When I first started out in security, I took the approach, “It’s a vulnerability…Security at all costs.” Now I have learned that sometimes one needs to balance out time vs. need vs. priority. So I encourage System Administrators to think before jumping into situations like that. Think of how much more work could be accomplished in the time that would have been spent trying to patch something that probably wouldn’t have been exploited to begin with.