{"id":6386,"date":"2014-06-20T13:52:09","date_gmt":"2014-06-20T08:22:09","guid":{"rendered":"http:\/\/blog.resellerclub.com\/?p=6386"},"modified":"2025-02-27T11:50:02","modified_gmt":"2025-02-27T11:50:02","slug":"8-simple-ways-to-secure-your-linux-servers","status":"publish","type":"post","link":"https:\/\/www.resellerclub.com\/blog\/8-simple-ways-to-secure-your-linux-servers\/","title":{"rendered":"8 simple ways to secure your Linux Servers"},"content":{"rendered":"

\"8<\/a><\/p>\n

At ResellerClub<\/a>, our primary objective has always been to provide you with powerful, secure and robust hosting solutions. While for product such as Shared Hosting<\/a>, we take utmost care to ensure maximum server level security and redundancy, products such as Dedicated Servers<\/a> and VPS<\/a>, we can ensure network level security while the OS level control lies in your hands.<\/p>\n

Let\u2019s start by first understanding the basic concepts of a web server. A web server, simply put is a computer host configured and connected to the internet, for serving web pages on user requests. Since web servers are open to public access and often contain critical information, it is important to shield them from hackers.<\/p>\n

Although Linux based Operating Systems are relatively more secure and include inbuilt security mechanisms like SELINUX when compared to the others,\u00a0a small vulnerability or bug can give a hacker easy access to your system. Keeping this in mind, we\u2019ve put together a comprehensive set of steps that you can take to mitigate the risk of getting hacked.<\/p>\n

    \n
  1. Always stay up to date<\/strong><\/li>\n<\/ol>\n

    A great way to ensure maximum server security at all times is to keep your system up to date with the latest bug fixes or the latest version of your Operating System. A good way to keep track of update announcements is to sign up for email alerts. CentOS \u00a0and Ubuntu have a security mailing list where all security and vulnerability fixes are discussed and released.<\/p>\n

      \n
    1. Verify Permissions<\/strong><\/li>\n<\/ol>\n

      It is essential to review permission settings to ensure that a server remains secure. There are certain files such as the \u201c\/etc\/passwd\u201d, \u201c\/etc\/shadow\u201d, \u201c\/etc\/group\u201d and \u201c\/etc\/gshadow\u201cfiles that <\/strong>contain critical user, password and group information. These files have a greater chance of being subjected to malicious attacks.<\/p>\n

      Several utilities also require read access to the passwd \ufb01le to function properly, however read access to the shadow file will allow malicious attacks against system passwords, and should never be enabled and should never be enabled.<\/p>\n

      Below are the default permissions and owners that should be set for these files. \u00a0<\/strong><\/p>\n

      # cd \/etc<\/p>\n

      # chown root:root passwd shadow group gshadow<\/p>\n

      # chmod 644 passwd group<\/p>\n

      # chmod 400 shadow gshadow<\/p>\n

        \n
      1. Find unauthorized World Writable files<\/strong><\/li>\n<\/ol>\n

        The following command discovers and prints any world-writable \ufb01les in local partitions. Run it once for each local partition<\/p>\n

        # find \/tmp -xdev -type f -perm -0002 -print<\/p>\n

        If this command produces any output, \ufb01x each reported \ufb01le file using the command:<\/p>\n

        # chmod o-w file<\/p>\n

        Data in world writable \ufb01les can be modi\ufb01ed by any user on the system. In almost all circumstances, \ufb01les can be con\ufb01gured using a combination of user and group permissions to support whatever legitimate access is needed without the risk caused by world-writable \ufb01les.<\/p>\n

        It is generally a good idea to remove global (other) write access to a \ufb01le when it is discovered. However, it is always advisable to check relevant documentation for applications before making changes. Also, monitor for recurring world-writable \ufb01les, as these may be symptoms of a miscon\ufb01gured application or user account.<\/p>\n

          \n
        1. Set the sticky bit on World Writable directories<\/strong><\/li>\n<\/ol>\n

          Setting the sticky bit prevents users from removing each other\u2019s \ufb01les. \u00a0When a sticky-bit is set on a directory, only the owner of a given \ufb01le is given the right to remove it from the directory. Without the sticky bit, any user with write access to a directory can remove any \ufb01le from it.<\/p>\n

          Use the following command to discover\u00a0and print any world writable files that do not have their sticky bits set.<\/p>\n

          # find \/tmp -xdev -type d \\( -perm -0002 -a ! -perm -1000 \\) -print<\/p>\n

          If this command produces any output, \ufb01x each reported directory \/dir using the command:<\/p>\n

          # chmod +t \/dir<\/p>\n

          In cases where there is no reason for a directory to be world writable, a better solution is to remove that permission rather than to set the sticky bit.<\/p>\n

            \n
          1. Enable ExecShield<\/strong><\/li>\n<\/ol>\n

            ExecShield helps in\u00a0reducing the risk of worm or other automated remote attacks. It comprises a number of kernel features to provide protection against bu\ufb00er over\ufb02ows. These features include random placement of the stack and other memory regions and special handling of text bu\ufb00ers.<\/p>\n

            To ensure ExecShield (including random placement of virtual memory regions) is activated at boot, add or correct the following settings in \/etc\/sysctl.conf:<\/p>\n

            #kernel.exec-shield = 1<\/p>\n

            #kernel.randomize_va_space = 1<\/p>\n

              \n
            1. Con\ufb01gure Sudo to improve auditing of Root access<\/strong>C<\/strong><\/li>\n<\/ol>\n

              The sudo command allows \ufb01ne-grained control through which users can execute commands using other accounts. The primary bene\ufb01t associated with the configuration of sudo is that it provides an audit trail of every command run by a privileged user. It is possible for a malicious administrator to circumvent this restriction, but, if there is an established procedure that all root commands are run using sudo, then it is easy for an auditor to detect unusual behavior when this procedure is not followed.<\/p>\n

                \n
              1. Set Strict password requirements<\/strong><\/li>\n<\/ol>\n

                Setting more stringent password requirements can be an additional measure taken to step up server security.<\/p>\n

                User passwords should be strengthened with the PAM module which can be configured to require at least one uppercase character, lowercase character, digit, and other(special) character,<\/p>\n

                You can modify your password by following the steps listed below:<\/p>\n