Announcement Announcement Module
Collapse
No announcement yet.
Basic Steps to make Linux server secure Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Basic Steps to make Linux server secure

    These are the Basic steps that can be followed for securing a linux server.


    A) CHKRootKit –Detects hacker software and notifies via email

    B) RootKit Hunter – A tool which scans for backdoors and malicious softwares present in the server.

    C) CSF – A policy based iptables firewall system used for the easy configuration of iptables rules.

    D) SSH Securing – For a better security of ssh connections.

    E) Host.conf Hardening –Prevents IP spoofing and dns poisoning

    F) Sysctl.conf Hardening – Prevents syn-flood attacks and other network abuses.

    G) FTP Hardening – Secure FTP software by upgrading to latest version

    H) TMP Hardening – Hardening /tmp, /var/tmp, /dev/shm for preventing the execution of malicious scripts and codes.

    I) Shell Fork Bomb/Memory Hog Protection – Protection against Telnet/SSH users using all of the server resources and causing a system crash.

    J) Enabling Mod Evasive

    K) Disable http Trace Xss attack

    L) Disable the dangerous Methods in Webserver.

    M) Disable Apache UserDir Sensitive Information Disclosure

    N) Disable Apache Web Server ETag Header Information Disclosure Weakness


    A) CHKRootKit –Detects hacker software and notifies via email

    chkrootkit (Check Rootkit) is a common Unix based program intented to help system administrators check their system for known rootkits. It is basically a shell script using common UNIX/Linux tools like strings and grep commands to check core system programs for signatures. If you doubt that your server has been hacked, chkrootkit is what you need to run.

    Chkrootkit’s installation is very easy. I am describing the steps below.

    1. Ssh to the server as ‘root’, and then wget the chkrootkit from its FTP location.

    wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz


    2. Unpack the tarball in the current directory.

    tar xvzf chkrootkit.tar.gz


    3. Go to the directory newly created, and compile the script.

    cd chkrootkit*
    make sense


    4. Once the compilation is complete, use the below command to execute chkrootkit.

    ./chkrootkit


    NOTE: Make sure that you have gcc and make on the server or else the installation will fail

    At this point, I would suggest that you set a crontab to execute this chkrootkit daily. You can even have the results sent to you via email.

    For that, create a file /etc/cron.daily/chkrootkit.sh

    Insert the following to the new file and save it:

    #!/bin/bash
    cd /yourinstallpath/chkrootkit-0.42b/
    ./chkrootkit | mail -s "Daily chkrootkit from Servername" admin@youremail.com


    1. Replace ‘yourinstallpath’ with the actual path to where you unpacked Chkrootkit.
    2. Change ‘Servername’ to the server your running so you know where it’s coming from.
    3. Change ‘admin@youremail.com’ to your actual email address where the script will mail you.

    Change the file permissions so that it can execute:

    chmod 755 /etc/cron.daily/chkrootkit.sh


    You will receive daily chkrootkit reports on your email address from now on.

    B) RootKit Hunter – A tool which scans for backdoors and malicious softwares present in the server.


    # cd /usr/src
    # wget
    'http://downloads.sourceforge.net/pro...use_mirror=ncu'
    # tar zxvf rkhunter-1.4.0.tar.gz
    # cd rkhunter*/


    Install:

    # ./installer.sh --layout default --install


    Update:

    # /usr/local/bin/rkhunter --update


    Scan:

    # /usr/local/bin/rkhunter -c


    Configuration:

    You may have configured your Server in a way that triggers warnings from rkhunter.

    Firstly, I would say listen to what it says and decide if you really need something that is a security risk and, secondly, if you do want the risk, there are ways of configuring rkhunter so it ignores certain things.

    Here's an example. Let's say I ran rkhunter and got this message:

    Checking for allowed root login... Watch out Root login possible. Possible risk!
    info: "PermitRootLogin yes" found in file /etc/ssh/sshd_config
    Hint: See logfile for more information about this issue


    That's fairly straight forward: I left the "PermitRootLogin" set to "yes" in my sshd_config file.

    Now we know that's a silly thing to do and it's a nice reminder to tighten up our SSH configuration.

    But let's say we do want to enable root logins via SSH but don't want a warning every time we run rkhunter.

    Enter /usr/local/etc/rkhunter.conf. Open it up:

    # vi /usr/local/etc/rkhunter.conf


    Scan down until you reach this line:

    #ALLOW_SSH_ROOT_USER=0


    Uncomment the line and change the 0 to a 1

    ALLOW_SSH_ROOT_USER=1


    Now when we run rkhunter there are no highlighted warnings and this message:

    Checking for allowed root login... [ OK (Remote root login permitted by explicit option) ]


    Now it's says root logins are OK, but specifies why it's OK: You explicitly allowed it.

    However, please don't allow root logins. Thanks.

    Automation:

    Lastly, we know that automation and email notification make an administrator's life a lot easier, so now we can add rkhunter to a cronjob.

    This is straight from the rkhunter website: You need to create a short shell script as follows:

    #!/bin/sh

    ( /usr/local/bin/rkhunter --versioncheck
    /usr/local/bin/rkhunter --update
    /usr/local/bin/rkhunter --cronjob --report-warnings-only
    ) | /usr/bin/mail -s "rkhunter output" admin@yourdomain.com


    Save the file and call it something like 'rkhunterscript'. Make the file executable:

    # chmod 750 rkhunterscript


    and place in your local bin folder or in a public bin folder. Now set a root cronjob as follows:

    # crontab -e


    Cronjob looks like this:

    10 3 * * * /path/to/rkhunterscript -c --cronjob


    C) CSF – A policy based iptables firewall system used for the easy configuration of iptables rules.

    Installation:

    # cd /usr/src/
    # rm -fv csf.tgz
    # wget http://www.configserver.com/free/csf.tgz
    # tar -xzf csf.tgz
    # cd csf*
    # sh install.sh


    Next, test whether you have the required iptables modules:

    # perl /etc/csf/csftest.pl


    Don't worry if you cannot run all the features, so long as the script doesn't
    report any FATAL errors.

    * csf installation for cPanel is preconfigured to work on a cPanel server with all
    the standard cPanel ports open.

    * csf installation for DirectAdmin is preconfigured to work on a DirectAdmin
    server with all the standard DirectAdmin ports open.

    * csf auto-configures your SSH port on installation where it's running on a non-
    standard port.

    * csf auto-whitelists your connected IP address where possible on installation.

    * You should ensure that kernel logging daemon (klogd) is enabled. Typically, VPS
    servers have this disabled and you should check /etc/init.d/syslog and make
    sure that any klogd lines are not commented out. If you change the file,
    remember to restart syslog.

    D) SSH Securing – For a better security of ssh connections.


    Disable SSH protocol 1

    To disable protocol 1 for SSH make sure your “/etc/ssh/sshd_config” has the following uncommented:

    # Protocol 2,1
    Protocol 2


    Restart SSH.

    Change the SSH Port on the server

    This step is more security by obscurity, changing SSH default port 22 to a port of your choice (normally high) will reduce the amount of bots trying to brute for your SSH server.

    To change SSH server port add the following entry in your “/etc/ssh/sshd_config”:

    # Run ssh on a non-standard port:
    Port 2233


    NOTE **** DONT FORGET TO OPEN FIREWALL PORT IN CSF AND RESTART CSF BEFORE RESTARTING SSHD ****

    (Don’t use the port number listed above and don’t use 2222, everyone uses this port and it gets scanned almost as much as 22).

    You will need to specify the new port you have chosen in Putty or on the command line when connecting, on Putty this is pretty obvious on Unix you would do so by:

    ssh -p 2233 user@server

    Disable root Login

    Adding the following to your sshd_config file :

    PermitRootLogin no


    Allow specific Users on SSH

    If it’s only you and a bunch of other admin’s accessing the server over SSH I would recommend the use of AllowUser in the ssh_config, this is a ACL for SSH allowing only the users written in the config file. The example below would allow keith & bart to access the server over SSH:

    AllowUsers keith bart


    Change SSH login grace time

    This is the period of unauthenticated time the connection is left open, the time you have to login. By default it’s normally 2 minutes, which is far to long in my opinion… I change mine to 30 seconds.

    LoginGraceTime 30


    Limit the amount of unauthenticated SSH connections

    When SSH servers are cracked attackers open up as many SSH connections to your server as possible, the more connections they can open the more simultaneous parallel crack attempts then can run.

    Adding the following to your sshd_config file will allow 2 unauthenticated connections to your server at the same time and randomly and increasingly drop connection attempts between 2 and the maximum of 10. If you have a lot of valid SSH user authenticating on your servers at the same time this should be increased.

    #MaxStartups 10
    MaxStartups 2:50:10

    E) Host.conf Hardening –Prevents IP spoofing and dns poisoning


    The host.conf file resides in /etc/host.conf. This is it before hardening:

    order hosts,bind


    After Host.conf Hardening

    order bind,hosts
    multi on
    nospoof on


    F) Sysctl.conf Hardening – Prevents syn-flood attacks and other network abuses.


    # mv /etc/sysctl.conf /etc/sysctl.conf.orig


    # vi /etc/sysctl.conf


    #Kernel sysctl configuration file for Red Hat Linux
    #
    # For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
    # sysctl.conf(5) for more details.

    # Disables packet forwarding
    net.ipv4.ip_forward=0

    # Disables IP source routing
    net.ipv4.conf.all.accept_source_route = 0
    net.ipv4.conf.lo.accept_source_route = 0
    net.ipv4.conf.eth0.accept_source_route = 0
    net.ipv4.conf.default.accept_source_route = 0

    # Enable IP spoofing protection, turn on source route verification
    net.ipv4.conf.all.rp_filter = 1
    net.ipv4.conf.lo.rp_filter = 1
    net.ipv4.conf.eth0.rp_filter = 1
    net.ipv4.conf.default.rp_filter = 1

    # Disable ICMP Redirect Acceptance
    net.ipv4.conf.all.accept_redirects = 0
    net.ipv4.conf.lo.accept_redirects = 0
    net.ipv4.conf.eth0.accept_redirects = 0
    net.ipv4.conf.default.accept_redirects = 0

    # Enable Log Spoofed Packets, Source Routed Packets, Redirect Packets
    net.ipv4.conf.all.log_martians = 0
    net.ipv4.conf.lo.log_martians = 0
    net.ipv4.conf.eth0.log_martians = 0

    # Disables IP source routing
    net.ipv4.conf.all.accept_source_route = 0
    net.ipv4.conf.lo.accept_source_route = 0
    net.ipv4.conf.eth0.accept_source_route = 0
    net.ipv4.conf.default.accept_source_route = 0

    # Enable IP spoofing protection, turn on source route verification
    net.ipv4.conf.all.rp_filter = 1
    net.ipv4.conf.lo.rp_filter = 1
    net.ipv4.conf.eth0.rp_filter = 1
    net.ipv4.conf.default.rp_filter = 1

    # Disable ICMP Redirect Acceptance
    net.ipv4.conf.all.accept_redirects = 0
    net.ipv4.conf.lo.accept_redirects = 0
    net.ipv4.conf.eth0.accept_redirects = 0
    net.ipv4.conf.default.accept_redirects = 0

    # Disables the magic-sysrq key
    kernel.sysrq = 0

    # Decrease the time default value for tcp_fin_timeout connection
    net.ipv4.tcp_fin_timeout = 15

    # Decrease the time default value for tcp_keepalive_time connection
    net.ipv4.tcp_keepalive_time = 1800

    # Turn off the tcp_window_scaling
    net.ipv4.tcp_window_scaling = 0

    # Turn off the tcp_sack
    net.ipv4.tcp_sack = 0

    # Turn off the tcp_timestamps
    net.ipv4.tcp_timestamps = 0

    # Enable TCP SYN Cookie Protection
    net.ipv4.tcp_syncookies = 1

    # Enable ignoring broadcasts request
    net.ipv4.icmp_echo_ignore_broadcasts = 1

    # Enable bad error message Protection
    net.ipv4.icmp_ignore_bogus_error_responses = 1

    # Log Spoofed Packets, Source Routed Packets, Redirect Packets
    net.ipv4.conf.all.log_martians = 1

    # Increases the size of the socket queue (effectively, q0).
    net.ipv4.tcp_max_syn_backlog = 1024

    # Increase the tcp-time-wait buckets pool size
    net.ipv4.tcp_max_tw_buckets = 1440000

    # Allowed local port range
    net.ipv4.ip_local_port_range = 16384 65536


    After you make the changes to the file you need to run


    # /sbin/sysctl -p

    and


    # sysctl -w net.ipv4.route.flush=1

    to enable the changes without a reboot.


    G) FTP Hardening – Secure FTP software by upgrading to latest version


    CPANEL:

    # /scripts/ftpup --force


    WHM – Service Configuration – FTP Configuration:

    Disable anonymous FTP access

    H) TMP Hardening – Hardening /tmp, /var/tmp, /dev/shm for preventing the execution of malicious scripts and codes.


    Before TMP Directory Hardening, /etc/fstab line might be:

    /dev/sda2 /tmp ext3 defaults 1 1


    After TMP Directory Hardening

    /dev/sda2 /tmp ext3 rw,nodev,nosuid,noexec 1 1

    I) Shell Fork Bomb/Memory Hog Protection – Protection against Telnet/SSH users using all of the server resources and causing a system crash.

    This feature will prevent users with terminal access (SSH or Telnet) from using up the system’s resources and potentially crashing your web server via a malicious attack known as a fork bomb.
    Fork bombs work by starting a cascade of small processes that duplicate themselves until the server’s resources are depleted. WHM includes this feature to protect your server against fork bombs.

    (Home >> Security Center >> Shell Fork Bomb Protection)

    In order to enable Shell Fork Bomb Protection, the /etc/profile file must be editable:

    # chattr -i /etc/profile



    J) Enabling Mod Evasive

    Mod_Evasive – mod_evasive is an evasive maneuvers module for Apache that provides evasive action in the event of an HTTP DoS attack or brute force attack. It is also designed to be a detection and network management tool and can be easily configured to talk to ipchains, firewalls, routers, and more.
    Adding custom rules for preventing iframes and other attack on the server
    Configuring server for dropping DOS/DDOS attack

    Download the latest source file from http://www.zdziarski.com
    cd /usr/local/src/
    wget http://pkgs.fedoraproject.org/repo/pkgs ... 0.1.tar.gz
    wget http://www.zdziarski.com/projects/mod_e ... 0.1.tar.gz
    tar -xvzf mod_evasive_1.10.1.tar.gz
    cd mod_evasive/

    We also have cPanel running on this box, so, to install, we run the following:

    /usr/local/apache/bin/apxs -i -a -c mod_evasive20.c

    Now, that will create an entry in the httpd.conf file, and, if we want to retain that after an upgrade/rebuild, we need to tell cPanel not to take it out! Do do this, we now run this:

    /usr/local/cpanel/bin/apache_conf_distiller –update

    Now, to change the settings for mod_evasive, we need to add them in some place. All we have done so far, is install the actually module into apache, and, even with a restart, it would not be using it. So, I like to add things into my includes files through either WHM, or, directly through the terminal. To do this, we run the following:

    vim /usr/local/apache/conf/includes/post_virtualhost_2.conf

    Once the file is open, lets add in the following lines to the bottom of the file:

    DOSHashTableSize 3097
    DOSPageCount 2
    DOSSiteCount 50
    DOSPageInterval 1
    DOSSiteInterval 1
    DOSBlockingPeriod 3600
    DOSEmailNotify root

    =====
    OR
    =====
    <IfModule mod_evasive20.c>
    DOSHashTableSize 3097
    DOSPageCount 5
    DOSSiteCount 100
    DOSPageInterval 2
    DOSSiteInterval 2
    DOSBlockingPeriod 10
    DOSBlockingPeriod 600
    </IfModule>


    K) Disable http Trace Xss attack

    We need to disable the TRACE and/or TRACK methods in the Webserver. TRACE and TRACK
    are HTTP methods which are used to debug web server connections.
    It has been shown that servers supporting this method are subject to
    cross-site-scripting attacks, dubbed XST for Cross-Site-Tracing, when
    used in conjunction with various weaknesses in browsers.
    An attacker may use this flaw to trick your legitimate web users to give
    him their credentials.

    Solution:
    Add the following lines for each virtual host in your configuration file :

    RewriteEngine on
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]


    L) Disable the dangerous Methods in Webserver.

    We also need to disable the dangerous methods DELETE and PUT.

    Add the following lines for each virtual host in your configuration file :

    RewriteEngine on
    RewriteCond %{REQUEST_METHOD} ^(DELETE|PUT)
    RewriteRule .* - [F]


    M) Disable Apache UserDir Sensitive Information Disclosure


    An information leak occurs on Apache based web servers
    whenever the UserDir module is enabled. The vulnerability allows an external
    attacker to enumerate existing accounts by requesting access to their home
    directory and monitoring the response.
    Solution:
    1) Disable this feature by changing ’UserDir public_html’ (or whatever) to
    ’UserDir disabled’.
    Or
    2) Use a RedirectMatch rewrite rule under Apache -- this works even if there
    is no such entry in the password file, e.g.:
    RedirectMatch ^/~(.*)$ http://my-target-webserver.somewhere.org/$1
    Or
    3) Add into httpd.conf:
    ErrorDocument 404 http://localhost/sample.html
    ErrorDocument 403 http://localhost/sample.html
    (NOTE: You need to use a FQDN inside the URL for it to work properly).
    Additional Information:
    http://www.securiteam.com/unixfocus/5WP0C1F5FI.html


    N) Disable Apache Web Server ETag Header Information Disclosure Weakness

    A weakness has been discovered in Apache web servers that are
    configured to use the FileETag directive. Due to the way in which
    Apache generates ETag response headers, it may be possible for an
    attacker to obtain sensitive information regarding server files.
    Specifically, ETag header fields returned to a client contain the
    file’s inode number.
    Exploitation of this issue may provide an attacker with information
    that may be used to launch further attacks against a target network.


    For disabling the FileETag Direcitive add the following entry in your apache configuration file:

    FileETag none
    Last edited by JinoJoseph; 6th May 2014, 11:34 AM.
Tag Cloud Tag Cloud Module
Collapse
Working...
X