Server Patching:

One of the key components to a stable and secure system is keeping it up to date. In Red Hat, the best way to do this is with a subscription to the Red Hat Network (RHN.)  When you have purchased a Red Hat subscription, the subscription is bound to a user account for RHN.  You can then simply go to the portal and centrally manage patching for all of your servers through a web GUI.  Go here for more information. (https://www.redhat.com/red_hat_network/ )

If you prefer to have the systems automatically update, such as with a cronjob, (convenient, but potentially dangerous) or you simply prefer to use command line, you can do simply with:

up2date -u

For Fedora and CentOS, it's a bit different since there is no subscription.   In some sense, better.

Via the GUI:

For starters, you'll be prompted in the GUI from the door to update your server.   If you need to go to the update later, though, you can go to the Package Updated (box icon) in the upper right hand corner of the GUI.  (Alternately, you can also go to "Applications" > "System Tools" > "Software Updates")  Click it and then "Apply Updates" to patch your system:

You can also perform updates from command line with the power software tool, yum:

Yum update

Or for a full upgrade (removing obsolete packages:

Yum upgrade

Either way, once you kick off updates, go get a coffee.  It's gonna be a while.

Anti-Virus -

            For many Linux administrators it seems unnecessary to run anti-virus on their servers.  The postulation being that Linux "doesn't get viruses".  Aside from being hubris, this is poor logic.  Generally speaking, Linux has not gotten any viruses.  That does not mean that it will not in the future.  It also does not mean that your windows clients cannot be infected by virus' that are stored on a Linux server.  This being  the case, the prudent course of action is to run at least periodic scans on the server with anti-virus software.  

To install anti-virus you're going to have to download lastest version of a popular anti-virus package.  I recommend ClamAV.   Go to their site and download the latest installer:  http://www.clamav.net/lang/en/

Follow their directions for alternate repositories, or if you download an RPM, you can install the package(s) by typing:

Rpm -Uvh (package).rpm

Once the installation is complete, you want to configure the Anti-Virus software. 

You can set-up a quick script to handle this for you.  First, create a directory for storing infected files (/home/infected, for instance) and then create a shell script in /root/scripts named  AV-Scan.  Paste in  the following lines:

# Update Virus Defs:

freshclam

# Scan the filesystem

clamscan -r --move=/home/infected / | grep -v ': OK' | grep -v 'Empty file'

Finally, after saving the file, schedule the scan to run nightly.  Type:

Crontab -e

And add the following line to your crontab:

@daily /root/scripts/AV-Scan.sh | mail root -s"AV Scan"

And as simple as that, the system is set for nightly virus definition updates and a full scan.

Anti-Root Kit:

For many Linux administrators, one of the clearest dangers is a compromise of the server.  One of the most common way is an injection attack involving a rootkit.  Aside from observing good general security practices, it is also a good idea to scan for rootkits frequently.

To install the root kit checker you're going to have to download lastest version of a rootkit checker package.  I recommend Chkrootkit.   Go to their site and download the latest installer: 

http://www.chkrootkit.org/download/

The installer will be a tar file.  Simply open it, go into the directory and run the binary:

[root@localhost ~]# tar -zxf chkrootkit.tar.gz

[root@localhost ~]# cd chkrootkit-0.49/

[root@localhost chkrootkit-0.49]# ./chkrootkit

Once the installation is complete, you can easily schedule a job to check for rootkits,  Type:

Crontab -e

And add the following line to your crontab:

@daily chkrootkit | mail root -s"RootKit Scan"

And as simple as that, the system is set for a nightly root kit scan.

Firewalls:

There has long been an unfortunate misconception about the need and nature of firewalls.  Long held perceptions that border (internet firewalls) are sufficient to keep the 'bad guys' out have been time and time again found to be incorrect and with disastrous results.  With all of the focus on keeping outside intruders at bay, the local security tends to be lax.  In fact, more often than not (and in every compromise I have seen in the last two decades), the attacker comes from within.  Be it a disgruntled employee, the off-spring of an employee or a compromised workstation, the border firewall serves no benefit in  detecting internal attacks.

All servers should run local firewalls.

New administrators may not be familiar with the TCP/IP ports that they require for their firewalls and in turn decide to turn the firewall rule off with the theory that "I'll get back to it."   Don't.   You won't - until you've been compromised.   You can find a good list of common tcp/ip ports by looking in /etc/ports or google the internet for either "IANA tcp/ip ports."   Need to know ports for your application and the documentation doesn't clear state them?  Don't be afraid to ask your vendor or at worst, google "{your application} tcp/ip ports."

All servers should run local firewalls.

Some application may not be familiar with the TCP/IP ports that they require for their applications and want the firewalls turned off so their applications work.  Don't.  If they need to know ports for their application and the documentation doesn't clear state them?  Remind them not to be afraid to ask their vendor or at worst, google "{their application} tcp/ip ports."    Realistically, if you don't know the tcp/ip ports the application is using then you probably don't know that much about your application…

Red Hat is uncommonly good about firewalls.  For the default server install, the firewall is active and whenever a service (remote access VNC, email, etc.) is configured it simply  needs to be added in.  To do this, go to "System" > "Administration" > "Security Level and Firewall":

Configuring the firewall is as easy as selecting one of the pre-listed services.  If your service isn't listed and you do not know your port, check out /etc/services for a copy of the current IANA registered port listing. 

Finally, you can use this interface to disable the firewall for the purposes of troubleshooting.   You just need to remember to leave it on when you're done.    But of course you'll leave the firewall on as you very well know that all servers should run local firewalls.

Egress Filtering

So, since we're clear that all servers should run local firewalls, there is another tenant that we should discuss:

All firewalls should have egress filtering.

In other words, outbound ports should be restricted just as inbound ports are.   Seem strange?  Welcome to the modern age of script kiddies.  Modern worms / botnets function similar to virus - they spread from system to system and once they're activated, they 'phone home', that is, connect out to a remote site, typically a public location such as an IRC server, or website.  In fact, AIM, twitter and facebook are becoming new choice destinations for remote controlling these networks of zombied devices.   Step one in avoiding these is to keep your local security tight so you don't get them to start with.  Step two is to make sure they can't phone home to activate and provide remote control of your servers.

So, how to avoid this?

-Network firewalls should have egress filtering.   If your users must have IRC, AIM, twitter, etc., Fine.  Then put your servers in their own VLANS and restrict outbound on all unneeded ports for just that VLAN.

-Local firewalls should have egress filtering.  What does my server need to talk to?  Definitely DNS.  Maybe http.  Maybe the domain.  Definitely not IRC, AIM or twitter.  (A server is not a workstation, remember?)

-Internet access should be filtered via proxy servers.  Aside from giving the users quicker internet responsiveness, giving you a clear history of what is going where, the proxy server can be employed for protocol validation to reduce the exploiting of common protocols (HTTP) to do un-standard functions

Intrusion Detection Systems:

There are many varied and complicated steps that can be taken in securing a server.  One of the most rudimentary is installing an Intrusion Detection System.   Although IDS' do little prevent intrusion, it does proactively alert to potential intrusions, allowing the systems administrator to be aware of the compromise almost immediately when it occurs.

There are a number of commercial IDS, each with varying levels of functionality. (For instance, Symantec's Endpoint Protection product offers excellent IDS services … for the desktop.  The server version is considerably less functional.)  One of the most efficient and free IDS systems is OSSEC.

OSSEC is a local agent that looks for changes to system configurations or binary files.  It periodically runs a rootkit detector and proactively firewalls IP's that appear to be attempting to compromise the system.   And it's easy to install!  Simply:

Make sure you have a c compiler like gcc installed.

Download the Linux/UNIX version from http://www.ossec.net/main/downloads/

Untar and install:

tar -zxf ossec-hids-2.2.tar.gz

cd ossec-hids-2.2

./install.sh

Walk through the installation questions; you want a local install, you want "y' to all functionality and you want to email notifications to root@localhost (and any other addresses you'd like.)

From the door, you should understand that you're going to get a lot of false positives.  Everytime you update a config file or do a software update on the system, it will alert you.  But, since you're the system administrator, that means you know what's going on with your system, right?  So, you'll know what's legit and what isn't.  And it's the 'what isn't' that's the scary stuff.