Article

Home » Server-side Coding » Server Side Essentials » Secure Your Linux Server

About the Author

Aaron Brazell

author_aaron Aaron Brazell is the senior technology manager for b5media, a new media network. He is a well known and respected voice in the world of blogging and social media and has a passion for written communication. He has been developing in PHP for six years and has been actively involved with WordPress for nearly three years. He writes on his blog, Technosailor and is available for WordPress consulting.

View all articles by Aaron Brazell...

Secure Your Linux Server

By Aaron Brazell

June 17th, 2003

Reader Rating: 7.5

Page: 1 2 Next

The Linux Operating System is one of the most stable and diverse OS's around. It's also one of the most popular servers in the world, thanks to its stability, process handling and developer dedication. No matter what you're planning to do with Linux, you can bet there's a flavor that will match your particular needs.

In the development world, the most popular and often used Linux distribution (known to Linux geeks as a "distro") is RedHat. Other open source varieties include Mandrake, Debian, or SuSE. We'll be referring to the RedHat 9 distro throughout this tutorial.

Do Not Turn Your Brain Off At The Door!

Warning! If you think that reading this article will give you all the information you need to be a systems administrator, think again. This article will cover the basics of security, but it is not intended to be a substitute for common sense, nor the necessary interactive thinking of a competent systems administrator.

