HOW-TO: Secure and optimize your Linux server

[Joshua Delsman]

HOW-TO: Secure/optimize your new Linux server
=============================================

Table of Contents
-----------------

A. Welcome
B. Secure SSH
   I.   Disable direct root login / Protocol 2
   II.  Allowed Users
C. Updating components
   I.   YUM software updates
   II.  Kernel updates
   III. Control Panel Updates/Tweaks
D. Preventative Measures
   I.   APF
   II.  Rootkit Hunter / chkrootkit
   III. BFD
   IV.  SIM
   V.   Root Access Warnings
D. Apache Optimization
   I.   Obfuscate Version Number
E. PHP Optimization
F. MySQL Optimization
   I.   Change MySQL Root Password
   II.  skip-networking
G. BIND/DNS Optimization
   I.   Obfuscate Version Number
   
============================================

A. WELCOME!

  So, you have a shiny new Linux dedicated server from Lunarpages. Congratulations! You're about to embark on a magical hosting journey where your websites will dance in the fields next to the Information Superhighway!

All magical tangents aside, there are some very serious security and optimization measures you should take into consideration to make sure that your experience is the best -- and so your server doesn't get taken advantage of! I have compiled the best of the best from around the Internet, and many from my professional experiences as a Lunarpages systems administrator. If you have any questions at any time during this extensive tutorial, please do not hesitate to contact any of our various support avenues for assistance:

   Dedicated Helpdesk:      http://desk.lunarpages.com/  -or-  dedicated@lunarpages.com

It's also important to note that some of these fixes, optimizations and tweaks will differ if you use cPanel or Plesk. If you're unsure, please ask a dedicated technician to assist you.
   
B. SECURING SSH

I. Disabling direct root login / Protocol 2

This is probably one of the most important parts of this tutorial. Sometimes, attackers will use servers from around the world to use what are called "brute-force attacks" to try and guess your server's root password. You can easily circumvent this type of attack by disabling direct root access to the server.

First, as root, you're going to want to create a new user on the server (you may already have one -- check your welcome e-mail) you'll use to access the server first:

Code:

# useradd lunarpages
# passwd lunarpages

   
You'll be prompted to change your password -- do so! Then, you're going to add this user to the "sudoers" file, which will give you access to use the sudo command on the server:

Code:

# visudo

   
Underneath the entry for root, please add your username. It should look something like the following:

Code:

root    ALL=(ALL) ALL
lunarpages    ALL=(ALL) ALL
yourUserName ALL=(ALL) ALL

Save the file (CTRL + O), quit (CTRL + X) and then open up the sshd_config file, which stores configuration for the SSH server on your machine:

Code:

# nano /etc/ssh/sshd_config

   
You'll want to make sure you have following values:

Code:

Protocol 2
PermitRootLogin no

   
These are the minimums, and I implore you to research the other options before trying them out -- as you may lose access to your server if you change anything else. You can even go as far as changing the SSH port. If you would like to change the SSH port, please open a ticket, or log into dedicated chat For assistance.
Save the file and quit (CTRL + X).

Now you can reload the sshd_config file so sshd knows there are changes:

Code:

# /sbin/service sshd reload

   
DO NOT, I repeat, DO NOT CLOSE THE SSH WINDOW YET. Try out the settings by opening a new shell window and connecting to the server using the following command formula:

Code:

# ssh username@server.domain.com

   
Enter your password, and once you're logged in, you can either use sudo to gain root access:

Code:

$ sudo su -

   
If this works, you're good! If not, contact Lunarpages' Dedicated Support for assistance.

II. Allowed Users

If you are going to be the only person accessing the server via shell, or if you already have a set amount of users which you have already created who will be accessing the server, you can specify these in the SSH server configuration:

Code:

# nano /etc/ssh/sshd_config

   
At the end of the file, you can add the following line:

Code:

AllowUsers lunarpages

   
Of course, replace "lunarpages" with your specified username(s) separated by spaces. This will *ONLY* allow the username "lunarpages" to access the server -- whether they want to gain root or otherwise.

With both of the above tips, it's a good idea to create a "lunarpages" user/password and add this user to the list of allowed users and sudoers, then let us know if you'll be limiting SSH, especially if you have Managed Hosting. That way we'll be able to access your server for support purposes and in emergencies.

C. UPDATING COMPONENTS

I. YUM Software Updates

