The web hosting publication by web hosting users for web hosting users
Update a Host / Editor Login
Search
Article News Host Business Name
DIRECTORY TOP RATING EDITOR REVIEW SEARCH HOSTING SHOWCASE BECOME AN EDITOR
RECENT NEWS
Pingdom Adds Business Monitoring Plan
Apptix Offers Hosted VoIP Products
Hostway Offers Free Server Setup
FWHN Offers 3 Discount Programs
Hosting Networking Site Launches
Infinera Names Strategic Materials VP
Egenera Hosts Virtualization Webinar
DRT Offers Euro Data Center Study
ARTICLES
Co-location Hosting
Dedicated Servers
Domain Names
E-Commerce / Merchant Accounts / Payment Gateways
Free Web Hosting
General Web Hosting
Hosting Software & Control Panels
Managed Web Hosting
Programming
Reseller Hosting
Running a Web Hosting Business
Search Engine Optimization
Specific Web Hosting Provider or Company
Technical & Security
Useful Website Tools
Virtual Private Servers
Web Design & Content
Website Marketing Campaign
SEARCH ARTICLES
WEBHOST DIRECTORY
By Location

By Category
Application Hosting
Collocation Hosting
Dedicated Servers
Domain Name Registration
Ecommerce Hosting
Free Web Hosting
Reseller Domain Name Registration
Reseller Hosting
Shared Web Hosting
Virtual Private Servers
By Function
Windows Web hosting
PHP Web Hosting
Mysql Web Hosting
ASP Web Hosting
MS SQL Server Web Hosting
Coldfusion Web Hosting
MS FrontPage Web Hosting
Ecommerce Web Hosting
Cheap/Discount Web Hosting
Personal Web Hosting
Domain Name Web Hosting
A-Z Listing
Enter web host domain:




Articles
  You are here : Home Articles Hosting Software & Control Panels
Hardening a Linux server in 10 minutes
Submitted by Trevor Blunt on | 372 reads
Hardening a Linux server in 10 minutes

Read the title and wonder how possible that a freshly installed Linux server can be hardened in less than 10 minutes? Here is how!

Note: As the following commands are by and large issued in a terminal, you will require a bit of experience with the Linux command-line environment, and root access on your server as well. By the way, the following instructions apply to any LSB-compliant Linux distribution, but for an example, let us check on Fedora Core.

Step 1: turn all unneeded services off
There are two kinds of network services: those that get started as init.d services, and those that get started by xinetd. This distinction is important, as xinetd can start services on demand, while services started through init.d run all the time.

Alright, it is time to start securing your server. On a terminal, as root (and, for the purposes of this tutorial, assume this from now on) run netstat -ltunp . You should see a listing like this one:

root@andrea rudd-o]# netstat -ltunp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address                 State       PID/Program name
tcp        0          0 0.0.0.0:3493                    0.0.0.0:*                   LISTEN      30562/upsd
tcp        0          0 0.0.0.0:3306                    0.0.0.0:*                   LISTEN      12461/mysqld
tcp        0          0 0.0.0.0:6543                    0.0.0.0:*                   LISTEN      12490/mythbackend
tcp        0          0 0.0.0.0:111                     0.0.0.0:*                   LISTEN      1771/portmap
tcp        0          0 0.0.0.0:6544                    0.0.0.0:*                   LISTEN      12490/mythbackend
tcp        0          0 127.0.0.1:631                  0.0.0.0:*                   LISTEN      31537/cupsd
tcp        0          0 127.0.0.1:25                    0.0.0.0:*                   LISTEN      2143/sendmail: acce
tcp        0          0 :::80                           :::*                           LISTEN      5024/httpd
tcp        0          0 :::22                           :::*                            LISTEN      2009/sshd
tcp        0          0 0.0.0.0:19                      0.0.0.0:*                  LISTEN      2019/xinetd

Those are all processes listening to specific ports. As you can see, the PID (process ID) and the program name are displayed as well. Make two lists: one for the services you absolutely need (which you should already know by heart), and one for the services that are expendable or you can start manually when they are needed (tip: each program name usually ships with a main page).

