ModSecurity: OWASP CRS3 menambahkan
sumber: https://2buntu.com/articles/1571/installing-lamp-modsecurity-modsecurity-crs-on-ubuntu-1604/
LAMP stack refers to Linux, Apache, MySQL and PHP . With this bundle you can create web applications / services with Linux serving as the OS, Apache as the Web-Server, MySQL as the database server and PHP as the server-side programming language.
So what is ModSecurity?
ModSecurity is an open-source Web Application Firewall (WAF). It sits before your Web Server and so is able to monitor the incoming as well as the outgoing traffic. With this, we can, to some extent, prevent attacks, information leakage, etc.. Installation Installing LAMP Stack:
Installing the LAMP Stack on Ubuntu is a breeze! You have this meta-package called lamp-server that lets you install all the required packages and configures them so that you're ready to start playing at the end of it.
So open up a terminal and type,
$ sudo apt-get update && sudo apt-get install -y lamp-server^
Supply your password upon prompt and it'll proceed with the installation. In between, you'll be prompted to set the MySQL root user's password. After that, when you get your terminal prompt back, you should have a fully working LAMP stack, ready to go!
Don't believe me? Check it out yourself by browsing to http://localhost/. You should be able to see the default Apache page.
Default locations:
Apache Webroot: /var/www/html/ Apache Config: 1/etc/apache2/ Apache Log folder: /var/log/apache2/ PHP config: /etc/php5/ php.ini location for PHP Apps served by Apache: /etc/php5/apache2/php.ini
Installing ModSecurity
We are going to be installing ModSecurity as a module to Apache, so, please key in the following command in a terminal.
$ sudo apt-get install libapache2-modsecurity
Once that has finished installing, you can verify that ModSecurity has been installed and is running by running the following command:
$ apache2ctl -M | grep -i security
security2_module (shared)
Installing ModSecurity Core Rule Set
You might have noticed during installation that a package called modsecurity-crs got installed when you installed ModSecurity. That is the ModSecurity Core Rule Set, which is an OWASP project of ModSecurity rules that you can use to defend yourself against common web application attacks.
Installing the Github version
Some people like installing the Github version, since it provides more flexibility in terms of fetching any updates, switching between branches, etc.. To install the ModSecurity CRS from its Github repo, we need to replace the /usr/share/modsecurity-crs directory and then clone the repo at that location.
sudo rm -rf /usr/share/modsecurity-crs sudo apt-get install -y git sudo git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git /usr/share/modsecurity-crs
Finally, just copy/rename the example setup file to have a .conf extension.
sudo cp /usr/share/modsecurity-crs/modsecurity_crs_10_setup.conf.example /usr/share/modsecurity-crs/modsecurity_crs_10_setup.conf
Now we can continue with the following steps.
To set up the ModSecurity CRS, lets first switch to the /usr/share/modsecurity-crs directory.
$ cd /usr/share/modsecurity-crs
To activate the rules that you need, you need to place it in the activated_rules directory. First let's include the setup file by creating a soft link to it from the activated_rules directory.
$ sudo ln -s ../modsecurity_crs_10_setup.conf activated_rules/modsecurity_crs_10_setup.conf
Next, we'll include all the base_rules,
$ for f in `ls base_rules`; do sudo ln -s ../base_rules/$f activated_rules/$f; done
Now you're activated_rules directory should look something like this:
$ ll activated_rules/ total 20 drwxr-xr-x 2 root root 4096 Jun 26 14:15 ./ drwxr-xr-x 9 root root 4096 Jun 26 13:56 ../ lrwxrwxrwx 1 root root 44 Jun 26 14:07 modsecurity_35_bad_robots.data -> ../base_rules/modsecurity_35_bad_robots.data lrwxrwxrwx 1 root root 42 Jun 26 14:07 modsecurity_35_scanners.data -> ../base_rules/modsecurity_35_scanners.data lrwxrwxrwx 1 root root 49 Jun 26 14:07 modsecurity_40_generic_attacks.data -> ../base_rules/modsecurity_40_generic_attacks.data lrwxrwxrwx 1 root root 42 Jun 26 14:07 modsecurity_50_outbound.data -> ../base_rules/modsecurity_50_outbound.data lrwxrwxrwx 1 root root 50 Jun 26 14:07 modsecurity_50_outbound_malware.data -> ../base_rules/modsecurity_50_outbound_malware.data lrwxrwxrwx 1 root root 32 Jun 26 14:15 modsecurity_crs_10_setup.conf -> ../modsecurity_crs_10_setup.conf lrwxrwxrwx 1 root root 57 Jun 26 14:07 modsecurity_crs_20_protocol_violations.conf -> ../base_rules/modsecurity_crs_20_protocol_violations.conf lrwxrwxrwx 1 root root 56 Jun 26 14:07 modsecurity_crs_21_protocol_anomalies.conf -> ../base_rules/modsecurity_crs_21_protocol_anomalies.conf lrwxrwxrwx 1 root root 52 Jun 26 14:07 modsecurity_crs_23_request_limits.conf -> ../base_rules/modsecurity_crs_23_request_limits.conf lrwxrwxrwx 1 root root 49 Jun 26 14:07 modsecurity_crs_30_http_policy.conf -> ../base_rules/modsecurity_crs_30_http_policy.conf lrwxrwxrwx 1 root root 48 Jun 26 14:07 modsecurity_crs_35_bad_robots.conf -> ../base_rules/modsecurity_crs_35_bad_robots.conf lrwxrwxrwx 1 root root 53 Jun 26 14:07 modsecurity_crs_40_generic_attacks.conf -> ../base_rules /modsecurity_crs_40_generic_attacks.conf lrwxrwxrwx 1 root root 59 Jun 26 14:07 modsecurity_crs_41_sql_injection_attacks.conf -> ../base_rules/modsecurity_crs_41_sql_injection_attacks.conf lrwxrwxrwx 1 root root 49 Jun 26 14:07 modsecurity_crs_41_xss_attacks.conf -> ../base_rules/modsecurity_crs_41_xss_attacks.conf lrwxrwxrwx 1 root root 52 Jun 26 14:07 modsecurity_crs_42_tight_security.conf -> ../base_rules/modsecurity_crs_42_tight_security.conf lrwxrwxrwx 1 root root 45 Jun 26 14:07 modsecurity_crs_45_trojans.conf -> ../base_rules/modsecurity_crs_45_trojans.conf lrwxrwxrwx 1 root root 55 Jun 26 14:07 modsecurity_crs_47_common_exceptions.conf -> ../base_rules/modsecurity_crs_47_common_exceptions.conf lrwxrwxrwx 1 root root 62 Jun 26 14:07 modsecurity_crs_48_local_exceptions.conf.example -> ../base_rules/modsecurity_crs_48_local_exceptions.conf.example lrwxrwxrwx 1 root root 54 Jun 26 14:07 modsecurity_crs_49_inbound_blocking.conf -> ../base_rules/modsecurity_crs_49_inbound_blocking.conf lrwxrwxrwx 1 root root 46 Jun 26 14:07 modsecurity_crs_50_outbound.conf -> ../base_rules/modsecurity_crs_50_outbound.conf lrwxrwxrwx 1 root root 55 Jun 26 14:07 modsecurity_crs_59_outbound_blocking.conf -> ../base_rules/modsecurity_crs_59_outbound_blocking.conf lrwxrwxrwx 1 root root 49 Jun 26 14:07 modsecurity_crs_60_correlation.conf -> ../base_rules/modsecurity_crs_60_correlation.conf -rw-r--r-- 1 root root 5720 Jul 12 2013 README
You can include other rules found in other directories in the same way as well. Just remember to place all the rules you want activated in the activated_rules directory.
Now, let's head to the /etc/modsecurity/ directory to continue with the configuration.
$ cd /etc/modsecurity
Copy the recommended configuration file and name it modsecurity.conf
$ cp modsecurity.conf-recommended modsecurity.conf
Open the modsecurity.conf file and change the line that reads SecRuleEngine DetectionOnly to SecRuleEngine On . This changes ModSecurity from a passive monitoring mode to an active blocking mode. The rest of the default configurations that ship with the modsecurity-crs package on Ubuntu are more than sufficient. However, if you're interested in tweaking them, please refer to the ModSecurity Reference Manual. Here's the diff of the recommended file and the actual configuration file,
$ diff modsecurity.conf-recommended modsecurity.conf 7c7 < SecRuleEngine DetectionOnly --- > SecRuleEngine On
One final configuration file to tweak - the /etc/apache2/mods-available/security2.conf . Add the line IncludeOptional /usr/share/modsecurity-crs/activated_rules/*.conf to it and so you're configuration file would read,
<IfModule security2_module>
# Default Debian dir for modsecurity's persistent data
SecDataDir /var/cache/modsecurity
# Include all the *.conf files in /etc/modsecurity.
# Keeping your local configuration in that directory
# will allow for an easy upgrade of THIS file and
# make your life easier
IncludeOptional /etc/modsecurity/*.conf
IncludeOptional /usr/share/modsecurity-crs/activated_rules/*.conf
</IfModule>
Finally, we reload Apache for all the changes to take effect.
$ sudo service apache2 reload
Testing if it all works!
We can test if it all works, by sending some typical malicious requests to our Web Server and see if the requests are being blocked.
## XSS $ curl 'http://localhost/?q="><script>alert(1)</script>' <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>403 Forbidden</title> </head><body>
Forbidden
You don't have permission to access / on this server.
<address>Apache/2.4.7 (Ubuntu) Server at localhost Port 80</address> </body></html>
## SQLi $ curl "http://localhost/?q='1 OR 1=1" <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>403 Forbidden</title> </head><body>
Forbidden
You don't have permission to access / on this server.
<address>Apache/2.4.7 (Ubuntu) Server at localhost Port 80</address> </body></html>
And yay! It works! If you're curious to know more, you can look in the ModSecurity Audit Log file at /var/log/apache2/modsec_audit.log
And that's it! We now have a working LAMP Stack with ModSecurity and the ModSecurity CRS installed. If you want to customize your ModSecurity installation further and fine-tune it or write your own rules or disable some of them, please refer to the ModSecurity Reference Manual.
Note: In the above post, we just discussed how to install the LAMP Stack, ModSecurity WAF with the ModSecurity CRS on Ubuntu 16.04. Please do NOT assume your server is magically secured because of this. Please do not use this in production.