This is not a fix-all! Hackers and attackers constantly reinvent themselves and a good systems administrator will be versatile and adept, reinventing himself as necessary. I recommend these sources to help you stay on top of systems administration and security issues pertaining to your Linux server:

  • Linuxdocs.org - http://www.linuxdocs.org/

  • CERT - http://www.cert.org/

    Installation

    Before you can really get going, you have to install your Linux distro. Because we're setting up a server, we are going to run without X-Windows (the graphical user interface that ships with Redhat). You may choose to install X if you wish, but we won't use it in this tutorial.

    The rule of thumb we're operating under here, is that, if something is not needed, we're not going to enable it. The reason for this approach is that the more services and modules that you have installed, the greater is the risk that an exploited and overlooked service could provide a gateway to your box.

    Depending on your server or distro, the file locations I provide here may not correspond with those on your own system. You can use the following command to locate a file: find / -name filename. You can also use tools such as pico or vi to edit a file, by executing the following command:

    # pico file

    or

    # vi file

    Lockdown

    This is the first thing you want to do to secure your new Linux box. There are a number of actions that can be taken to prevent dangerous activity.

    Changing the root Password

    The most obvious and simplest lockdown method is to change (or even initially setup) your root password, right from the start.

    It's a good idea to change this once every 30 days, and it's also wise to come up with a password that will not be easily cracked. There are apps out there that can run a password list against a dictionary and try to crack passwords that way. There are also apps that will run a password list against a dictionary, and against "hacker" spellings. Therefore, using the term "d0gf00d" as your password is highly insecure.

    You can change your password using the passwd command while logged in as root.

    Disable suid

    It is very valuable at times, and also very dangerous, to be able to run an application as a different user. The most common application of this is with suid. With suid, an underprivileged user can run an application as if they were a privileged user. For instance, Apache Web server, which, by design, runs as its own user, could execute commands as root. In this way, it would be possible for a regular user to gain access to, and edit the /etc/passwd file, among others.

    You can find out which files are using suid by executing the following command. Anything with an 's' in the permission column (on the left) is enabled to run with suid.

    # ls -alF `find / -perm -4000` > /root/suid.txt

    On your server, you may get something like this in /root/suid.txt:

    -rwsr-xr-x    1 root     root        60104 Apr  1  2002 /bin/mount*
    -rwsr-xr-x    1 root     root        35192 Apr 18  2002 /bin/ping*
    -rwsr-xr-x    1 root     root        19116 Apr  8  2002 /bin/su*
    -rwsr-xr-x    1 root     root        30664 Apr  1  2002 /bin/umount*
    -r-sr-xr-x    1 root     root       120264 Apr  9  2002 /sbin/pwdb_chkpwd*
    -r-sr-xr-x    1 root     root        16992 Apr  9  2002 /sbin/unix_chkpwd*
    -rwsr-xr-x    1 root     root        37528 Jan 17  2002 /usr/bin/at*
    -rwsr-xr-x    1 root     root        34296 Mar 27  2002 /usr/bin/chage*
    -rws--x--x    1 root     root        12072 Apr  1  2002 /usr/bin/chfn*
    -rws--x--x    1 root     root        11496 Apr  1  2002 /usr/bin/chsh*
    -rwsr-xr-x    1 root     root        21080 Apr 15  2002 /usr/bin/crontab*
    -rwsr-xr-x    1 root     root        36100 Mar 27  2002 /usr/bin/gpasswd*
    -rwsr-xr-x    1 root     root        19927 Apr 17  2002 /usr/bin/lppasswd*
    -rws--x--x    1 root     root         4764 Apr  1  2002 /usr/bin/newgrp*
    -r-s--x--x    1 root     root        15104 Mar 13  2002 /usr/bin/passwd*
    -rwsr-xr-x    1 root     root        14588 Jul 24  2001 /usr/bin/rcp*
    -rwsr-xr-x    1 root     root        10940 Jul 24  2001 /usr/bin/rlogin*
    -rwsr-xr-x    1 root     root         7932 Jul 24  2001 /usr/bin/rsh*
    -rwsr-xr-x    1 root     root       219932 Apr  4  2002 /usr/bin/ssh*
    ---s--x--x    1 root     root        84680 Apr 18  2002 /usr/bin/sudo*
    -rwsr-xr-x    1 root     root        32673 Apr 18  2002 /usr/sbin/ping6*
    -r-sr-xr-x    1 root     root       451280 Apr  8  2002 /usr/sbin/sendmail.sendmail*
    -rwsr-xr-x    1 root     root        20140 Mar 14  2002 /usr/sbin/traceroute*
    -rwsr-xr-x    1 root     root        13994 Apr 18  2002 /usr/sbin/traceroute6*
    -rws--x--x    1 root     root        22388 Apr 15  2002 /usr/sbin/userhelper*
    -rwsr-xr-x    1 root     root        17461 Apr 19  2002 /usr/sbin/usernetctl*

    Many systems administrators will recommend the deactivation of services like ping and traceroute, which are not required. In this particular output, I'm going to disable /usr/bin/chage, /usr/bin/chfn, /usr/bins/chsh, /bin/mount,
    /bin/umount, /usr/bin/gpasswd, /usr/sbin/usernetctl, /usr/sbin/traceroute, /usr/sbin/traceroute6,
    /usr/bin/newgrp and /usr/sbin/ping6, /bin/ping.

    To disable suid on a file, use the following command. This makes the file executable only by the owner, and also makes it immutable (unable to be modified or deleted, or even linked to):

    # chmod 111 /path/to/file
    # chattr +I /path/to/file

    Remember, the rule of thumb is if something isn't needed, disable it!

    /etc/securetty -- Next, you'll want to edit your /etc/securetty file. This script allows you to define what services have access to your TTY device. A TTY device is a fancy designation for any basic input/output device, and in this case, the device is your Linux console.

    The file contains a list of services by which root can access your console. The most important items here will be to disable (i.e. comment out, using a # in front of the line) telnet. The reason for this is that telnet broadcasts unencrypted packets. In layman's terms, it shouts your vital user password through a bullhorn for the world to hear. Obviously, you don't need your root password broadcast this way. Our box has the following /etc/securetty file before we get to it.

    # pico /etc/securetty
    vc/1
    #vc/2
    #vc/3
    #vc/4
    #vc/5
    #vc/6
    #vc/7
    #vc/8
    #vc/9
    #vc/10
    #vc/11
    tty1
    #tty2
    #tty3
    #tty4
    #tty5
    #tty6
    #tty7
    #tty8
    #tty9
    #tty10
    #tty11

    We are going to comment out (place a # in front of the appropriate line) all devices except vc/1 and tty1, effectively preventing root access except from these single consoles. The only way to access root then, is to use su -.

    If you liked this article, share the love:
    Print-Friendly Version Suggest an Article
  • Sponsored Links