In the introductory post in the Quick Wins with Website Protection Services series, we described the key attack vectors that usually result in pwnage of your site and possibly data theft, or an availability issue with your site falling down and not being able to get back up. Since this series is all about Quick Wins, we aren’t going to belabor the build-up, rather let’s jump right in and talk about how to address these issues.

Application Defense

As we mentioned in the Managing WAF paper, it’s not easy to keep a WAF operating effectively, which involves lots of patching and rule updates based on new attacks and tuning the rules to your specific application. Doing nothing isn’t an option, given the fact that attackers use your site as the path of least resistance to gain a foothold in your environment. One of the advantages of front-ending your website with a website protection service (WPS) is to take advantage of a capability we’ll call WAF Lite.

Now WAF Lite is first and foremost — simple. You don’t want to spend a lot of time configuring or tuning the application defense. The key to getting a Quick Win is to minimize required customization, while providing adequate coverage against the most likely attacks. You want it to just work and block the stuff that’s pretty obviously an attack. You know, stuff like XSS, SQLi, and the other stuff that makes the OWASP Top 10 list. These are pretty standard attack types and it’s not brain surgery to build rules to block them. It’s amazing that everyone doesn’t have this kind of simple defense implemented.

Out of one side of our mouths we talk about the need for simplicity. But we also need the ability to customize and/or tune the rules when you need to, which shouldn’t be that often. It’s kind of like having a basic tab, which gives you a few check boxes to configure and needs to be within the capabilities of the unsophisticated admin. That’s what you should be using most of the time. But when you need it, or when you enlist expert help, you’d like to have an advanced tab to give you lots of knobs and granular controls.

Although a WPS can be very effective against technical attacks, these services are not going to do anything to protect against a logic error on the part of your application. If your application or search engine or shopping cart can be gamed using legitimate application functions, no security service (or dedicated WAF, for that matter) can do anything about that. So parking your sites behind a WPS doesn’t mean you don’t have to do QA testing and have smart penetration tester types trying to expose potential exploits. OK, we’ll end the disclaimer there.

We’re talking about service offerings in this series, but that doesn’t mean you can’t accomplish all of these goals using on-premise equipment and managing the devices yourself. In fact, that’s how stuff got done before the fancy cloud-everything mentality started to permeate through the technology world. But given the fact that we’re trying to do things quickly, a service gives you the opportunity to deploy within hours and not require significant burn-in and tuning to bring the capabilities online.

Platform Defense

Despite the application layer being the primary target for attacks on your website (since it’s the lowest hanging fruit for attackers) that doesn’t mean you don’t have to pay attention to attacks on your technology stack. We delved a bit into some of the application denial of service (DoS) attacks targeting the building blocks of your application, like Apache Killer and Slowloris. A WPS can help deal with this class of attacks by implementing rate controls on the requests hitting your site, amongst other application defenses.

Given that search engines never forget and some data you don’t want in the great Googly-moogly index, it pays to control the pages available for crawling by the search bots. You can configure this using a robots.txt file, but not every search engine plays nice. And some will jump right to the disallowed sections, since that’s where the good stuff is, right? Being able to block automated requests and other search bots via the WPS can keep these pages off the search engines.

You’ll also want to restrict access to unauthorized areas of your site (and not just from the search engines discussed above). This could be pages like the control panel, sensitive non-public pages, or your staging environment where you test feature upgrades and new designs. Unauthorized pages could also be back doors left by attackers to facilitate getting back into your environment. You also want to be able to block nuisance traffic, like comment spammers and email harvesters. These folks don’t cause a lot of damage, but are a pain in the rear and if you can get rid of them without any incremental effort, it’s all good.

A WPS can lock down not only where a visitor goes, but also where they come from. For some of those sensitive pages you may want to enforce those pages can only be accessed by someone on the corporate network (either directly or virtually via a VPN). So the WPS can block access to those pages unless the originating IP is on the authorized list. Yes, this (and most other controls) can be spoofed and gamed, but it’s really about reducing your attack surface.

Availability Defense

We can forget about keeping the site up and taking requests, and a WPS can help with this function in a number of ways. First of all, a WPS provider has bigger pipes than you. In most cases, a lot bigger that gives them the ability absorb a DDoS without disruption or even impacting performance. You can’t say the same. Of course, be wary of bandwidth based pricing, since a volumetric attack won’t just hammer your site, but also your wallet. At some point, if the WPS provider has enough customers you can pretty much guarantee at least one of their clients is under a DDoS at any given time, so they spend a bunch of money on anti-DoS equipment and extra bandwidth — so you don’t have to.

Another benefit of implementing a WPS in front of your site is to obscure the coordinates (IP addresses) of your site. This prevents an attacker from by bypassing your WAF or other proxy designed to protect the site. If they don’t know the IP address, they can’t attack the directly. This approach allows you to restrict inbound connections on your site to trusted IP addresses within the WPS. Thus random folks can’t connect to the site without going through the WPS. Similarly, the WPS can be configured to block protocols like SSH, FTP and telnet – which should only be used by internal people (and locked down to your internal network, as described above) and only in limited situations.

As you can see, using a WPS reduces a lot of the applicable attack surface of your websites. Not all, but a lot. Since this is a Quick Wins series, unless you can deploy and turn up the service quickly, all for naught. So we’ll wrap up the series next week by looking at the deployment decisions you’ll need to make, implementation process you’ll undergo, and finally the ongoing management responsibilities to keep your sites protected, available and operational.