You have to shutdown each service on the second list (except for xinetd). That is a pretty straightforward task. Each one of those services is started by init.d. To find out the name of the service control script, just hop to /etc/rc.d/init.d and look for a file with a name similar to the program name.
Example: assume you do not need mythbackend. To stop it: /etc/rc.d/init.d/mythbackend stop (some distributions provide the service mythbackend stop command, which is easier on your fingers). Now, to disable it: chkconfig --del mythbackend. After doing this, you should check to see if the offending service went away, with the same netstat -ltunp command.

Next, we go to that pesky xinetd. As we saw earlier, xinetd has its own ways. In practice, this means that some services will be started on demand — thus, you will not see them under your netstat -ltunp listing. To find out which services xinetd manages, hop to /etc/xinetd.d and do a directory listing. You should see some service configuration files. Identify the ones you will not be using, and edit each one of them, adding a line that says disable = yes between the curly braces.

Note that some services already ship with disable = yes, but some ship with disable = no. If one of the configuration files says disable = no, just change it to disable = yes. Now, reload xinetd with the famous /etc/rc.d/init.d/xinetd reload, and run netstat -ltunp again, just to be sure.
That is step 1. With a bit of practice, you should be doing this in five minutes or less.

Step 2: limit access to run services using iptables
It is great to have our server runs the absolutely required services, and no more. But, some of those services are not meant to be accessed from everywhere, right? For example: You may have a MySQL database server running, but that does not mean MySQL should be accessible from any random IP address on the Internet, true?
So, to stop evil at the door, use the firewall. Again, make a list of services. For each item on the list, identify which IP addresses should be able to reach the service. For each service on your list, write down the TCP/UDP port(s) they use. In previous example, MySQL uses TCP port 3306, and should only be accessible by localhost (127.0.0.1).
Afterward, to compose and activate the iptables rules just doing a quick check with iptables -L, then you can see that your INPUT chain (the one you will be working with, since you want to disallow INPUTs to your server) is empty:

[root@andrea xinetd.d]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Your mileage may vary, because your distribution may already have set up some basic iptables rules; to make these instructions foolproof, in this article rules are inserted at the beginning of the INPUT chain.
In this case, say that you want to allow access to 127.0.0.1:3306, and deny access to everyone else on port 3306, in that order. Hence, two rules are needed: add the “allow” rule into position 1 (the very first):
[root@andrea xinetd.d]# iptables -I INPUT 1 --protocol tcp --destination-port 3306 -s 127.0.0.1 -j ACCEPT
[root@andrea xinetd.d]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  localhost.localdomain  anywhere            tcp dpt:mysql
The firewall is being told to -j ACCEPT all --protocol tcp connections to --destination-port 3306 from the address -s 127.0.0.1. Now, insert the “deny” rule into position 2:
root@andrea xinetd.d]# iptables -I INPUT 2 --protocol tcp --destination-port 3306 -j REJECT
[root@andrea xinetd.d]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  localhost.localdomain  anywhere            tcp dpt:mysql
REJECT     tcp  --  anywhere             anywhere            tcp dpt:mysql reject-with icmp-port-unreachable
See how easy it is? Here is the explanation. Rule 2 tells the firewall to -j REJECT all --protocol tcp connections to --destination-port 3306 from any address (since I omitted the address).

Since rules are processed “top-down” (from 1 to n), the first one that matches an incoming connection is applied. If no rules match, the default policy (which is normally ACCEPT) kicks in.
Tizzy. Dip. Tizzy. Dip. Repeat for every service that you want to secure.

To finish, save the rules. For this, you will need to use your distribution's tools. For Fedora Core, that is as easy as issuing the command service iptables save and ensuring that the iptables service runs at boot time: chkconfig --add iptables .

It is worth noting that some people prefer to -j DROP instead of DENY ing. DROP means that your server will ignore connection attempts (neither denying connections nor accepting them). DENY is more preferred, because it is easier to pinpoint a problem with iptables rules that way, and (most importantly) DROP rules make those ports appear as filtered to a hostile port scanner (which hints to the attacker that a service is running).

So, that is it! From insecure to secure in 10 minutes!
Print these instructions out, and keep them posted on a wall in your office or home. Before plugging a freshly installed network server, simply remember to follow these instructions. Make these instructions second nature to you!


ARTICLES | NEWS | DIRECTORY | TOP REVIEWS| TOP RATINGS| SEARCH | SHOWCASE | UPDATE A HOST
OUR EDITORS | CONTACT US | ADVERTISING | TERMS OF AGREEMENT
© Copyright 2006 , The Web Hosting Herald. All rights reserved.