Nerd Guide to WordPress Firewall Security

Learn about different firewalls to secure your WordPress sites (and servers).

This is standard sys-admin knowledge but many people don’t know the difference or how to implement. So unfortunately, gimmicky “security” companies get away with scaring naive users into buying services they don’t need.

So let’s learn about firewalls so you know exactly what you need, once and for all!

• How firewalls block malicious traffic.
• Network Firewall vs Web Application Firewall (WAF).
• Which firewalls you should have (or worry about).
• Best practices for firewalls.
• Should you pay for premium firewalls?

I demystify everything about firewalls in this guide.

What firewalls do – block unwanted connections

Firewalls are access control systems for your network.

• Passwords are like codes for a door lock.
• Firewalls are like gateguards deciding who even reaches the doorway (where the passcode is asked for).
• Firewalls are essentially a list of rules deciding who gets access or not.

As you can see, there are multiple forms of security to thwart hackers. First you use a firewall to decide which ports to allow traffic or not. And for the ports that are open, you might allow all traffic (like with public services, e.g. HTTP) or require password authentication (private services, SSH, FTP, POP3/SMTP).

Firewalls are basically your first form of security. They’re like the bouncer or doorguard deciding who gets into the club or not. Based on your rules. They decide which doors are allowed entry and to whom. Maybe the frontdoor is for everyone. Maybe the side doors are for internal staff only. Some doors allow traffic both ways. Others are exit only.

There are generally 2 ways that a hacker can cause problems through your network:

1. They breach your security and access your data. This can mean code injection and backdoors. Then stealing your data or changing your files.
2. They don’t breach your security but instead flood your system with fake connections, overwhelming server resources and causing an outage. This is also known as DOS or DDOS attack.

General practice would be to close off ports you don’t need so hackers cannot enter your server or use up system resources. The more common issue nowadays is not so much that hackers get in through your ports but that they hog all your server resources with fake connections or trying endless passwords.

Network firewalls – stateless & stateful

Network firewalls are the original traditional network “firewall”.

Anybody hearing the word firewall will immediately think of network firewall. They think of ports and IP’s. This kind of firewall is usually built into central networking devices, like servers and routers.

• Network firewalls control which ports are closed or open, and which IP’s can have access.
• Easy to understand. Easy to see which ports are open/closed, which IP’s allowed or blocked.
• Different services use different ports. For example SSH uses port 22, FTP uses port 21, HTTP uses 80, etc and etc. You decide which ones are open and to whom.
• As a real world analogy – think of a building (server) with many doors (ports). Your firewall is your security staff that controls access in and out of the building doors. You can also configure which people (IP’s) can enter through those doors. You can also configure some doors as entry-only, exit-only, or both.

However, the first generation network firewalls (stateless firewalls) had some drawbacks:

• They could only filter packets based on the ports they were passing through and IP’s being used.
• They couldn’t detect when packets faked their IP to gain entry (aka “IP spoofing”).
• Sure, their minimal processing made them very resource-efficient but also not very intelligent at stopping (disguised) bad traffic.
• Stateless firewalls are manually configured. Once ports (open/close) and IP’s (allow/deny) are set, it simply filters packets based on those rules. They can’t dynamically adapt rules to attacks on open ports.
• Stateless firewalls only do packet filtering at the network layer 3 on the OSI model. (In other words, it protects you from LAYER 3 DDOS attacks).

So to better identify and police packet flow, we use second generation network firewalls (stateful firewalls):

• Stateful firewalls can inspect the state of packets (open, closed, established, etc…thus the name “stateful”), and decide whether to allow or not based on the packet status. You can think of a lazy guard (stateless) that only glances at your ID versus one that verifies (stateful) to see that it’s real.
• Stateful firewalls also compare packets in context with other packets (e.g. how many connections made). It’s able to detect patterns and more adaptive at stopping bad traffic.
• It can also log traffic and recognize abuse patterns. It’s a much more full-featured monitoring system.
• Because it inspects packets more thoroughly, it also uses more resources and can be (in its own way) more susceptible to DDOS attacks.
• Because stateful firewalls depend a bit on software automation, it can also be tricked or taken advantage of by hackers understanding its security algorithm.
• Stateful firewalls are more complex to configure but can allow you to better secure open ports since it’s “smart” enough to detect/limit network abuse. For example, it allows everyone to access your web server ports 80/443 but will ban IP’s if they make more than 10 connections simultaneously.
• Stateful firewalls can do packet filtering and scan things on the transport layer 4 of the OSI model making it effective at stopping layer 3 and 4 DDOS attacks).

