WEBVTT 00:00:01.160 --> 00:00:03.260 [Autogenerated] So for this demo, 00:00:03.270 --> 00:00:06.960 I'm remotely connected to a Linux server which has the Apache web 00:00:06.960 --> 00:00:10.900 server installed and is configured as a reverse proxy. 00:00:10.910 --> 00:00:15.310 I've also compiled and installed mod security and the Apache connector. 00:00:15.830 --> 00:00:20.730 I generally recommend compiling versus using packaged versions of mod security. 00:00:20.920 --> 00:00:24.110 Since you can update the software much faster if there's a public 00:00:24.110 --> 00:00:27.680 vulnerability instead of waiting on the vendor to update the package, 00:00:28.350 --> 00:00:32.689 notice that I've also enabled mod security and created a rules file 00:00:32.700 --> 00:00:35.360 that currently points to the recommended mod security, 00:00:35.360 --> 00:00:37.110 default configuration file. 00:00:37.940 --> 00:00:40.130 We will take a look at this file a bit later. 00:00:41.190 --> 00:00:44.780 I left most of the defaults for this installation except for what I 00:00:44.780 --> 00:00:47.490 need to change for a reverse proxy configuration. 00:00:47.500 --> 00:00:50.730 Keep in mind that mod security on its own does not 00:00:50.730 --> 00:00:52.300 protect your web applications. 00:00:52.310 --> 00:00:55.920 You need to either add your own custom rules or use rules 00:00:55.920 --> 00:00:59.160 developed by a third party for this demo, 00:00:59.170 --> 00:01:03.280 I will show you how to leverage the open web application security project. 00:01:03.290 --> 00:01:05.650 Core rule set First, 00:01:05.660 --> 00:01:09.470 I'll use w get to download the current version of the rules and extract it. 00:01:10.330 --> 00:01:13.870 Then I will change to the extracted directory and rename a 00:01:13.870 --> 00:01:16.560 copy of the example Core rule set setup file. 00:01:17.370 --> 00:01:22.050 Now I'll open the setup file so you can see some of the configuration options. 00:01:22.860 --> 00:01:27.800 This main configuration file will allow you to control how the cRS will 00:01:27.800 --> 00:01:31.810 perform some of the features you can control with this file. 00:01:31.810 --> 00:01:36.420 Our mode of detection anomaly scoring severity levels, 00:01:36.430 --> 00:01:41.450 anomaly scoring threshold levels, paranoia levels and alert login. 00:01:42.450 --> 00:01:46.970 The mode of detection choices are traditional and anomaly scoring where 00:01:46.970 --> 00:01:49.820 the latter is the default and the more advanced system, 00:01:50.720 --> 00:01:53.860 The traditional mode, also known as self contained, 00:01:53.930 --> 00:01:59.620 is the most basic mode where each rule is used in isolation or self contained. 00:02:00.270 --> 00:02:03.780 There is no special logic or intelligence in this mode. 00:02:04.670 --> 00:02:07.550 If a real triggers it takes the designated action 00:02:07.560 --> 00:02:09.639 without regard for the previous events, 00:02:10.870 --> 00:02:15.490 anomaly scoring uses collaborative detection and delayed blocking. 00:02:15.590 --> 00:02:18.860 What that means is that when a rule matches, 00:02:18.870 --> 00:02:23.640 it also looks at the full context of the HTTP transaction that have happened, 00:02:23.680 --> 00:02:28.060 including previous rules that have matched and uses a scoring 00:02:28.060 --> 00:02:30.700 system to determine when to block the traffic. 00:02:31.260 --> 00:02:35.770 The scoring system uses severity levels that can be adjusted and 00:02:35.780 --> 00:02:38.730 eventually a scoring threshold will be hit. 00:02:38.740 --> 00:02:40.970 That triggers the blocking functionality. 00:02:41.750 --> 00:02:45.230 I should mention that there is a threshold level for inbound 00:02:45.230 --> 00:02:48.900 traffic and one for outbound traffic alert, 00:02:48.900 --> 00:02:52.010 logging control allows you to have mod security log its 00:02:52.020 --> 00:02:53.960 audit messages to the web servers, 00:02:53.970 --> 00:02:58.730 error log a separate mod security audit file or a combination of the two. 00:02:59.350 --> 00:03:02.550 I will believe in most of the settings in the default configuration. 00:03:02.560 --> 00:03:06.030 So you can see that it provides pretty good coverage out of box. 00:03:06.080 --> 00:03:09.720 Let's scroll down a bit further and we'll find that the default 00:03:09.720 --> 00:03:13.560 setting logs to a separate mod security audit file and the web 00:03:13.560 --> 00:03:18.120 server error log since the default mode is anomaly scoring the 00:03:18.120 --> 00:03:19.940 last instruction is passed. 00:03:20.580 --> 00:03:23.780 If we continue our journey down this configuration file, 00:03:23.790 --> 00:03:29.480 we arrive at the paranoia levels which range from one to the default level four. 00:03:30.270 --> 00:03:33.680 Each level will increase the number of rules that get enabled. 00:03:34.820 --> 00:03:37.900 You may be tempted to increase the paranoia level to four 00:03:37.910 --> 00:03:41.580 for the most protection but this can introduce false 00:03:41.580 --> 00:03:43.930 positives or service disruption. 00:03:43.970 --> 00:03:46.600 You need to test it in your environment and see 00:03:46.600 --> 00:03:48.250 what level is appropriate for you. 00:03:49.320 --> 00:03:52.310 This is where you would update the paranoia settings. 00:03:53.490 --> 00:03:58.310 This is where you update the severity levels and if 00:03:58.310 --> 00:04:01.580 you want to update the thresholds, this is where that is done. 00:04:02.900 --> 00:04:07.810 The last configuration I'll cover here is for application specific exclusions. 00:04:07.850 --> 00:04:10.790 For instance, if you have a wordpress site, 00:04:10.810 --> 00:04:15.430 the core rule set has already defined some exclusions that could benefit you 00:04:15.440 --> 00:04:18.380 and all you need to do is enable the appropriate settings. 00:04:19.470 --> 00:04:20.260 Okay, 00:04:20.410 --> 00:04:22.960 now let us look at the rules file we saw referenced 00:04:22.960 --> 00:04:24.480 at the beginning of this clip. 00:04:25.660 --> 00:04:29.130 This is a file I created to make the different mod security, 00:04:29.130 --> 00:04:32.960 configuration and rule files easier to manage. 00:04:32.970 --> 00:04:36.840 The first line I added immediately after installing mod security. 00:04:36.850 --> 00:04:41.070 Now I'm going to add the configuration lines necessary to allow 00:04:41.070 --> 00:04:43.810 mod security to utilize the core rule set. 00:04:44.510 --> 00:04:48.720 The first line is the setup file we viewed a few moments ago and the 00:04:48.720 --> 00:04:52.760 last line points to all the rules if you have engineers that can 00:04:52.760 --> 00:04:55.040 develop custom rules for your organization, 00:04:55.130 --> 00:04:56.770 then those can be placed below. 00:04:58.180 --> 00:05:02.850 The last thing we'll look at is changing mod security's default behavior. 00:05:02.860 --> 00:05:07.120 I'm going to open up mod securities configuration file at the top. 00:05:07.130 --> 00:05:09.500 There's a configuration directive that places mod 00:05:09.500 --> 00:05:13.380 security in a detection only mode We need to change this 00:05:13.380 --> 00:05:16.780 to on then restart the web server. 00:05:17.650 --> 00:05:19.720 Now we're ready to test mod security. 00:05:20.360 --> 00:05:24.350 I'm going to switch to a Cali box and run a curl command that will try 00:05:24.350 --> 00:05:28.590 to connect to a web app I have in the lab environment but remember all 00:05:28.590 --> 00:05:30.920 requests will go through the reverse proxy, 00:05:30.930 --> 00:05:34.240 which is the Apache web server using mod security. 00:05:34.860 --> 00:05:39.090 So for this curl command using dash S will clean up the 00:05:39.090 --> 00:05:41.880 output so we don't see the progress meters. 00:05:41.940 --> 00:05:46.070 The dash L will tell curl to follow the redirect from the proxy. 00:05:46.590 --> 00:05:51.210 I'm adding the slash bin slash bash portion to the URL to 00:05:51.210 --> 00:05:53.490 simulate a command injection attack. 00:05:54.640 --> 00:05:55.460 Okay. 00:05:55.480 --> 00:05:59.560 We can see from the output that we got a 403 as expected. 00:06:00.250 --> 00:06:03.670 Let's switch back to the proxy server and look at the audit log. 00:06:04.640 --> 00:06:05.120 Great. 00:06:05.430 --> 00:06:07.220 So things are working as expected.