WEBVTT 00:04.510 --> 00:10.270 In this lesson we'll see how to use engine X as bolt in rate limiting module to create what can be thought 00:10.270 --> 00:17.200 of as traffic lights for incoming connections rate limiting a survey implies rather than simply limiting 00:17.500 --> 00:22.010 managing incoming connections to the server for a specific reason. 00:22.180 --> 00:27.760 Common Reasons to rate limit a server can be to add an extra layer of security against potential brute 00:27.760 --> 00:34.750 force attacks preventing traffic spikes for a more reliable server or even to restrict users to a service 00:34.750 --> 00:39.620 based on the tier something like a download service for example. 00:39.730 --> 00:46.480 Now given the tools we have at our disposal which right now is the browser and Apache bench testing 00:46.510 --> 00:49.540 our servers rate limiting is going to be a bit difficult. 00:49.540 --> 00:55.390 What I'll do then to better demonstrate the outcome of connections to the server is install a new tool 00:55.420 --> 01:03.280 called seach siege is a lot like a Benge but focussed more on load testing a server rather than benchmarking 01:03.280 --> 01:03.770 it. 01:03.850 --> 01:07.180 A minor difference but one that will suit the needs of this lesson. 01:07.180 --> 01:11.680 Better to install siege then again using a P T. 01:11.680 --> 01:17.160 I'll say apt get install seach to install this on sentence. 01:17.160 --> 01:22.600 You'll most likely have to bolded from source which is simple enough and instructions can be found in 01:22.600 --> 01:26.430 the documentation is linked in the list and resources. 01:26.770 --> 01:29.650 That's all done so to check the tool is working. 01:29.650 --> 01:33.420 Let's run a test to the demo site for that image. 01:33.490 --> 01:33.980 Thumb. 01:33.990 --> 01:43.000 P In G I'll say C each with a V flag fall for both slogging are two meaning run. 01:43.000 --> 01:53.260 Two tests of C Five being five concurrent connections so five concurrent connections then another 5 01:53.500 --> 01:58.230 10 in total to fundos PRNG enter. 01:59.890 --> 02:08.620 And that finishes almost immediately resulting in 10 hits 5 times two and 10 of those being successful. 02:08.620 --> 02:10.980 So clearly no limiting here. 02:11.290 --> 02:17.110 This output now demonstrating why this tool is going to work better for these tests as any failed or 02:17.110 --> 02:20.150 rejected connections will also appear in red. 02:20.200 --> 02:21.900 Just a bit more visual. 02:22.190 --> 02:29.110 OK so with that done let's implement some basic rate limiting over to the configuration file where like 02:29.110 --> 02:36.300 the fast CGI cache and the SSL session cache will define a new memory zone in which to track connection 02:36.310 --> 02:37.480 limits. 02:37.480 --> 02:45.820 Limit request zone and the first argument to say here is again a key with which to identify how rate 02:45.820 --> 02:47.360 limiting as a blood. 02:47.560 --> 02:54.190 For example if we set this to the server underscore name variable rate limiting will apply to requests 02:54.490 --> 02:56.620 based on the server name. 02:56.620 --> 03:00.220 So essentially all requests to this IP. 03:00.280 --> 03:07.750 If however we made this key binary remote address which is the connecting IP address rate limiting will 03:07.750 --> 03:13.420 be applied per user as each connecting client will have a unique IP address. 03:13.420 --> 03:19.210 This per IP limit being perfect for something like rate limiting a log in form and thus preventing or 03:19.210 --> 03:22.460 rather severely slowing down a brute force attack. 03:22.780 --> 03:26.390 Or in our case I'll use request underscore. 03:26.410 --> 03:29.980 You are my meaning limit connections per request. 03:29.980 --> 03:30.840 You are right. 03:31.000 --> 03:34.400 Regardless of the client IP or anything else. 03:34.530 --> 03:41.110 If a certain you are high for example thumbed or PRNG receives more connection requests then the zone 03:41.170 --> 03:43.640 allows apply rate limiting. 03:44.020 --> 03:46.780 Next specify the zone name. 03:46.780 --> 03:54.700 I'll make this my zone calon and the size of the soane in memory 10 meg which will be plenty. 03:55.480 --> 03:59.290 With the last parameter being the all important rate. 03:59.440 --> 04:02.910 This takes a unique format of the number of requests. 04:02.950 --> 04:07.400 Say 60 are for 60 requests per. 04:07.570 --> 04:13.570 With a slash and an engine next time format like em or minutes. 04:13.570 --> 04:22.350 So this so now saying limit requests to the same request you are try to not exceed 60 requests per minute. 04:22.510 --> 04:23.660 Very importantly. 04:23.680 --> 04:30.490 Note that this does not mean the server can accept 60 requests at once and they no more for the remainder 04:30.490 --> 04:37.030 of that monnet But rather it sets a frequency of requests for this time frame. 04:37.060 --> 04:44.950 In other words this 60 requests per minute is the exact same thing as saying one request per second 04:45.570 --> 04:50.390 or three thousand six hundred requests per hour and so on. 04:50.440 --> 04:56.340 The point being that engine X will apply rate limits evenly thus preventing traffic spikes. 04:56.620 --> 05:01.550 Okay then with our zone created we can add it to either the server context. 05:01.690 --> 05:09.490 So apply to all requests on the server or inside a location context like this default location we have 05:09.490 --> 05:16.230 here meaning we can test it on that thumbed or PRNG image say limit underscore. 05:16.240 --> 05:20.870 Request zone equals my zone. 05:20.980 --> 05:23.200 The name of that zone we defined. 05:23.440 --> 05:32.350 Save this reload the configuration and run that same test again 5 concurrent requests for thumb of P 05:32.350 --> 05:34.330 in G twice. 05:34.330 --> 05:41.260 Enter and this time round we get only the very first request succeeding with the remaining 9 resulting 05:41.260 --> 05:45.490 in 5 0 3 errors which is service unavailable. 05:45.490 --> 05:46.750 So what happened here. 05:46.840 --> 05:51.880 The way rate limiting is applied is the server received five connections at once. 05:51.880 --> 05:59.170 Being the first batch of siege requests it responded to the first one of those five being that we're 05:59.170 --> 06:04.650 allowing one request per second and immediately rejected the remaining four. 06:04.660 --> 06:06.490 This obviously happened very quickly. 06:06.520 --> 06:12.940 Well with in a second meaning that when the second batch of requests were sent to the server that one 06:12.940 --> 06:19.690 second limit had not yet passed and all 5 requests of the next batch also got rejected. 06:19.720 --> 06:22.740 This being the default rate limiting behaviour. 06:22.750 --> 06:26.980 If we change this to perform two tests for a single connection. 06:27.040 --> 06:31.230 Same as now the one second has elapsed since the last test. 06:31.240 --> 06:33.420 But again the second request gets denied. 06:33.430 --> 06:36.000 As soon as that second limit starts again. 06:36.460 --> 06:41.110 Let's say however I manually perform a code request for thunder P and G. 06:41.170 --> 06:46.870 Again only checking the headers for the status code the second from the last test has elapsed. 06:46.870 --> 06:49.270 So enter it works. 06:49.270 --> 06:54.350 Wait more than one second and run this again another 200 success. 06:54.520 --> 06:57.110 More than a second and so on. 06:57.250 --> 07:04.510 So as long as these requests are sent more than 1 second apart no limiting as applied 1 second being 07:04.510 --> 07:08.560 extremely aggressive of course but for the sake of demonstrating. 07:08.900 --> 07:14.680 Okay so that's the default rate limiting behaviour but the zone directive does allow us to change this 07:14.680 --> 07:16.450 behaviour somewhat. 07:16.450 --> 07:24.130 The first will look at a city in a burst limit by specifying on the zone directive berst equals and 07:24.130 --> 07:24.700 a number. 07:24.730 --> 07:32.710 For example 5 they're supplying a burst allowance which will discuss in a second to all implementations 07:32.770 --> 07:34.370 of this zone. 07:34.390 --> 07:38.370 Alternatively then to better specify where we enable bursts. 07:38.470 --> 07:45.610 We can also specify this on the limit request implementation like so just a more granular way of configuring 07:45.610 --> 07:51.460 the rate limiting behaviour especially if you have multiple implementations of the same zone. 07:51.460 --> 07:54.420 So what does this burst allowance do. 07:54.490 --> 08:00.550 Basically setting a burst changes their default behaviour of immediately rejecting all requests exceeding 08:00.550 --> 08:08.200 the limit to allow this number of requests to also be fulfilled meaning our server will now accept one 08:08.380 --> 08:11.430 plus five connections within the second. 08:11.710 --> 08:16.510 It does not however mean that these five will be responded to immediately. 08:16.510 --> 08:22.570 Instead they will still have to adhere to the specified limit only that they will have to wait and won't 08:22.570 --> 08:23.380 be rejected. 08:23.380 --> 08:30.130 With that 5o 3 error we saw this then provides a bit of a buffer and rather than creating hard limits 08:30.340 --> 08:34.660 allows us to implement what would be considered more traffic shaping. 08:34.660 --> 08:40.300 So slowing down connections save this and reload the configuration. 08:41.040 --> 08:49.280 Run that first test again to Lot of 5 concurrent connections meaning we're within this six total allowed 08:49.680 --> 08:55.620 and this time the first is responded to immediately as before and the remaining four gets four fold 08:55.650 --> 08:57.330 one every second. 08:57.540 --> 09:00.120 So perfectly within the right limit. 09:00.120 --> 09:06.220 Then once the second batch of 5 connections is sen. we're still within the right limit and again the 09:06.220 --> 09:08.030 same shaping occurs. 09:08.160 --> 09:16.530 So all 10 requests is successful but taking nine point three seconds nearly one second per request only 09:16.530 --> 09:20.590 the first immediate request making up for those few milliseconds. 09:20.890 --> 09:25.680 So much more eloquent way of limiting say front in traffic for example. 09:27.000 --> 09:29.680 Change this test to exceed the burst however. 09:30.880 --> 09:35.630 Say 15 concurrent connections doing only one lot less time. 09:37.250 --> 09:43.760 And immediately the exceeded number of requests is rejected whilst the remainder gets throttled to one 09:43.760 --> 09:51.890 per second leaving us with the total six requests exceeding one blast burst and the remaining nine immediately 09:51.890 --> 09:57.370 receiving five or three errors as there were outside the raised limit and the allowed burst. 09:58.140 --> 10:01.110 The final modification we can apply to our limits zone. 10:01.200 --> 10:03.470 Is there no delay parameter. 10:03.600 --> 10:10.350 This only being applicable to a zone that already defines a burst value as well essentially no delay 10:10.350 --> 10:17.430 says serve the allowed burst requests as quickly as possible so not adhering to the right limit for 10:17.430 --> 10:18.710 the burst requests. 10:18.870 --> 10:25.230 But very importantly still maintain the applicable time limit for any new requests. 10:25.230 --> 10:31.050 Meaning if we performed six concurrent requests even though there will all be served as quickly as possible 10:31.500 --> 10:36.270 the right limit will still only reset at 1 request each second. 10:36.270 --> 10:43.030 This might sound a bit confusing so let me demonstrate again save and reload the configuration. 10:43.890 --> 10:47.640 I'll run a single test for the full six requests only. 10:47.880 --> 10:53.910 And as soon as that is done which should be very quick due to that no delay parameter I'll run the same 10:53.910 --> 10:55.130 one again. 10:55.440 --> 10:57.620 Enter again. 10:58.700 --> 10:59.860 And done. 11:00.020 --> 11:05.630 So what we can see here is how long it took me to run the sick and test then the first six requests 11:05.660 --> 11:13.250 were all responded to successfully as per our rate of 1 plus 5 the burst which all in all took nearly 11:13.250 --> 11:20.030 a full second and then it took me a little over another second to run the second test as we only managed 11:20.030 --> 11:27.980 to have 2 of those request responded to meaning the total limit of 1 request per second making six seconds 11:28.160 --> 11:35.060 was still active and the two seconds it took until the second Test ran freed up two requests in that 11:35.060 --> 11:39.720 limit which is what the no delay parameter allows us to do. 11:39.770 --> 11:45.980 That wraps up rate limiting and given these three variations of default burst and no delay. 11:45.980 --> 11:48.610 The limiting strategies are endless. 11:48.690 --> 11:50.800 If this got a bit confusing towards the end. 11:50.800 --> 11:57.110 Be sure to watch this listen again and also take a look at the excellent article linked in the resources.