Web application firewalls

Network Firewall vs Web Application Firewall (WAF)

Yes, there are different kinds of firewalls! If anything, this is probably the most confusing part of understanding firewalls for people. Because every service and plugin out there is selling “firewall security” features. And undoubtably, many have no idea what the differences are. Once you recognize the distinction between network firewall vs web application firewall, everything gets so much easier.

So what’s a web application firewall (WAF)?

Unlike network firewalls which filter packets on the network layer 3 and transport layer 4….web application firewalls filter traffic on the application layer 7. (By layers, I’m referring to the OSI model.)

This allows it to filter traffic in a different manner and through different protocols. Let’s compare all 3.

• LAYER 3 firewall – filter packets based on what ports they’re passing through and what IP’s they’re coming to and from.
• LAYER 4 firewall – can filter based on layer 3 information but also connection status, how many connections are made, and whether this IP is on a ban list for recent abuse.
• LAYER 7 firewall – can filter based on layer 3 & 4 information but also things like user agent, what webpages or code is requested, and more.

Another way to think of it is that network firewalls are hardware firewalls and web application firewalls are software firewalls.

What makes web application firewalls special?

WAFs can filter higher-level information and block things that lower-level firewalls cannot.

For example…your network firewall can block SSH port 22 for all traffic but it has to leave HTTP port 80 and HTTPS port 443 open for all website visitors. And that means good and bad traffic can pass through those ports. And if all traffic is allowed through those open ports, you need another way of filtering them. That’s where WAFs come in.

• Remember… the lowest layer of the networking OSI model is the physical layer (layer 1). We just see a cable with electricity passing through it. We can’t tell which parts of that electricity is a hacker or not. We only know if the cable is connected and power is on.
• The middle layers (3 & 4) can differentiate those electric bits as network packets. But it can’t tell if those packets have bad or good info, or what code it’s executing. It can only see what IP’s they’re coming from and to, what ports they want to access, and connection state.
• The highest layer (7) is the application layer and can see exactly the code being run, what data is passed through. It can see and process data in the exact form as users (humans) see it…in readable text and numbers (not binary or electric flow).

Raw computing technology is somewhat at its core turning electric signals stored on mechanical devices into human written language and visual colors displayed on screen. Different-level firewalls intercept and filter this traffic on different layers.

Web application firewalls can filter by:

• User agent – suppose you want only web browsers to get through but not automated crawler bots.
• Code – preventing malicious code-executions. (Especially useful for hackers that already got in and now trying to run malware from your servers.)
• URL – can stop all or specific visitors from reaching certain urls.
• Referrer – can stop visitors from certain site.
• Authentication – force visitors to use passwords.
• And more – but I’m too lazy to list all.

Filtering in this manner allows you to more selectively weed out bad traffic passing through open ports. Hackers find it harder to get in now since so much more information is read from each visit request. It takes more work for them to mask their request and fool the firewall.

Drawbacks to web application firewalls.

Since WAF’s are so advanced, why don’t we use them as default and forget about the layer 3 & 4 firewalls?

1. They use much more resources since they process more information and operate on the highest layer of the OSI model (closest to the end user) and farthest from the server’s raw resources.
2. They only work on their specific web application. For example, a WAF firewall built for your website (HTTP/HTTPS) theoretically cannot secure for FTP or other services.

You can think of it as multi-layered bank security. They have low-level grunts working the door. Their job is just to make sure nobody who looks like trouble is getting in. Then next are the tellers who make you show ID or enter a pin before you can access any money. And then if you try to get access into the secured area behind the counter or into the vault, there’s much higher level of security (keys, fingerprint) and better-trained guards back there.

Having multiple layers of security is not only more secure but also much more resource-efficient. It doesn’t make sense to have your best security personnel checking everyone at the front door (and slowing traffic) when some of them might not even be there to withdraw money let alone rob the bank. Scrutinizing all traffic so closely like that would be a waste of resources. It’s better to filter layer by layer.

Server WAF vs Cloud WAF

It used to be that most small businesses or single server environments would install the firewall right on their server. It’s convenient to have to only one physical machine to manage. But as their traffic grows and so does their need for security, they may put this firewall function on a separate server.

