{"id":12034,"date":"2019-03-21T03:59:55","date_gmt":"2019-03-21T03:59:55","guid":{"rendered":"http:\/\/www.appservgrid.com\/paw92\/?p=12034"},"modified":"2019-03-21T03:59:55","modified_gmt":"2019-03-21T03:59:55","slug":"protect-apache-against-brute-force-or-ddos-attacks-using-mod_security-and-mod_evasive-modules","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw92\/index.php\/2019\/03\/21\/protect-apache-against-brute-force-or-ddos-attacks-using-mod_security-and-mod_evasive-modules\/","title":{"rendered":"Protect Apache Against Brute Force or DDoS Attacks Using Mod_Security and Mod_evasive Modules"},"content":{"rendered":"

For those of you in the hosting business, or if you\u2019re hosting your own servers and exposing them to the Internet, securing your systems against attackers must be a high priority.<\/p>\n

mod_security<\/b>\u00a0(an open source intrusion detection and prevention engine for web applications that integrates seamlessly with the web server) and\u00a0mod_evasive<\/b>\u00a0are two very important tools that can be used to protect a web server against brute force or (D)DoS attacks.<\/p>\n

Read Also<\/b>\u00a0:\u00a0How to Install Linux Malware Detect with ClamAV as Antivirus Engine<\/a><\/p>\n

mod_evasive<\/b>, as its name suggests, provides evasive capabilities while under attack, acting as an umbrella that shields web servers from such threats.<\/p>\n

\n

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

Install Mod_Security and Mod_Evasive to Protect Apache<\/p>\n<\/div>\n

<\/center>In this article we will discuss how to install, configure, and put them into play along with Apache on\u00a0RHEL<\/strong>\/CentOS 6<\/strong>\u00a0and\u00a07<\/strong>\u00a0as well as\u00a0Fedora 21-15<\/strong>. In addition, we will simulate attacks in order to verify that the server reacts accordingly.<\/p>\n

This assumes that you have a LAMP server installed on your system. If not, please check this article before proceeding further.<\/p>\n

    \n
  1. Install LAMP stack in RHEL\/CentOS 7<\/a><\/li>\n<\/ol>\n

    You will also need to setup\u00a0iptables<\/strong>\u00a0as the default firewall front-end instead of\u00a0firewalld<\/a>\u00a0if you\u2019re running RHEL\/CentOS 7 or Fedora 21. We do this in order to use the same tool in both\u00a0RHEL<\/strong>\/CentOS 7<\/strong>\/6<\/strong>\u00a0and\u00a0Fedora 21<\/strong>.<\/p>\n

    Step 1: Installing Iptables Firewall on RHEL\/CentOS 7 and Fedora 21<\/h3>\n

    To begin, stop and disable\u00a0firewalld<\/b>:<\/p>\n

    # systemctl stop firewalld\r\n# systemctl disable firewalld\r\n<\/pre>\n
    \n
    \"Disable<\/a><\/p>\n
    Disable Firewalld Service<\/p>\n<\/div>\n
    Then install the\u00a0iptables-services<\/b>\u00a0package before enabling\u00a0iptables<\/b>:<\/p>\n
    # yum update && yum install iptables-services\r\n# systemctl enable iptables\r\n# systemctl start iptables\r\n# systemctl status iptables\r\n<\/pre>\n
    \n
    \"Install<\/a><\/p>\n
    Install Iptables Firewall<\/p>\n<\/div>\n
    Step 2: Installing Mod_Security and Mod_evasive<\/h3>\n
    In addition to having a LAMP setup already in place, you will also have to\u00a0enable the EPEL repository<\/a>\u00a0in\u00a0RHEL<\/strong>\/CentOS 7<\/strong>\/6<\/strong>\u00a0in order to install both packages. Fedora users don\u2019t need to enable any repo, because epel is a already part of Fedora project.<\/p>\n
    # yum update && yum install mod_security mod_evasive\r\n<\/pre>\n
    When the installation is complete, you will find the configuration files for both tools in\u00a0\/etc\/httpd\/conf.d<\/b>.<\/p>\n
    # ls -l \/etc\/httpd\/conf.d\r\n<\/pre>\n
    \n
    \"mod_security<\/a><\/p>\n
    mod_security + mod_evasive Configurations<\/p>\n<\/div>\n
    Now, in order to integrate these two modules with\u00a0Apache<\/b>\u00a0and have it load them when it starts, make sure the following lines appear in the top level section of\u00a0mod_evasive.conf<\/b>\u00a0and\u00a0mod_security.conf<\/b>, respectively:<\/p>\n
    LoadModule evasive20_module modules\/mod_evasive24.so\r\nLoadModule security2_module modules\/mod_security2.so\r\n<\/pre>\n
    Note that\u00a0modules\/mod_security2.so<\/b>\u00a0and\u00a0modules\/mod_evasive24.so<\/b>\u00a0are the relative paths, from the\u00a0\/etc\/httpd<\/b>\u00a0directory to the source file of the module. You can verify this (and change it, if needed) by listing the contents of the\u00a0\/etc\/httpd\/modules<\/b>\u00a0directory:<\/p>\n
    # cd \/etc\/httpd\/modules\r\n# pwd\r\n# ls -l | grep -Ei '(evasive|security)'\r\n<\/pre>\n
    \n
    \"Verify<\/a><\/p>\n
    Verify mod_security + mod_evasive Modules<\/p>\n<\/div>\n
    Then restart Apache and verify that it loads\u00a0mod_evasive<\/b>\u00a0and\u00a0mod_security<\/b>:<\/p>\n
    # service httpd restart \t\t[On RHEL\/CentOS 6 and Fedora 20-18]\r\n# systemctl restart httpd \t\t[On RHEL\/CentOS 7 and Fedora 21]<\/pre>\n
    [Dump a list of loaded Static and Shared Modules]\r\n\r\n# httpd -M | grep -Ei '(evasive|security)'\t\t\t\t\r\n<\/pre>\n
    \n
    \"Check<\/a><\/p>\n
    Check mod_security + mod_evasive Modules Loaded<\/p>\n
    Step 3: Installing A Core Rule Set and Configuring Mod_Security<\/h3>\n
    In few words, a\u00a0Core Rule Set<\/b>\u00a0(aka\u00a0CRS<\/b>) provides the web server with instructions on how to behave under certain conditions. The developer firm of\u00a0mod_security<\/b>\u00a0provide a free\u00a0CRS<\/b>\u00a0called\u00a0OWASP<\/b>\u00a0(Open Web Application Security Project<\/a>) ModSecurity CRS that can be downloaded and installed as follows.<\/p>\n
    1.<\/strong>\u00a0Download the\u00a0OWASP CRS<\/b>\u00a0to a directory created for that purpose.<\/p>\n
    # mkdir \/etc\/httpd\/crs-tecmint\r\n# cd \/etc\/httpd\/crs-tecmint\r\n# wget https:\/\/github.com\/SpiderLabs\/owasp-modsecurity-crs\/tarball\/master\r\n<\/pre>\n
    \n
    \"Download<\/a><\/p>\n
    Download mod_security Core Rules<\/p>\n<\/div>\n
    2.<\/strong>\u00a0Untar the\u00a0CRS<\/b>\u00a0file and change the name of the directory for one of our convenience.<\/p>\n
    # tar xzf master\r\n# mv SpiderLabs-owasp-modsecurity-crs-ebe8790 owasp-modsecurity-crs\r\n<\/pre>\n
    \n
    \"Extract<\/a><\/p>\n
    Extract mod_security Core Rules<\/p>\n<\/div>\n
    3.<\/strong>\u00a0Now it\u2019s time to configure mod_security. Copy the sample file with rules (owasp-modsecurity-crs\/modsecurity_crs_10_setup.conf.example<\/b>) into another file without the\u00a0.example<\/b>\u00a0extension:<\/p>\n
    # cp modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf<\/pre>\n
    and tell\u00a0Apache<\/b>\u00a0to use this file along with the module by inserting the following lines in the web server\u2019s main configuration file\u00a0\/etc\/httpd\/conf\/httpd.conf<\/b>\u00a0file. If you chose to unpack the tarball in another directory you will need to edit the paths following the Include directives:<\/p>\n
    <IfModule security2_module>\r\n    Include crs-tecmint\/owasp-modsecurity-crs\/modsecurity_crs_10_setup.conf\r\n    Include crs-tecmint\/owasp-modsecurity-crs\/base_rules\/*.conf\r\n<\/IfModule>\r\n<\/pre>\n
    Finally, it is recommended that we create our own configuration file within the\u00a0\/etc\/httpd\/modsecurity.d<\/b>directory where we will place our customized directives (we will name it\u00a0tecmint.conf<\/b>\u00a0in the following example) instead of modifying the\u00a0CRS<\/b>\u00a0files directly. Doing so will allow for easier upgrading the CRSs as new versions are released.<\/p>\n
    <IfModule mod_security2.c>\r\n\tSecRuleEngine On\r\n\tSecRequestBodyAccess On\r\n\tSecResponseBodyAccess On \r\n\tSecResponseBodyMimeType text\/plain text\/html text\/xml application\/octet-stream \r\n\tSecDataDir \/tmp\r\n<\/IfModule>\r\n<\/pre>\n
    You can refer to the\u00a0SpiderLabs\u2019 ModSecurity GitHub<\/a>\u00a0repository for a complete explanatory guide of\u00a0mod_security<\/b>\u00a0configuration directives.<\/p>\n
    Step 4: Configuring Mod_Evasive<\/h3>\n
    mod_evasive<\/b>\u00a0is configured using directives in\u00a0\/etc\/httpd\/conf.d\/mod_evasive.conf<\/b>. Since there are no rules to update during a package upgrade, we don\u2019t need a separate file to add customized directives, as opposed to\u00a0mod_security<\/b>.<\/p>\n
    The default\u00a0mod_evasive.conf<\/b>\u00a0file has the following directives enabled (note that this file is heavily commented, so we have stripped out the comments to highlight the configuration directives below):<\/p>\n
    <IfModule mod_evasive24.c>\r\n    DOSHashTableSize    3097\r\n    DOSPageCount        2\r\n    DOSSiteCount        50\r\n    DOSPageInterval     1\r\n    DOSSiteInterval     1\r\n    DOSBlockingPeriod   10\r\n<\/IfModule>\r\n<\/pre>\n
    Explanation of the directives:<\/p>\n
      \n
    1. DOSHashTableSize<\/b>: This directive specifies the size of the hash table that is used to keep track of activity on a per-IP address basis. Increasing this number will provide a faster look up of the sites that the client has visited in the past, but may impact overall performance if it is set too high.<\/li>\n
    2. DOSPageCount<\/b>: Legitimate number of identical requests to a specific URI (for example, any file that is being served by Apache) that can be made by a visitor over the DOSPageInterval interval.<\/li>\n
    3. DOSSiteCount<\/b>: Similar to DOSPageCount, but refers to how many overall requests can be made to the entire site over the DOSSiteInterval interval.<\/li>\n
    4. DOSBlockingPeriod<\/b>: If a visitor exceeds the limits set by DOSSPageCount or DOSSiteCount, his source IP address will be blacklisted during the DOSBlockingPeriod amount of time. During DOSBlockingPeriod, any requests coming from that IP address will encounter a 403 Forbidden error.<\/li>\n<\/ol>\n
      Feel free to experiment with these values so that your web server will be able to handle the required amount and type of traffic.<\/p>\n
      Only a small caveat<\/strong>: if these values are not set properly, you run the risk of ending up blocking legitimate visitors.<\/p>\n
      You may also want to consider other useful directives:<\/p>\n
      DOSEmailNotify<\/h5>\n
      If you have a mail server up and running, you can send out warning messages via Apache. Note that you will need to grant the apache user SELinux permission to send emails if SELinux is set to enforcing. You can do so by running<\/p>\n
      # setsebool -P httpd_can_sendmail 1\r\n<\/pre>\n
      Next, add this directive in the\u00a0mod_evasive.conf<\/b>\u00a0file with the rest of the other directives:<\/p>\n
      DOSEmailNotify you@yourdomain.com\r\n<\/pre>\n
      If this value is set and your mail server is working properly, an email will be sent to the address specified whenever an IP address becomes blacklisted.<\/p>\n
      DOSSystemCommand<\/h5>\n
      This needs a valid system command as argument,<\/p>\n
      DOSSystemCommand <\/command>\r\n<\/pre>\n
      This directive specifies a command to be executed whenever an IP address becomes blacklisted. It is often used in conjunction with a shell script that adds a firewall rule to block further connections coming from that IP address.<\/p>\n
      Write a shell script that handles IP blacklisting at the firewall level<\/h6>\n
      When an IP address becomes blacklisted, we need to block future connections coming from it. We will use the following shell script that performs this job. Create a directory named\u00a0scripts-tecmint<\/b>\u00a0(or whatever name of your choice) in\u00a0\/usr\/local\/bin<\/b>\u00a0and a file called\u00a0ban_ip.sh<\/b>\u00a0in that directory.<\/p>\n
      #!\/bin\/sh\r\n# IP that will be blocked, as detected by mod_evasive\r\nIP=$1\r\n# Full path to iptables\r\nIPTABLES=\"\/sbin\/iptables\"\r\n# mod_evasive lock directory\r\nMOD_EVASIVE_LOGDIR=\/var\/log\/mod_evasive\r\n# Add the following firewall rule (block all traffic coming from $IP)\r\n$IPTABLES -I INPUT -s $IP -j DROP\r\n# Remove lock file for future checks\r\nrm -f \"$MOD_EVASIVE_LOGDIR\"\/dos-\"$IP\"\r\n<\/pre>\n
      Our\u00a0DOSSystemCommand<\/b>\u00a0directive should read as follows:<\/p>\n
      DOSSystemCommand \"sudo \/usr\/local\/bin\/scripts-tecmint\/ban_ip.sh %s\"\r\n<\/pre>\n
      In the line above,\u00a0%s<\/b>\u00a0represents the offending IP as detected by\u00a0mod_evasive<\/b>.<\/p>\n
      Add the apache user to the sudoers file<\/h6>\n
      Note that all of this just won\u2019t work unless you to give permissions to user\u00a0apache<\/b>\u00a0to run our script (and that script only!) without a terminal and password. As usual, you can just type\u00a0visudo<\/b>\u00a0as root to access the\u00a0\/etc\/sudoers<\/b>\u00a0file and then add the following 2 lines as shown in the image below:<\/p>\n
      apache ALL=NOPASSWD: \/usr\/local\/bin\/scripts-tecmint\/ban_ip.sh\r\nDefaults:apache !requiretty\r\n<\/pre>\n
      \n
      \"Add<\/a><\/p>\n
      Add Apache User to Sudoers<\/p>\n<\/div>\n
      IMPORTANT<\/strong>: As a default security policy, you can only run\u00a0sudo<\/b>\u00a0in a terminal. Since in this case we need to use\u00a0sudo<\/b>\u00a0without a\u00a0tty<\/b>, we have to comment out the line that is highlighted in the following image:<\/p>\n
      #Defaults requiretty\r\n<\/pre>\n
      \n
      \"Disable<\/a><\/p>\n
      Disable tty for Sudo<\/p>\n<\/div>\n
      Finally, restart the web server:<\/p>\n
      # service httpd restart \t\t[On RHEL\/CentOS 6 and Fedora 20-18]\r\n# systemctl restart httpd \t\t[On RHEL\/CentOS 7 and Fedora 21]<\/pre>\n
      Step 4: Simulating an DDoS Attacks on Apache<\/h3>\n
      There are several tools that you can use to simulate an external attack on your server. You can just google for \u201ctools for simulating ddos attacks<\/b>\u201d to find several of them.<\/p>\n
      Note that you, and only you, will be held responsible for the results of your simulation. Do not even think of launching a simulated attack to a server that you\u2019re not hosting within your own network.<\/p>\n
      Should you want to do the same with a VPS that is hosted by someone else, you need to appropriately warn your hosting provider or ask permission for such a traffic flood to go through their networks.\u00a0Tecmint.com<\/b>\u00a0is not, by any means, responsible for your acts!<\/p>\n
      In addition, launching a simulated DoS attack from only one host does not represent a real life attack. To simulate such, you would need to target your server from several clients at the same time.<\/p>\n
      Our test environment is composed of a\u00a0CentOS 7<\/b>\u00a0server [IP 192.168.0.17<\/b>] and a Windows host from which we will launch the attack [IP\u00a0192.168.0.103<\/b>]:<\/p>\n
      \n
      \"Confirm<\/a><\/p>\n
      Confirm Host IPAddress<\/p>\n<\/div>\n
      Please play the video below and follow the steps outlined in the indicated order to simulate a simple DoS attack:<\/p>\n
       <\/p>\n<\/div>\n