If you opted to have CentOS installed on your dedicated server (which is default for our servers), your server comes with a software application called "yum" which helps to keep your system software up to date. Moreover, you can install and remove most software this way as well.

You can update your system software with the latest security updates easily! Just type:

Code:

# yum update

   
You can even set your system to update software nightly, which takes a lot of thought out of the update process for you, the server administrator. However, please keep in mind that this can sometimes break things! If you are unsure of whether you should set it to update nightly, be sure to ask support (dedicated@lunarpages.com) for more assistance.

To setup the nightly cron update, type:

Code:

# chkconfig --level 2345 yum on
# /sbin/service yum start

   
II. Kernel Updates

The Linux kernel is always being updated due to malicious attacks and exploits being released at a constant rate. Sometimes its hard to keep up!

PLEASE NOTE: The kernel upgrade process can be a very intricate process. If you do not believe you're up to it, I highly recommend that you do not. Instead, contact Lunarpages Dedicated Support 24/7 and we can assist you.

To see what kernel version you are currently using, you can type the following:

Code:

# uname -r

   
Similarly, if you need to see which version of CentOS your server is using, you can type:

Code:

# cat /etc/redhat-release

   
In recent history, our administrators have used the following commands to update the Linux kernel on our servers:

Code:

# cp /etc/grub.conf /etc/grub.conf.bk
# yum -y update kernel

   
This will backup the old grub.conf just in case something goes wrong, so we can boot in to the old kernel during the support process. It then updates the Linux kernel to the newest version without any user intervention.

You need to reboot the server to see the changes take effect. If you see a "Transaction succeeded" or "Finished" message, you're good to go:

Code:

# reboot

   
You can open another shell window on your computer, and type:

Code:

$ ping server.domain.com

This will tell you when the server comes back from the reboot. If it doesn't come back, let us know, and we'll be glad to assist you.

III. Control Panel Updates / Tweaks

If you use cPanel/WHM on your Linux server, you can easily update it by typing the following:

Code:

# /scripts/upcp

   
This will update cPanel/WHM, and all server software (except Apache/PHP) to the latest versions. You'll need to do this in addition to the YUM process above if you have cPanel, since it excludes its packages from yum updates traditionally.

When this process completes, you should also make sure that cPanel is set to update to the latest RELEASE version in cPanel in the "Update Config" section, like below:

   
   
D. PREVENTATIVE MEASURES

I. APF (Advanced Policy Firewall)

APF is a part of the Managed Hosting add-on for dedicated servers, which is $9.99 per month. It is an important part of filtering unneeded ports on your server to give it a more secure footprint.

First, download the APF source to an appropriate setup directory, and extract the archive:

Code:

# mkdir /root/setup
# cd /root/setup
# wget http://www.rfxnetworks.com/downloads/apf-current.tar.gz
# tar -zxf apf-current.tar.gz

   
Then, you'll need to cd to the directory it extracted to, and run the installer:

Code:

# ./install.sh

   
Now, we need to make a few modifications to the APF configuration file:

Code:

# nano /etc/apf/conf.apf

   
Scroll to where you see the following, and make the modifications as you see here:

Code:

# Common ingress (inbound) TCP ports
IG_TCP_CPORTS="20,21,22,25,26,53,80,110,143,443,465,993,995,2082,2083,2086,2087,2095,2096,3306,6666"

# Common ingress (inbound) UDP ports
IG_UDP_CPORTS="21,53,465,873"

# Common ICMP (inbound) types
# 'internals/icmp.types' for type definition; 'all' is wildcard for any
IG_ICMP_TYPES="3,5,11,0,30,8"

   
You may need to add port 8443 to IG_TCP_CPORTS if you use Plesk, replacing the 20xx ports only used by cPanel. If you ordered a bare server with no control panel, you can exclude these ports completely.

Change the line to "1":

Code:

EGF="0"

   
Scroll to where you see the following, and make the modifications as you see here:

Code:

# Common egress (outbound) TCP ports
EG_TCP_CPORTS="21,22,25,26,37,43,53,80,110,113,443,465,873,2089,3306"

# Common egress (outbound) UDP ports
EG_UDP_CPORTS="20,21,53,465,873"

# Common ICMP (outbound) types
# 'internals/icmp.types' for type definition; 'all' is wildcard for any
EG_ICMP_TYPES="all"

Save and exit (CTRL + X) and start APF in developer mode:

Code:

# /usr/local/sbin/apf -s

   
Verify that everything works -- you can still get into SSH, cPanel works, you can view a page, etc. If it all works, open the configuration file again and change the following line to "0" and save/exit (CTRL + X):

Code:

DEVEL_MODE="1"

   
You can then make sure that APF is started and running:

Code:

# /usr/local/sbin/apf -r

   
II. Rootkit Hunter / chkrootkit

These are two software applications developed to alert you if there are any possible rootkits or rootkit-like vulnerabilities on your machine. Let's download and extract both of them!

NOTE: Search Google for the latest versions of these applications, as they may have updated since the time of this post.

Code:

# mkdir /root/setup
# cd /root/setup
# wget http://internap.dl.sourceforge.net/sourceforge/rkhunter/rkhunter-1.2.9.tar.gz
# wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz
# tar -zxf rkhunter-1.2.9.tar.gz
# tar -zxf chkrootkit.tar.gz

   
First, you can install, update and run Rootkit Hunter:

Code:

# cd rkhunter-1.2.9/
# sh install.sh
# rkhunter --update; rkhunter -c

   
If this is a brand new server, you shouldn't get anything but maybe a few false positives, like MD5 hahses, etc. If you see anything that you're unsure of, however, please open a new ticket with us by e-mailing the results to dedicated@lunarpages.com

Next, let's make and run chkrootkit. This won't actually install a system-wide binary, so you'll have to keep the folder and its contents there for future use:

Code:

# cd chkrootkit/
# make
# ./chkrootkit

   
III. BFD (Brute Force Detection)

Like I mentioned in this earlier tutorial, your server may get constantly hit by dictionary attacks due to the popularity of our network. However, BFD can be installed, which will stop the attacks in their tracks, and before any damage can be done to your system:

Code:

# wget http://www.rfxnetworks.com/downloads/bfd-current.tar.gz
# tar -zxf bfd-current.tar.gz

   
CD into the directory which was created, and then run the installer:
   

Code:

# ./install.sh

   
After the install is completed, there are a few settings you should change in the BFD configuration file:

Code:

# nano /usr/local/bfd/conf.bfd

You should enable BFD alerts, and specify your e-mail address so you know if and when your server is being hit, so you can take additional action if necessary:
   

Code:

# Enable/disable user alerts [0 = off; 1 = on]
ALERT_USR="1"

# User alert email address
EMAIL_USR="yourname@domain.com"

   
Save and exit (CTRL + X) and open the ignore.hosts file:

Code:

# nano /usr/local/bfd/ignore.hosts

   
This file is parsed first whenever an IP is about to be blocked for excessive SSH authentication failures. You should add your IP address here, as well as Lunarpages IP addresses, so we can access your server if need be. Here is the minimum you should have in this file:

Code:

127.0.0.1
209.200.241.2
216.227.209.246
your.ip.address.here

   
After you're done, go ahead and start BFD:

Code:

# /usr/local/bfd/bfd -s

   
IV. SIM (System Integrity Monitor)

This is a great application, and extremely useful if you have mission-critical web sites running on your server. This piece of software runs on your server, continuously monitoring any service that you specify. It provides monitoring of HTTP, FTP, DNS, SSH, MYSQL & more. It will e-mail you whenever a service goes down, attempt to automatically restart it, monitor server load, and send you logs of the entire process.

Please note that cPanel and Plesk have integrated system monitoring tools. You should probably think about using these instead, although adding SIM will not interrupt these tools.

Let's download it and install:

Code:

# mkdir /root/setup
# cd /root/setup
# wget http://www.r-fx.ca/downloads/sim-current.tar.gz
# tar -zxf sim-current.tar.gz
# cd sim-*
# ./setup -i

   
Once the application has installed successfully, you should see something like "SIM installation completed." Keep pressing enter during the "auto-configuration," as we'll be changing most of the important settings manually.

Let's edit the configuration file:

Code:

# nano /usr/local/sim/conf.sim

   
Enter an e-mail address you'd like all alerts to be sent to:

Code:

EMAIL="yourname@domain.com" # address/user to send alerts to

Let SIM know which services you would like to have monitored. What I have below should be sufficient for most users:

Code:

SERV_FTP="true" # FTP Service
SERV_HTTP="true" # HTTP Service
SERV_DNS="true" # DNS Service
SERV_SSH="true" # SSH Service
SERV_MYSQL="true" # MySQL Service
SERV_XINET="false" # XINET Sevice
SERV_SMTP="false" # SMTP Service

   
Now, here is where the tricky part comes in. The following settings should be OK for most cPanel users, but may differ between control panels (e.g., bare servers use vsftpd):

Code:

FTP_NAME="pureftpd" # name of FTP service as appears in 'ps'
HTTP_NAME="httpd" # name of HTTP service as appears in 'ps'
DNS_NAME="named" # name of DNS service as appears in 'ps'
SSH_NAME="sshd" # name of SSH service as appears in 'ps'
MYSQL_NAME="mysqld" # name of MySQL service as appears in 'ps'
XINET_NAME="xinetd" # name of XINET service as appears in 'ps'
SMTP_NAME="exim" # name of SMTP service as appears in 'ps'

If you get alerts stating that your services are down, but they really aren't, you can always run:

Code:

# ps -aux

   
Scroll through that output to see which service name resembles the one you're trying to track. If all else fails, e-mail dedicated@lunarpages.com to ask what the proper service name is. Now, we must start the script:

Code:

# /usr/local/sim/sim -j

   
You can test to make sure things are working correctly by doing the following:

Code:

# /sbin/service httpd stop
# /usr/local/sim/sim -s

   
You should see something similar to:

Code:

- Service Summary:
HTTP [restarted - 1 events]
MYSQL [online - 0 events]
...

   
V. Root Access Notices

These notices will let you know if someone other than you gains access to root on your server in any way. Just a warning -- these notices can get annoying if you find yourself using root often. But, if you don't, its a great way to make sure you're the only one accessing your server.

Once you're logged in as root, type:

Code:

# nano /root/.bash_profile

   
At the end of the file, add the following line, replacing "yourname@domain.com" with your primary e-mail address:

Code:

echo 'Root Access on:' `date` `who` | mail -s "ALERT! Root Access from `who | awk '{print $6}'`" yourname@domain.com

   
Save and exit. (CTRL + X)

D. APACHE OPTIMIZATION/SECURITY

I. Obfuscate Apache's version

In order to confuse the heck out of possible attackers, you may want to remove the version number from being disclosed by Apache.

Code:

# nano /etc/httpd/conf/httpd.conf

   
Find the following lines, and change them to what I have below:

Code:

ServerSignature Off
ServerTokens ProductOnly

   
Save and close the file (CTRL + X). Then, to restart Apache for the changes to take effect:

Code:

# /sbin/service httpd restart

[Joshua Delsman]

E. PHP OPTIMIZATION