This separated firewall function was run from a firewall proxy device (could be an actual server or a network switch with firewall capabilities) and sit right in front of their web-server. The advantages are having dedicated resources for handling firewalls. The disadvantage is extra cost, management, and speed impact (having more proxies will slow down request-processing times.)

The largest companies or those with extremely specialized demands may go with a paid “firewall service” from a big company like Sucuri. They are similar to the firewall proxy idea except only their server is not located locally next to your web server. They sit somewhere in the cloud but still between your visitors and your web server.

Cloud-based firewalls have numerous benefits over your local server-based firewalls:

• Firewalls are managed by a specialized security company.
• Can handle larger attacks (distributed across multiple servers), whereas your single server can only handle small ones.
• Benefit from a centralized database of attack signatures. Likely more updated.

Cloud-based firewalls allow you to have the best protection without having to do anything. No worry about setup, security, or complexity. Simply route your traffic through their servers and they do all the filtering for you. The obvious disadvantages are cost and potential slowdown in traffic.

Times have changed a lot now. Cloud-based security companies have dropped tremendously in price and improved their offerings to be more user-friendly. It seems everyone (even a tiny business) is better off using a free or low-cost cloud firewall than to buy or maintain their own firewall. Cloud-based security solutions also tend to have much nicer interfaces, show more data, and helpful visual reports. Whereas most server WAF look very plain and/or overly technical text-based tools.

Application-based WAF (aka PHP-based firewall)

Oh boy, more confusion coming up. As we all already know, you can run a web application firewall right from your server (or cloud server)….BUT…you can also run a WAF right on top of your frontend language (like PHP).

For example, most of you reading this guide are using a web application like WordPress which runs on PHP language. In WordPress, there are several security plugins that basically do this. They examine your PHP processes and filter accordingly. But beware…in case it needs to be said, a PHP-based WAF will definitely run slower than a server-based WAF.

Do keep in mind that an application-based firewalls only protect the application on which they’re installed. If you have many applications on one server, it’s probably easily to install a server-wide WAF so only have to manage rules from one place.

Importance of app-specific WAF

When it comes to network firewalls. You should add as many rules and block off as much as you can. The more you block, the safer and more performant your system.

With WAF, you can’t really think like that. Because WAF uses the application layer and WAF rules are loaded as software processes and use server resources. So with WAF, you want to be as efficient as possible. Having only the rules you need and nothing more, since WAF rules are run on every application request.

WAF’s will come with varying levels of protection. Some WAF’s are very general and have a loose set of rules to allow most applications to run on the server (without hindering or blocking their critical servers). Other WAF’s are more application-specific, such as being specific to WordPress and blocking only the vulnerable parts of WordPress (instead of account for all server apps in general). Using app-specific WAF gets you not only better security but also better performance.

Popular firewalls (and how they’re used)

Comparing different firewalls – their features and functions

What makes firewalls so confusing is that there are so many of them. It seems everywhere you turn in your server or application software, there are “firewall” features. It’s like everything is a firewall. Which ones are the firewalls you need?

It also doesn’t help when you have commercial software or services toting the same firewall security promises…”best bulletproof enterprise security”. Hahah and oh yeah, there’s software out there that act like firewalls but aren’t actually firewalls (in the traditional sense). How do we expect people to know which ones to use or not?!

Yeah, it’s confusing for sure and even more confusing to explain. But once you know how each firewall works…and what network layer they operate on, you will know:

• whether you already have it
• whether you need it
• how you should configure it

Built-in server firewalls (built-in iptables, firewalld, ufw):

These are basic (stateless) network firewalls that already come with your Linux operating system. Unless you’re a command-line junkie (and I assume you’re not if you’re reading this), you should never have to think about or deal with any of these.

• Iptables was traditionally built into every Linux server already.
• Settings were configurable through config file or iptables commands from CLI. But the commands were so complex…for example iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT.
• Thankfully, there are much friendlier firewall management tools from the command line.
• CentOS uses firewalld (example command: firewall-cmd --add-port=2222/tcp) and Ubuntu uses iptables (example command: sudo ufw allow 2222). Much friendlier, right?

GUI & control-panel firewalls (built into your control panel):

These are simply GUI interfaces for the existing underlying server firewalls. They are the user-friendly ones you’ve seen before. There is nothing to install. They’re already built-in and you simply use them as needed. Pre-configured (managed) hosting environments usually already have them set and don’t allow you to change them.

