Close Open DNS Servers Published: Mar 16, 2006
  • Rating

    5/5

10 Steps to Securing your Server is an easy to follow guide that everyone should use to secure the basics of a web server. Follow this guide to prevent your server from getting hacked.

10 Steps to Securing your Server

So many people are getting their own dedicated servers but are completely clueless about security. Usually they leave it up to the company where they purchase it or hire someone. That's fine but make sure you have these 10 items covered.

1) Use a Firewall
Make absolutely sure that your server has a firewall running all the time. A firewall is like a screen door to your porch. It blocks out flies, rodents and other pests but you can still walk out and use your BBQ. If someone ever were to get into your server, which is very very likely, the first thing they're going to try and do is upload something to start a daemon or their own service like an IRC server or use a port to launch attacks to other systems. A firewall with egress and ingress protection can stop both incoming and outgoing attacks even when you're not aware of it. We recommend using APF on Linux systems or TinyFirewall on Windows Servers. These are software firewalls so there's no extra monthly cost like a hardware firewall. For very busy systems a hardware firewall is recommended so it takes the burden off your system CPU/RAM and resources to do the work.

Know what ports are open and why, know how to block and unblock an IP. These are basic things you need to understand in the daily security of your system. If someone from an IP begins a brute force attack you want to know how to stop them, right away. Installing APF Firewall, Preventing Brute Force Attacks, Installing KISS Firewall

2) Update your kernel and OS
Make sure your server is using current, updated software. Use the stable version which has been tested more than any beta and update as soon as possible. An old kernel can lead to an easy target for your server. If you're not sure then ask your provider for the latest update.


3) Monitor Logs
Do you know what logs record which activities? How often are they updated and rotated?
LogWatch is a great tool to email you the daily reports of your systems activity of anything it determines unusual, EG repeated failed logins. Besides using this you should check your logs manually to see what’s up. Tail –f /var/log/messages and view your Apache logs as well. Apache Log Files Explained

4) Backups
I still never understand why no one backs up their data yet you spend hundreds of hours working on your website or application then you absolutely must have a second hard drive for backups or use a remote back up system or a combination of these. Second Hard Drive Means Life or Death

5) Limit Access to a Minimum
Do not give users more access than the absolute minimum they require. Never give them shell access, restrict file access to a bare minimum and leave other services turned off by default until specifically requested and you determine that its safe to do so.


6) Lock down PHP and use Mod_Security with Apache
PHP is actually a large security risk but there are a few things to do to help lock it down. CGI has Suexec,which helps runs proccesess as the user and PHP has something similar called PHPSuexec but there are a few downfalls. You should also use open_base directory protection, have safe_mode on system wide, turn off register_globals, enable_dl and allow_url_open to help lock things down further.

You can use server wide protection with mod_security, a web server filter that can watch all requests to see if they match a rule and react by logging, denying the request or other programs. I highly recommend this on Apache based servers and can be extremely useful in blocking attacks and stopping hackers before they do any damage. Securing Safe Mode , Installing Mod_Security


7) Lock /tmp /var/tmp and /dev/shm partitions
On Linux each partition can have certain access restrictions. Since /tmp /var/tmp and /dev/shm are world writable directories they’re often home to uploads, sessions storage and hacker executables. Since anyone can read-write-excute anything from these directories it becomes a major security concern. With /etc/fstab however you can limit what can be done in these locations. If you see defaults beside the /tmp line remove it and replace it with noexec,nosuid this will stop any executables from being allowed to run. Do the same for /dev/shm and make /var/tmp and shortcut (symbolic link) to /tmp. Securing Your TMP Partition

8) Intrusion Detection System (IDS)
An intrusion detection system or IDS is like a burglar alarm on your server. It keeps a record of which files were changed when and alerts you of anything new or altered. This is critical because hackers usually try to replace binary applications like ps, top, netstat and others. This means when you run this new version of ps or top to see processes running they make it so it actually HIDES their hacker software, even though its running it won’t show up. Some IDS systems include TripWire, Snort and AIDE. Installing Chkrootkit

