Welcome to this lesson on configuring the Web Application Firewall, or WAF.
The Web Application Firewall is one of the most important features of Admin Tools. It provides multiple layers of protection for your website and starts working as soon as Admin Tools is installed.
To access it, go to Security and select Web Application Firewall.
You'll see several options here, but in this lesson we'll concentrate on Configure WAF.
Open Configure WAF to begin.
The first section contains the basic protection features.
Here you'll find options that control administrator access, including restricting access by IP address or using a secret URL parameter. We'll cover these features in detail in the lesson on restricting access to Joomla, so we won't change them here.
Next is the Request Filtering section.
These settings are responsible for detecting and blocking many of the most common attacks against Joomla websites.
The default settings have been carefully chosen and, for most sites, I recommend leaving them exactly as they are.
If you'd like to learn more about any individual option, hover over its title to read the built-in help, or consult the Admin Tools documentation on the Akeeba website.
The next tab contains the Hardening options.
These provide additional security measures, but unless you understand exactly what each setting does, it's best to leave the defaults in place.
You'll also find the option to treat failed administrator logins as security exceptions.
By default this is enabled, and we'll look at security exceptions in more detail in a later lesson.
The Cloaking tab contains features that make it a little harder to identify information about your website.
One option allows you to remove or customise the generator meta tag.
Some administrators prefer not to advertise that they're running Joomla. While this won't stop a determined attacker, there's no harm in changing or removing the tag if you wish.
If you have a sense of humour you could even change it to say WordPress.
Another option prevents visitors from loading pages using the template parameter.
I recommend leaving this enabled, as it can prevent visitors from accessing layouts you didn't intend them to see.
You'll also find the 404 Shield.
This recognises requests for URLs that are commonly targeted by automated attacks. Instead of treating them as ordinary "Page Not Found" errors, Admin Tools records them as security exceptions so they can be monitored more effectively.
The next section covers Project Honeypot.
Project Honeypot is an external service that helps identify known sources of spam and abusive traffic.
If you decide to use it, simply create an account, obtain your API key, and enter it here. There's a link directly to the Project Honeypot website if you'd like to find out more.
Finally we come to the options for logging and automatically blocking repeat offenders.
Before enabling automatic bans, you may want to add trusted IP addresses or networks to the whitelist so they can never be blocked accidentally.
Admin Tools records every security exception.
Once the number of exceptions reaches the threshold you've configured, it can automatically block that IP address from accessing your site.
No security system is perfect. Attackers can change IP addresses, but automatic blocking is still very effective at stopping many automated attacks and persistent probing, so I recommend enabling it.
You can also choose whether to receive an email whenever an automatic ban is applied.
Personally, I'd like to know when that happens, so I'll enter my email address here.
Next, decide how many security exceptions should trigger a ban.
The default is three exceptions within one hour.
I generally prefer three exceptions within fifteen minutes, but you should choose values that suit your own site and the amount of legitimate traffic it receives.
You can also decide how long the ban should remain in place.
Some administrators prefer a temporary ban, while others choose a much longer period.
Finally, you can customise the message displayed to anyone whose IP address has been blocked.
The last section covers logging and notifications.
The first option records PHP errors.
This is primarily a troubleshooting feature rather than a security feature, although unexpected PHP errors can sometimes indicate that something unusual is happening.
If you enter an email address here you'll receive notifications whenever a PHP error occurs.
You can also choose to record the IP address used when a new user registers.
Some organisations need this information for auditing or compliance purposes. If you don't have a requirement for it, you can simply leave the default setting.
Admin Tools also logs all security exceptions.
I recommend leaving this enabled, as it provides valuable information if you ever need to investigate suspicious activity.
You can choose to receive an email for every security exception, but I generally leave this disabled.
Most security exceptions are simply failed automated attacks, and the volume of emails can quickly become overwhelming.
Instead, I prefer to receive notifications only when an IP address has actually been blocked.
Another useful option is administrator login notifications.
If you're the only administrator of the site, receiving an email whenever someone successfully logs in can provide an early warning if your account has been compromised.
On sites with multiple administrators, however, those notifications may become more of an annoyance than a benefit.
There's also an option to receive notifications for failed administrator login attempts.
Again, that's a personal choice, but on a busy site it can generate a large number of emails.
Once you're happy with your settings, click Save & Close.
Your changes take effect immediately, and your Web Application Firewall will continue protecting your website using the configuration you've chosen.
One thing I would change from your original is the advice about permanent IP bans. I wouldn't recommend "I don't ever want that person to reappear so I put in a really large number of days."
There are two reasons:
- Many ISPs recycle IP addresses, so an innocent visitor could inherit a previously banned IP months later.
- IPv6 privacy addresses and mobile networks mean IP addresses change frequently, so permanent bans are often less useful than they once were.
I'd instead say something like:
"I normally choose a ban period that's long enough to discourage repeated attacks without risking legitimate visitors being blocked in the future. A few days or a few weeks is often a sensible balance."
That advice is more technically accurate and less likely to cause support issues later.