If you’re setting up a brand new server or installing firewall software from scratch, you should probably close down ports instead of leaving everything wide open.

• Typically has textboxes to enter port number, IP and IP ranges. Then a dropdown for ALLOW or DENY.
• Very simple to understand.
• Server-based control panels like cPanel/Plesk typically have a firewall management function where you can open and close ports, etc. This flexibility is nice for running different apps and services or having your own custom configs (e.g. changing FTP port and adjusting for that in firewall settings).
• Managed hosting or cloud-based control panels like Cloudways/GridPane typically have pre-configured firewalls for designated apps (like WordPress) and might not allow firewall management capability.

Stateful firewall software:

These are extra firewall software you can install onto your server, or enable through your control panel. They add extra functionality and very handy, but can also cause problems if not configured exactly for your applications and hosting environment.

Because of potential issues, they are usually disabled or not installed on new servers. You may find them already enabled and pre-configured for app-specific server-stacks (like GridPane or WordPress server install scripts on Digital Ocean).

You only have to install these if you feel your server is getting bombarded by many unwanted connections or authentication attempts. Be careful if installing them yourself. Their default settings might not account for your custom ports (like non-default SSH) and you could get locked out!

• ConfigServer Security & Firewall – I love using this one. Tons off features and very powerful but yes it can be an overwhelming amount of settings. I feel CSF is more common on CentOS and multiple-tenant environments.
• Fail2ban – not actually a firewall tool but it reads your logs and manages your firewall rules to ban IP’s with failed authentication attempts. I feel it’s more common on Ubuntu or servers with only single tenants.
• Control-panel based – your control panel may have its own stateful firewall functions already built-in. For example: WHM has “Host Access Control” and also “CPHulk” (similar to Fail2ban), and can also install and work with CSF as well.

Server-based WAF:

These are basically a set of pre-configured application firewall rules installed onto your server. You usually don’t have to configure much. They already have many rules to block most of the bad traffic out there. Although there are fancy premium services, most people try to find a FREE WAF that requires the least amount of configuration and most specific to their app.

• .htaccess – no, not a firewall but a configuration file used by Apache/LiteSpeed to execute or filter web requests in various ways. You can throw rules in there to block certain kinds and sources of requests. Some WAFs are actually based on this. You may have seen security guides or plugins that simply copy lines of code into your .htacess. Htaccess can be like a manual “WAF”.
• ModSecurity (aka “modsec”) – the most popular free open source WAF that’s available on most control panels (for Apache or LiteSpeed servers). The configurations are simple and mostly reliant on available rulesets by existing security organizations (mainly “OWASP” and “COMODO”). The drawbacks to ModSecurity is that some feel it’s slow and/or blocking legitimate traffic for certain applications.
• NGINX ModSecurity WAF – this is NGINX’s rewritten version of ModSecurity. Unfortunately only available with the paid version of NGINX (aka “NGINX Plus”). But I think some people also manually install ModSecurity on the free NGINX.
• NGINX App Protect WAF solution – I imagine it’s their proprietary WAF but I never tried. It also requires NGINX Plus.
• 6G/7G Firewall (by Jeff Star) – another popular WAF with .htaccess rules made specifically for WordPress. You may have seen his firewall integrated into existing panels or services (like GridPane). His WAF ruleset is very fast, protective, and perfectly made for WordPress.
• Others I didn’t list – there are many (often free) claiming to be fast and powerful. The more popular ones are usually updated often and/or associated with reputable security companies. Admins typically choose loose ones for mixed-environments or specialized ones for app-specific environments. YMMV.

Cloud-based WAF:

Cloud-based WAF’s are usually free or paid services by big name companies. They look nicer, user-friendly, and don’t require any configuration. Lots of fancy images of shields and locks to make you feel secure. Lots of visual reports, charts and graphs to show you all the attacks they prevented. And also a simple interface for you to create custom rules if ever needed.

• Cloudflare – great DNS proxy service (free and paid) and since your traffic is already passing through their proxies…you have the choice of enabling other features like CDN (for performance) or WAF (for security).
• Sucuri – big company specializing in security. You sign up for their service and pass your traffic through their servers which do all the traffic filtering for you.
• Others not listed – there are many other companies like these. Some are priced higher to target enterprise clients. Some are priced lower to attract everyday users. The main difference is in the level of rule customization, customer support, and accuracy of attack signature database. I suspect the cheap ones are simply integrating free WAF rulesets into their service instead of making their own rulesets.

