10 Actions You Can Take to Secure Against Web Attacks

There's a huge array of tools, technologies and strategies you can use to protect your web assets. So what should you do? Here's our ten recommendations that we've collated from our many years of experience and expertise.

Use Bulletproof DNS Hosting

DNS is a critical but often overlooked component of your web assets.  For attackers who are looking to take you offline, an easy and convenient method is simply to knock out your authoritative DNS.  After-all, clients can’t use your web service if they can’t resolve its hostname.

Having a DNS provider who can withstand high-volume, denial-of-service attacks is necessary if you want to stay online.  Although, large scale DNS DDoS attacks have been on the order of terabits per second, even a fraction of this would be enough to overwhelm self-hosted solutions and most smaller providers.  If you are serious about your web security, the first step to consider is hosting your DNS with a provider that has the scale, scope and sophistication to shrug off DDoS attacks.

Partner with a Content Delivery Network (CDN)

CDNs are a critical component of a layered web defence.  While the availability, improved latency and reduced bandwidth consumption are certainly worthwhile, having your web assets front ended by a larger, more robust entity is strategically necessary.  Anything on the Internet will be subject to bad bots, script kiddies and ‘junk’ attacks.  As we’ll see in the next few items, you are wanting to get rid of these as early as possible so that you can focus on any serious, sophisticated threats.

I’m still surprised that many large organisations shy away from CDNs for no other reason than they’ve always hosted their web services themselves.  While there’s merit in having the resources to do this, it’s unnecessary to continue to go it alone and unfortunately, you’re placing your organisation at risk by doing so.

Enable DDoS Protection in the Cloud

This is where using a CDN really starts to pay off.  With a CDN, if you are the target of a DDoS attack, they are also the target of a DDoS attack, and they take it very seriously.  Most providers offer comprehensive DDoS protection, with many it comes as standard.  Additionally, many providers wave bandwidth charges that arise from volumetric DoS attacks (as they should, it was never real traffic), minimising the financial risks.  If you’re trying to fight off a DoS attack from your own boundaries, it’s not going to work. You’ll be swamped.

Deploy Bot Detection in the Cloud

If there’s one thing, I would recommend above all else it is this: Get yourself some good bot detection.  By volume, most attacks against your web applications will be from bots.  Detecting them and blocking them before they get to your perimeter is what you want to achieve.  Firstly, it’s not genuine traffic, so just get rid of it.  Secondly, most platforms will give you good visibility and reporting of exactly what kind of bots are attacking you and you can add this information to your threat intelligence.  Finally, it cleans up a lot of noise, ensuring that your defences to come provide you with high-fidelity alerts.  This is good, because you will absolutely need these to stop more sophisticated attackers.

Use Third-party Threat Intelligence

Just because we have scrubbed our traffic from bots doesn’t mean there are no bad actors remaining.  Having third-party threat feeds can help filter these out to further refine and clean up the traffic before it hits your web applications.  While there are some decent free options, paid subscriptions tend to be great value for money in terms of how much protection you get.

Give Risky Traffic a Hard Time

We’re starting to get to the point where potential traffic is no longer ‘definitely bad’ and we can’t just drop it outright.  However, there’s still plenty we can do to further reduce our risk.  There’s plenty of traffic that could be considered ‘risky’ and the specific nature of this will differ depending on your organisation.  Traffic from known VPN providers is one example, traffic from unusual geolocations is another consideration.  Rather than allow standard access for this traffic we can do things that would make the life of a potential attacker hard but barely impact a normal user.  Rate-limiting is a great option, both in terms of HTTP transactions and raw bandwidth.  This is also the type of traffic where false positives from aggressive security defences can be justified.  Dialling them up exclusively for risky traffic is going to pay off.

Baseline your metadata

Knowing what normal traffic looks like helps considerably to spot sophisticated threats.  Simple things like baselining transactions per second, geolocation of source addresses and browser types/versions are easy to do from your SIEM.  The more you know what ‘normal’ traffic looks like, the more your will be able to refine the parameters of ‘risky’ helping you improve your defences for this traffic.  All of this is fairly obvious, however, the reason why it is so often messed up is that organisations haven’t cleaned up their traffic before it gets to their perimeter.  If you’re baselining off a lot of junk, you can’t use the information effectively because it’s full of noise.

Before you WAF, consider your options

Okay, here we go.  Web Application Firewalls (WAF) are generally ineffective and you’re better directing your money and time to things that will give you better results.  There are two exceptions.  First, you have legacy, third-party apps that can’t or won’t be patched by a vendor in a timely manner.  Sadly, this is a much larger category than it should be and a WAF is a good option to ‘hot patch’ on-the-fly.  Second, your risk profile and depth of resources allows you to sink the necessary time and money into tuning your WAF ‘just right’. 

At this point it’s worth considering what kind of attacks will be sophisticated enough to make it through your previous defences, yet clumsy enough to trip over a WAF policy?  Not many.  I would argue that a better allocation of your time and money would be ensuring your vulnerability management practices are timely and efficient.  Attackers can’t use an exploit if it is patched, regardless of how sophisticated they may be.  If you have more resources left over, vulnerability scanning, penetration testing and code reviews will all yield more results than trying to tune a WAF.  Every web application violates HTTP to some degree and trying to confine this great big mess to a set of rules is folly.

If you must WAF, be strategic

But the fact remains that organisations do indeed have WAFs and intend on using them.  So how can we get the most out of them?  For starters, implement all the above steps so that whatever causes a violation is relatively ‘clean’ traffic.  This will give you much higher-fidelity alerts and help you tune out false-positives quicker.  Also covered earlier, feel free to ramp up the protection on that ‘risky’ traffic from before using your more aggressive policies.  Legitimate users going through a Russian VPN service will just have to log a service desk ticket when their request gets blocked.

For some organisations, the scope of ‘risky’ traffic is quite large, and only the clearly known bad can be dropped.  In these situations, WAFs can be a good way to augment threat intelligence.  For example, if a source address creates enough violations, add it to a dynamic block list at your perimeter for a ‘time-out’ period.  Be smart with your WAF and you’ll get returns.  If not, you’ll be drowning in alarm nonsense.    

Use honeypots to distract, detect and respond

If you do get breached, attackers will be seeking to pivot from your web tier to a juicer target.  Maybe it’s an unpatched Exchange server, maybe it’s Active Directory that’s not locked down, maybe it’s an insecure database.  So, why not give it to them?  Now we know exactly what they will attack next!

Honeypots deployed in your DMZ will give attackers an easy (but fake) target to hit and by the time they’ve worked it out, it will be too late.  Alarms from honeypots are super high-fidelity and if triggered, justify you going straight into incident response.  Assuming you respond appropriately, they give you the chance to save your organisation from some serious damage.  As such, honeypots should be strongly considered as part of your web defence-in-depth strategy.