9) Review Processes Running and Remove Extra Software
You can’t protect a system if you don’t know what’s on it. If a hacker adds an extra process that you see in PS but you wouldn’t notice if you didn’t know what should be there usually. Know what runs on your system and why which user. How does Perl or Apache run, under which user? You can check your processes usually with top or ps auxfww which gives you a tree view. Check these every time you login to your server. Getting started with Shell (SSH) , Common Shell Commands

10) Keep an Eye on the Servers Performance
Know what speed your server is running at and how much bandwidth it uses on a daily basis. If an attacker compromises your system and you don’t know you’ll probably notice the system responding slowly or using a lot of bandwidth. If you don’t know what your system is usually like how will you notice something out of the ordinary. This is all common sense but some people never bother to check until they ask their provider after a system has been slow for 2 weeks – it’s usually to late then. Server Loads Explained

Knowing your system makes you one step ahead of an intruder. Check it often and ask an expert if you’re ever over your head. There are MANY other things you can and should do to ensure your server is secure but these are a few basics that everyone should use.

If you have anything you’d like to add please post in our forums or comment on this article.

About the Author:
Steven Leggett is the editor of the server resource and hosting tutorial site, www.webhostgear.com and specializes in system administration and web development.

  • Rating

    5/5

Related Articles

Comments (20)

  • Gravatar - Jen
    Jen 19:58, March 20, 2006
    If you have multiple servers running off the same DNS, make sure that you put all those server IPs in the trusted area if they are resolving through that DNS:<br />
    <br />
    <pre>acl "trusted" {<br />
    mainIP;secondaryIP;firstserverip;secondserverip;127.0.0.1;<br />
    };</pre><br />
    <br />
    Otherwise, great tutorial.
  • Gravatar - zac
    zac 21:57, March 22, 2006
    actually all you need to do is tihs:<br />
    <br />
    options {<br />
    recursion no;<br />
    };<br />
    <br />
  • Gravatar - Rajesh
    Rajesh 09:42, March 23, 2006
    i did as per the instructions but the "Open DNS Servers" still show fail. please let me what else is to be done.
  • Gravatar - Andrew
    Andrew 20:11, March 23, 2006
    The above breaks Bind on a VPS
  • Gravatar - Rajesh
    Rajesh 10:10, March 29, 2006
    I did as mentioned above but still the "Open DNS Servers" show fail in the DNS stuff.
  • Gravatar - dew
    dew 11:40, April 12, 2006
    really
  • Gravatar - alan
    alan 12:46, April 18, 2006
    this worked as-is for me
  • Gravatar - valtea
    valtea 20:35, April 19, 2006
    My server have <br />
    <br />
    root@server [/etc]# cat named.conf<br />
    include "/etc/rndc.key";<br />
    <br />
    controls {<br />
    inet 127.0.0.1 allow { localhost; } keys { "rndckey"; };<br />
    };<br />
    So where do i Add <br />
    acl "trusted" {<br />
    mainIP;secondaryIP;127.0.0.1;<br />
    };<br />
    Will it be on the same line with the keys after "rndckey"; <here><br />
    or <br />
    "rndckey"; }; <Here><br />
    };
  • Gravatar - Ryan
    Ryan 02:22, May 4, 2006
    Did anyone come up with an answer for valtea or does anyone know? I have been researching until I am blue in the face.
  • Gravatar - Dan
    Dan 16:54, May 13, 2006
    Got the same problem as valtea!
  • Gravatar - Kyle
    Kyle 19:34, May 15, 2006
    Same problem as above!
  • Gravatar - Steve
    Steve 17:46, May 18, 2006
    Add it after the controls section. <br />
    <br />
    EG:<br />
    controls {<br />
    inet 127.0.0.1 allow { localhost; } keys { "rndckey"; };<br />
    };<br />
    <br />
    Add it here<br />
  • Gravatar - Nick
    Nick 08:35, June 27, 2006
    Thanks, this tutorial worked great!
  • Gravatar - Spock
    Spock 21:15, July 9, 2006
    Steve, I tried adding it after controls, but I receive this error:<br />
    <br />
    Stopping named: [ OK ]<br />
    Starting named: /etc/named.conf:17: missing ';' before '}'<br />
    /etc/named.conf:18: missing ';' before '}'<br />
    /etc/named.conf:19: missing ';' before '}'<br />
    <br />
    Jul 10 04:12:50.694 starting BIND 9.2.4 -g<br />
    Jul 10 04:12:50.717 using 1 CPU<br />
    Jul 10 04:12:50.722 loading configuration from '/etc/named.conf'<br />
    Jul 10 04:12:50.723 /etc/named.conf:1: open: /etc/rndc.key: permission denied<br />
    Jul 10 04:12:50.723 loading configuration: permission denied<br />
    Jul 10 04:12:50.723 exiting (due to fatal error)<br />
    Error in configuration file /etc/named.conf : [FAILED]<br />
    <br />
    ===================<br />
    Here are the first lines of my named.conf:<br />
    <br />
    include "/etc/rndc.key";<br />
    <br />
    controls {<br />
    inet 127.0.0.1 allow { localhost; } keys { "rndckey"; };<br />
    };<br />
    <br />
    acl "trusted" {<br />
    ip1;ip2;ip3;ip4;ip5;127.0.0.1;<br />
    };<br />
    <br />
    //<br />
    // named.conf for Red Hat caching-nameserver<br />
    //<br />
    <br />
    options {<br />
    directory "/var/named";<br />
    allow-recursion { trusted };<br />
    allow-notify { trusted };<br />
    allow-transfer { trusted };<br />
    dump-file "/var/named/data/cache_dump.db";<br />
    statistics-file "/var/named/data/named_stats.txt";<br />
    /*<br />
    * If there is a firewall between you and nameservers you want<br />
    * to talk to, you might need to uncomment the query-source<br />
    * directive below. Previous versions of BIND always asked<br />
    * questions using port 53, but BIND 8.1 uses an unprivileged<br />
    * port by default.<br />
    */<br />
    // query-source address * port 53;<br />
    version "surely ye jest?";<br />
    };<br />
    ===================<br />
    Suggestions?
  • Gravatar - Spock
    Spock 21:27, July 9, 2006
    Solved it! I just missed the ";" after the words trusted inside allow-recursion { trusted; }; etc.
  • Gravatar - Andrew
    Andrew 04:40, July 20, 2006
    How long does it takes dnsreport.com to update this info after you make changes?
  • Gravatar - Hussein
    Hussein 05:50, October 15, 2006
    Like Zac above noted.<br />
    All you need to do is add a like in the options sections that looks like this:<br />
    <br />
    recursion no;<br />
    <br />
    This should close your server.<br />
    <br />
    If you need to harden and secure Bind even more, you can have a look at this site:<br />
    <br />
    http://www.cymru.com/Documents/secure-bind-template.html<br />
    <br />
    You need to be carful, and back up your named.conf file before testing, but this is a complete secured Bind template.<br />
    <br />
    Cheers
  • Gravatar - Ricardo
    Ricardo 05:44, April 4, 2007
    I did all this things but the problem i have is that then my clients stop receiving emails and they are not able to send either i have added all the ips of the server plus 127.0.0.1...any ideas?
  • Gravatar - G
    G 03:59, June 1, 2007
    thanks worked a treat
  • Gravatar - ahmed
    ahmed 07:55, February 25, 2010
    close open dns

Add Your Thoughts

WebHostGear.com is a hosting directory, not a web host.

Copyright © 1998-2014 WebHostGear.com