For PHP, I would recommend installing Zend Optimizer (http://www.zend.com/products/zend_optimizer) and eAccelerator. eAccelerator (http://eaccelerator.net/) is a PHP accelerator/encoder/caching utility that is based off of the old mmcache (which is no longer being maintained).

What eAccelerator does is it caches your PHP scripts so that the database is no longer being queried every time someone requests a script. This is particularly useful for large forums, but pretty much anyone can benefit from it. Since these scripts are cached, you'll notice a decrease in memory use and server load, as well!

NOTE: There may be a new version of this software since time of writing. Check out http://eaccelerator.net for the latest release.

So, as root:

Code:

# mkdir /ea/
# cd /ea/
# wget http://bart.eaccelerator.net/source/0.9.5/eaccelerator-0.9.5.tar.bz2
# bzip2 -d eaccelerator-0.9.5.tar.bz2
# tar -xf eaccelerator-0.9.5.tar
# cd eaccelerator-0.9.5/
# export PHP_PREFIX=`which php`
# $PHP_PREFIX/bin/phpize
# ./configure --enable-eaccelerator=shared --with-php-config=$PHP_PREFIX/bin/php-config
# make; make install

   
Now, it is basically installed. What we have to do now is edit the php.ini files to include eAccelerator. These are usually found in the /etc/ or /usr/local/lib/ folders, but if you can't find them, try this:

Code:

# updatedb
# locate php.ini

Let's edit /etc/php.ini:

Code:

# nano /etc/php.ini

   
Search (CTRL + W) for "Dynamic Extensions" without the quotes. In this section, paste:

Code:

extension="eaccelerator.so"
eaccelerator.shm_size="16"
eaccelerator.cache_dir="/tmp/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

   
Now we need to make the cache directory where all the cache files will be stored.

Code:

# cd ~
# mkdir /tmp/eaccelerator/
# chmod 777 /tmp/eaccelerator/

   
It's configured completely now. Let's restart Apache and test:

Code:

# /sbin/service httpd restart
# php -v

   
If you see an eAccelerator copyright notice, then eAccelerator should be installed. If you have any doubts, please e-mail dedicated@lunarpages.com and we can take a look for you.

F. MySQL OPTIMIZATION/SECURITY

I. Change MySQL root password

By default, MySQL does not secure its root password. Basically, this means that anyone can connect to your MySQL server and trash your tables and database settings for any database. Let's stop them!

NOTE: If you use cPanel or Plesk, try updating the MySQL root password using the control panel first. Otherwise, database management functionality may not work correctly.

If this is a brand new server, and you've never used MySQL before, you can change the root password in shell as any user:

Code:

$ mysqladmin -u root password NEWPASSWORD

   
However, if you want to change an existing root password, do the following:

Code:

$ mysqladmin -u root -p oldpassword newpassword

   
II. /etc/my.cnf Optimization

These settings are tried and true for even above-average MySQL server usage. I encourage you to tweak them for your server and settings as you see fit to optimize MySQL even further. If your MySQL server still suffers from high load issues after modifying these settings, e-mail us at dedicated@lunarpages and we'll be glad to help.

As root, edit (or create, if it doesn't exist) the /etc/my.cnf file:

Code:

# nano /etc/my.cnf

   
Add the following values to the file:

Code:

[mysqld]
#datadir=/var/lib/mysql
#socket=/var/lib/mysql/mysql.sock
skip-locking
query_cache_limit=1M
query_cache_size=32M
query_cache_type=1
max_connections=500
interactive_timeout=100
wait_timeout=100
connect_timeout=10
thread_cache_size=128
key_buffer=16M
join_buffer=1M
max_allowed_packet=16M
table_cache=1024
record_buffer=1M
sort_buffer_size=2M
read_buffer_size=2M
max_connect_errors=10
# Try number of CPU's*2 for thread_concurrency
thread_concurrency=2
myisam_sort_buffer_size=64M

[mysql.server]
user=mysql
basedir=/var/lib

[safe_mysqld]
err-log=/var/log/mysqld.log
#pid-file=/var/lib/mysql/mysql.pid
open_files_limit=8192

[mysqldump]
quick
max_allowed_packet=16M

[mysql]
no-auto-rehash
#safe-updates

[isamchk]
key_buffer=64M
sort_buffer=64M
read_buffer=16M
write_buffer=16M

[myisamchk]
key_buffer=64M
sort_buffer=64M
read_buffer=16M
write_buffer=16M

[mysqlhotcopy]
interactive-timeout

   
For even more security, you can add "skip-networking" to the [mysqld] section. That disallows all access through TCP/IP and only allows communication through the socket file. So, basically, you'll only be able to connect to your databases using a "localhost" hostname in your scripts, not by server IP or hostname.

Note, as well, that "thread_concurrency=2" may need to be set higher for Dedicated II or Dedicated III server plans. The general rule of thumb is to multiply the number of processors on the server by 2. You can see the number of processors on the server by typing the following:

Code:

# cat /proc/cpuinfo

G. BIND OPTIMIZATION/SECURITY

I would highly recommend not changing any settings here without first researching everything first. Any changes to BIND will affect your DNS, which is *everything* -- web, mail, ftp, etc. Be sure to connect to SSH via IP before changing any settings here, as well.

First, we don't want BIND to report the version we're using. This can stop passive scanners from identifying the version of BIND you're using.

This trick doesn't really secure BIND as much as it obfuscates things a bit. Open /etc/named.conf:

Code:

# nano /etc/named.conf

   
Edit as shown below:

Code:

options {
    version "Not available";
}

   
You should also disable recursive queries (a big no-no on DNSStuff.com reports lately), which prevents your DNS server from being vulnerable to spoofing attacks. We'll allow them on the local network, as that's the only plae they should be occurring.

Add the following to the named.conf file:

Code:

options {
    fetch-glue no;
    allow-recursion { localnets; };
}

   
Save the file and exit (CTRL + X). Now, we're going to restart BIND for the changes to take effect:

Code:

# service named restart

   
Make sure to check the status to make sure all your zones show up, etc.:

Code:

# service named status

number of zones: 10
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running