Application-based WAF:

These are the security and firewall plugins you see for WordPress. Some are server-based and simply write WAF rules into your htaccess file. Others are php-based and execute the rules at the PHP level.

Htaccess is run at the server level and faster than PHP. And yes…if you simply copy the same rules into your htaccess, you won’t need the plugin *wink wink*. PHP-based WAF, I’m not a fan of since they’re slower…but they can be useful on NGINX servers or any hosting environment where you don’t have access to server configurations.

I also included some security plugins that are actually only a plugin integration for their cloud-based WAF. Just to help clarify things.

• WordFence – if I had to use an app-based WAF, it would be this one. I believe theirs would be most secure and performant.
• WebARX – this one seems solid too, seems like firewall is all they do.
• Sucuri – it’s not an app-based WAF, but they have a WordPress plugin that integrates with their cloud-based WAF.
• Ithemes Security – doesn’t even have a firewall function.
• BBQ, Blackhole, Banhammer – nice collection WAF protection tools from Jeff Starr (WordPress security expert). They’re block specific types of unwanted traffic and have granular control settings.
• Other ones I didn’t list – most are junk and/or I don’t believe they can be better than WordFence or WebARX.

Best practices for setting up firewalls

The most important question is…WHO will be managing your firewall?

A trained admin with lots of time dedicated to one server should plan differently from a busy business owner with many sites and servers. Generally there are 2 approaches…

Firewall strategy #1 – LOW MAINTENANCE PROACTIVE

This approach is the most common. Popular for end-users with low skills, or busy admins with limited time. It’s the classic “set it and forget it” type of attitude. You (or the webhost) install a bunch of generic firewall rulesets and go do something else. It works, secure enough, there might be some slight slowdowns or DDOS downtimes from time to time but you’ll be ok!

• Sign-up for managed webhosting service.
• DONE!

If there’s any extra need, they add a WordPress-specific WAF directly to websites. Some webhosts even already have one built-in!

• If you need suggestions, I like WordFence or Sucuri for paid services.
• If you want free WAF, Jeff Starr’s 6G/7G look promising or Cloudflare free WAF is ok, too.
• ModSecurity would be my last resort. I don’t feel their rulesets are WordPress-specific enough. Also, I always notice my sites run slower with modsec on.

Firewall strategy #2 – HIGH MAINTENANCE REACTIVE

This approach is for carefully-monitored servers with dedicated admins. Instead of piling on a bunch of generic rules and needlessly slowing down the server for the off-chance of an attack…we secure the server for the most common attacks…then sit back and wait for the big ones. If servers are ever noticeably affected, we jump in with adjustments and reconfigure site security in real-time.

• Shut down unused services.
• Close down or filter private ports more carefully.
• Set up stateful network firewalls (like CSF).
• Implement only common WAF rules and preferably at the server-level.
• Manually switch on cloud-based WAF during the worst attacks.

This approach requires more maintenance but is much more flexible and performant. You can have a super secure and super fast server that isn’t processing heavy WAF rules on each request. It better suits mixed environments and uncommon applications. And also likely to be more protective against DDOS attacks IMO.

The first line of defense is most efficiently served through software settings but the last line of defense is best served by a human. In the heat of a nightmare attack, a trained admin can react more intelligently to stop attacks whereas an automated firewall can only try to ride it out (basically, it does nothing).

The “reactive security” approach is more fun for server nerds who like to sit around banning and filtering attacks. As it seems….no matter how automated our technology in the 21st century, you eventually always need human intervention.

Firewall strategy #3 (unofficial) – LEARN ON THE JOB

Lol, because my site attracts many adventurous DIY’ers. The best way to learn is to follow some guides out there on how to configure different firewalls.

• Learn what firewalls come default with your Linux OS and server stack.
• Learn how to configure existing firewalls…from GUI and CLI.
• Learn how to uninstall and install other firewall tools.
• Learn common settings and configurations. (Careful when you mix! Conflicting rules can block legitimate traffic and slow down your server. The worst is when you inadvertently lock yourself out of the server.)
• Learn how to read logs, then adjust your firewalls to block hack attempts.
• Over time you’ll find your favorite firewall configurations for your use case.

NOTE: if you’re using shared hosting or managed hosting, you can only apply WAF as you won’t have access to the server for network firewalls. (A good host already handles that anyway.)

General questions about network firewalls:

“Do you really need a firewall?”

To clarify this question…I will say that all servers already have network firewalls installed. Whether they’re configured perfectly to your setup is another question. With managed hosting, firewalls are already installed and set for most common use scenarios. With brand new server setups, you have pre-installed firewalls but they’re probably not tweaked for your specific use.

Technically-speaking, if your passwords are difficult to guess and you don’t have any vulnerable software (themes/plugins)…then a firewall wouldn’t make it any harder for hackers to access your sensitive information. But that isn’t the case in reality.

There are always new vulnerabilities discovered in software and hackers are always probing and scanning for these “open windows” in your software that let them in without having to authenticate themselves.

But even if you didn’t have any vulnerabilities, hack attempts can still cause server outages because of their frequent attempts to guess your password or bombard your server with fake requests. In that case, you need the firewall for DDOS protection more so than unauthorized access protection.

But what if your server isn’t vulnerable and never targeted by hacks? Ok fine…that mythical scenario is the only one where you wouldn’t need a firewall at all. But let’s agree that isn’t good practice.

“Is having more firewalls better?”

• Having firewalls at different layers is more secure.
• Having multiple firewalls on the same layer is redundant and slow.
• I wouldn’t mix server-based WAF, php-based WAF, and cloud-based WAF together. That’s just asking for slow performance and not much extra security IMO. Do only one of those if you need.

“How do firewalls affect performance?”

• Network firewalls generally do not (negatively) affect server performance. They run on a lower network layer, do very little processing (“thinking”) and use very little resources.
• If anything, network firewalls help performance by closing down unnecessary ports and preventing bad traffic from harassing or drawing resources to those ports at all.
• WAF firewalls can noticeably slow down your server, because they uses resources to process firewall rules on every request regardless if it’s good or bad traffic.
• WAF firewalls, if not precisely-configured can actually make your server go down even faster during DDOS attacks since it uses more resources on each request.
• Any firewall proxy, whether cloud-based or local-based, will also slow down your site speed since requests have an extra proxy to jump through.
• The tradeoff with firewalls and performance is that a naked server is faster than a firewalled server. But under frequent attacks, a firewalled server is faster than a naked one since it’s preventing attacks from using up resources.

“How do I know which firewalls to use? Every new service says they’re the best.”

• Remember that firewalls are simply a list of rules. Nothing more, nothing less.
• You can pay a premium price for a list of rules. You can get it for free from the internet. Whether you manually copy them into your server config or install expensive software that does the same, the result is the same.
• Most of those paid firewall services or plugins usually rely on freely available (open-source) firewall rules anyway!
• If I had to choose, it’s always better to copy environment-specific or app-specific rules from an experienced admin using the same stack/apps as you than to go with a big fancy company that doesn’t specialize in your app-specific hosting environment. (Their rules won’t be as custom-targeted.)

“What makes a good firewall?”

• Stops bad traffic, while allowing good traffic. Bad firewalls don’t stop the bad traffic, or inadvertently block good traffic.
• Easy to use and understand. Not a labyrinth of overly technical settings that hinder you from maintaining it.
• Resource-efficient, doesn’t slow down your server.
• Less vulnerable to DDOS attacks. (Because what’s the point of a security system if it takes down your server during hacks?)
• If cloud-based, that it can handle giant DDOS attacks. Usually large DDOS attacks will easily overwhelm single servers.

“What does Johnny use?”

• I prefer ConfigServer Security & Firewall for my network firewall.
• For WAF…I use either nothing (yes nothing), WordPress security/firewall plugin like WordFence, or cloud-based WAF such as Cloudflare or Sucuri. It really depends on the hosting environment and type of apps used. When needed, I do like the Jeff Starr 7G firewall ruleset but with my own tweaks to it so it doesn’t block legitimate traffic/protocols.
• I may put a few manual .htaccess rules as needed, to block XMLRPC and other things.
• I don’t like ModSecurity for WAF (too slow and not app-specific). I use it only if I really have to.

Most importantly, I don’t treat my setup as an automated solution. We actively monitor our servers regularly and immediately jump in to scan logs and ban specific attacks without having to put on resource-heavy firewall rules or slowing our client servers in other ways.

Yes, it takes more work this way but personally very satisfying. We have a better pulse on trending security attacks, can identify and stop them quickly. This is more informative than using a blanket catch-all set of firewall rules intended for busy admins…or for low-maintenance server stacks.