Making the Raspberry Pi Fast, Secure, and Available

For the holidays I picked up a Raspberry Pi (RPi) Zero, a $5 linux computer that runs roughly as fast as a computer from 5-10 years ago. I decided that the RPi would be a good candidate as a test server for using F5 solutions to make it fast, secure, and available. I ended up with a test setup where I sped up the performance of my test site running on my RPi by a factor of two and protected it from simple network attacks like a L4 SYN flood and L7 slowloris/slow read attacks.

Making it Fast

The Raspberry Pi Zero is not a fast computer with only 1 Ghz CPU and 1 GB of RAM. For my test I first installed Apache HTTPD with PHP and created a custom Apache config to limit the webserver to 5 simultaneous connections (more about why later). I installed a basic PHP site as my test site and created a Performance L4 virtual server (very basic reverse proxy running on port 8080) on my F5 BIG-IP.

My first test of my RPi resulted in lame results. The page took 7 seconds to load! Digging into the logs to look at the cause I found the following in my web server logs:

[mpm_prefork:error] [pid 24433] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

The cause of this error is that my web browser was opening 6 connections to the RPi, but I had configured it to only accept 5 connections.  This caused the 6th connection to stall out while it waited for one of the other 5 connections to complete. This was an artificial constraint that I put on the test, but I wanted to highlight the benefits of adding another server to handle the load.

Making it Available

Now that I knew that I had a resource limit I needed to load balance! My first thought was to buy another RPi, but an easier option was to run a second server on the same device. While I was at it I would add a third server for good measure.

The 3 load balanced servers resulted in the connections taking only 3 seconds to load, faster and more available!

Making it smaller

I could have stopped with just load balancing, but I thought it might be possible to make the site faster by caching static content and compressing text. I changed my BIG-IP configuration to create a Standard Virtual Server with a HTTP, Compression and Caching profile running on port 80. With these profiles I was able to reduce the page load from 620 KB of data to 126 KB. This resulted in faster connections over a simulated 3G connection.  The load time stayed around 3 seconds versus creeping up to 7 for the non-optimized connection when testing the simulated 3G connection.

Making it secure

A RPi is a very small device, not a lot of horse power to defend against a network attack. Most attacks focus on draining resources by keeping the system busy with spurious requests.  I launched multiple attacks with expected results (RPi test site became unavailable) against the Performance L4 virtual server. This was done in an isolated network environment (please don’t try this at home, unless you know what you’re doing…).

SYN flood

Overwhelmed the RPi with SYN requests.

Slowloris

Overwhelm Apache HTTPD with HTTP requests that do not complete.

Slow Read

Overwhelm Apache HTTP with HTTP requests that read the body of the request very slowly.

I then repeated the attacks pointing to the previously created Standard virtual server running on port 80 with the addition of a DOS protection profile enabled for application/network attacks as well as a basic ASM (web app firewall) policy for good measure.

Repeating the test

The slowloris attack was mitigated with all the connections piling up on the BIG-IP and not reaching the RPi. To clear out the idle connections I applied a small iRule to reap idle connections.

The SYN flood attack was detected and mitigated by the DOS network profile.

A similar result for the Slow Read attack with the DOS application profile mitigating the attack. One of the mitigations that can be applied for Slow Read attacks is to send a CAPTCHA response. Automated attacks are unable to process the CAPTCHA while legitimate users can still connect (in the cases where users share the same external IP address). The CAPTCHA challenge will only appear when the BIG-IP detects that the site is under duress.

Other types of attacks were also caught by the ASM profile (for example some attacks were categorized as not being RFC compliant and got dropped on the floor before they could reach the RPi).

Easy as Pi?

In production you may not be using a RPi to host your services, but hopefully you enjoyed this look at how you can use F5 solutions to make your applications fast, secure, and available whether they’re on an RPi, on premises, or in the cloud.