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-serverthat 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 OWASPproject 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 .confextension.

  $ 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 DetectionOnlyto 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-crspackage 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>
<h1>Forbidden</h1>
<p>You don't have permission to access /
on this server.</p>
<hr>
<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>
<h1>Forbidden</h1>
<p>You don't have permission to access /
on this server.</p>
<hr>
<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.

Ubuntu 16.04 LTS ModSecurity2.9.2 Install

서론

아파치에는 ModSecurity 라는 자체적인 Security Firewall 이 존재하는데 (GNU, GPL) 기반의 Open Source Firewall 이다. 기존에 ModSecurity2 자체는 Apache에 타겟팅하여 나타난 형태이기 때문에, 다른 서버를 쓴다면 ModSecurity3 을 install 해야한다. 하지만 ModSecurity3 는 아직 stable 버전이 존재하지 않는다. 

1. 의존 패키지 설치

해당 라이브러리들은 dependency 를 가지는 패키지들로써, 이들이 없다면 자체적으로 소스 컴파일이 되지 않는다.

Installation for Apache

Prerequisites

ModSecurity 2.x works only with Apache 2.0.x or higher

The ModSecurity team works hard to ensure that ModSecurity version 2.x will work with all versions of Apache 2.x and higher. If you find incompatibilities on any version (2.2.x, 2.4.x, or 2.6.x) please immediately inform the ModSecurity team

mod_uniqueid

Make sure you have mod_unique_id installed. mod_unique_id is packaged with Apache httpd.

libapr and libapr-util

libapr and libapr-util - http://apr.apache.org/

libpcre

http://www.pcre.org/

libxml2

http://xmlsoft.org/downloads.html

liblua v5.x.x

This library is optional and only needed if you will be using the new Lua engine - http://www.lua.org/download.html

Note : that ModSecurity requires the dynamic libraries. These are not built by default in the source distribution, so the binary distribution is recommended.

Note : libModSecurity (aka v3) is compatible with Lua 5.2+.

libcurl v7.15.1 or higher

If you will be using the ModSecurity Log Collector (mlogc) to send audit logs to a central repository, then you will also need the curl library.

http://curl.haxx.se/libcurl/

Note : Many have had issues with libcurl linked with the GnuTLS library for SSL/TLS support. It is recommended that the openssl library be used for SSL/TLS support in libcurl.

여기서 liblua 는 option적인 항목으로써 반드시 적어주지 않아도 된다.

위의 대부분의 라이브러리들은 httpd (Apache2)를 설치할때 자동으로 의존성에 의해서 같이 설치되긴 하나, 필자의 경우 소스컴파일로 각자 다른 디렉토리에 불러들였기 때문에, 직접 일일히 지정해줘야한다. 

만약 apache 가 /etc/apache 위에 설치되어있는 아주 편안한 상황이라면 굳이 이 메뉴얼을 쓰지 않았다.

2. mod_uniqueid 를 활성화한다. 

그렇다. ModSecurity2 는 2.9.2 가 마지막 버전이다. 링크를 따온다. 

4. 이제 거의 다왔다. 조금만 더 힘내자.

5. httpd.conf 파일 수정에 들어간다. 마지막 라운드다.

안녕하세요 기술지원팀 서정민입니다.

apache 2.x 버전대랑 openssl 설치시 에러 났을때 해결하는 방법을 포스팅하려고 합니다.
SSL 인증서 설정이 완료된 후 아파치를 재시작했을 때 다음과 같은 에러가 발생할 수 있습니다.

SSLSessionCache: ‘shmcb’ session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?).

이런 경우에는 아파치 환경설정 파일인 httpd.conf 파일을 열어서 수정해주면 오류를 해결할 수 있습니다.

#LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
vim 편집기로 httpd.conf 파일을 열었을 때 오류나는 모듈이 주석처리 되어 있는 것을 볼 수 있습니다.

LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
주석처리 되어 있는 것을 해제하고 파일을 저장합니다.
물론 /usr/local/apache/modules에 해당 모듈이 있어야 합니다.

다시 아파치를 재시작하면 오류가 사라지고 정상적으로 SSL이 적용되는 것을 확인할 수 있습니다.