WordPress Security on the Network Layer

In the last post, we covered different layers of the WordPress attack surface. Security should always be applied on multiple layers. Today, we will be covering what you can (and should) do on the network layer.

On the network layer, you can decide who or what can connect to your server and what can’t. This is the very first line of defense for any WordPress site. In this post, we’ll cover what should be done on the network, how to do it, and also what not to do.

What to mitigate on the network layer?

On the network layer, we must pass every request through the filter, so we need to have the server resources to do it or outsource this gatekeeping to someone else who has what it takes.

One of the things that is most commonly mitigated on the network layer is bot traffic and DDoS attacks. The entire goal of Distributed Denial of Service attacks is to flood your server with so many requests that it gives up.

Depending on how well is the website built, and how powerful is the server underneath – sometimes bot traffic can bring a site down as well. So the question ultimately is – do you have the resources to serve all that traffic, and do you even want to?

Network layer is the best place to unload the traffic load from your servers and filter out DDoS attacks and different bots such as scrapers, crawlers and spammers. It’s also the best place where to set up simple IP and page based restrictions.

It’s also a great place to force SSL/TLS encryption and make sure all traffic is passed through HTTPS.

What not to mitigate on the network layer?

What you can’t do well on network layer is everything that requires visibility into the server, application and end-user specifics such as their session and authentication levels.

For that reason, most of the network layer firewalls (including Cloudflare) are optimised for the lowest level of false-positives, because it has to work flawlessly on any application. Naturally, by reducing the false-positives rate on generic rule based firewalls, you also reduce their true detection rates.

You could create your own rules (which majority don’t) to make it more specific to your WordPress application, but that doesn’t remove the technical limitations due to the lack of visibility and understanding of what is happening under the hood of the website.

For that reason, it’s generally not worth it to try protect the WordPress applications from vulnerability exploitation attacks on the network layer. You’ll get better results elsewhere.

Doing it on your own

If you have full control over the server and network switches, then you can decide to take the more painful route and set it all up yourself. However, these systems require regular and very careful maintenance.

If you don’t have access to the networking devices, then all of the traffic will hit your server anyways, so eventually it still all boils down to the resources the server has available and the volume of the traffic.

Many computer networking companies such as Cisco and Fortinet sell network security devices, which are more powerful and give more control over the filters. But.. these devices come with a hefty price tag + you’d still need to set everything up by yourself.

Delegating it to a WAF provider

One of the most common (and cost effective) approaches is to delegate this to a provider such as Cloudflare, Fastly or Akamai. They have specifically optimised their infrastructure to deal with a very large amount of network traffic and by having many servers all around the world, they can distribute the load evenly. Let’s use Cloudflare as an example.

All you need to do is tell your domain registrar that the IP address of your server behind the domain is the one Cloudflare gives to you. Then tell Cloudflare the real IP address of your server.

Now all of the traffic that comes from your domain goes directly to Cloudflare and before Cloudflare let’s the traffic pass to the real server, it filters out what ever (and who ever) you want. If your domain is getting a lot of bot traffic or is under a DDoS attack, Cloudflares servers will be used to mitigate that.

Important! Make sure you fully delegate it though, it’s critically important that the server can only be accessed through Cloudflare, if the IP leaks and is accessible directly then it’s possible to 100% bypass it.

Conclusion

Network layer is the best place to filter out bots and other unwanted traffic. It also helps to reduce load on your servers. While network level firewalls such as Cloudflare can prevent some of the less complicated attacks, it’s technically limited to provide accurate protection for WordPress specific vulnerabilities.

Next week, let’s check out what we can do when the traffic hits the server.

Resources:

Setting up Cloudflare: https://www.youtube.com/watch?v=CiOXICbaBQk

Setting up some WordPress specific rules on Cloudflare: https://medium.com/@troyglancy/how-to-stop-brute-force-attacks-with-cloudflare-free-page-rules-2a7d56d40646