Hello All!
I’ve started to work on a WAF for SPIP.
I have several high traffic site and I see a lot of automated attacks. Some against previous SPIP-CVEs, but others that are just sniffing for other CMS routes.
I have considered installing mod_security for Apache but this is cumbersome when running lots of SPIP sites in different circumstances. Plus, a WAF should be application specific, so and let through what needs to come though, and block the rest.
I know the ecran_securite already does a good job at blocking crawlers. The idea here is to block malicious hacker requests like /spip.php?get=<?php … or similar, clearly malicious requests.
The project is on the forge (for now only visible for logged in users):
https://git.spip.net/spip-contrib-extensions/waf
I will test these on several sites over the next weeks, to see if false positives come through.
Considerations:
- Normally a WAF is run BEFORE the traffic reaches the application.
– This can be feasible in the future by running the core functions of the plugin via PHP’s auto_prepend_file - But for now, I am directly calling the plugin’s main function via waf_options.php.
– At this point, SPIP is bootstrapped very minimally, this is very early in the request, where I don’t expect security issues.
The plugin checks the requests parameters for malicious patters. Every violation results in a strike.
On strike, the response is delayed, the user gets an « blocked » screen.
On 3 strikes, the user is blocked. Meaning, any other request (malicious or not), is also blocked. The user gets a « blocked » screen.
-
On the blocked screen, the user can unblock themselves.
-
After, the user can use the site normally. If another strike is counted, the user is blocked again. The block is lifted after a timeout, currently 24h.
-
BUT: If a max threshold is reached (e.g. 10 malicious requests in total, unblocked or not), the IP is permanently banned.
All the values can be adjusted via formulaire_config. The formulaire helps the user select the right HTTP header based on which to determine the IPs to block (important for users behind proxies). It also asks the user to whitelist their IP. Just in case…!
Anyhow, I will keep working on this on the forge, and hope it will reach a state where I’ll be able to deploy it on more SPIPs and eventually publish it.
Please feel free to have a look at the code on the forge and I’m happy if anyone wants to collaborate on this or is simply interested (or critical) in/of the approach.
Kind regards,
Urs