Commit 27e75423 authored by mattwire's avatar mattwire

Update readme, extract main function so it is testable

parent 9c26275e
......@@ -12,7 +12,24 @@ namespace Civi\Firewall;
class Firewall {
/**
* The main entry point that is called from hook_civicrm_config (the earliest point we can intercept via extension).
*/
public function run() {
if ($this->shouldThisRequestBeBlocked()) {
// Block them
http_response_code(403); // Forbidden
exit();
}
}
/**
* Perform the actual checks.
*
* @return bool
*/
public function shouldThisRequestBeBlocked() {
// @todo make these settings configurable.
// If there are more than COUNT triggers for this event within time interval then block
$interval = 'INTERVAL 2 HOUR';
$queryParams = [
......@@ -48,12 +65,7 @@ GROUP BY event_type
break;
}
}
if ($block) {
// Block them
http_response_code(403); // Forbidden
exit();
}
return $block;
}
/**
......
......@@ -2,6 +2,8 @@
This implements a simple firewall for CiviCRM that blocks by IP address in various scenarios.
This is currently a very simple automatic solution with no config and no configuration. It is expected that will change in the future.
The extension is licensed under [AGPL-3.0](LICENSE.txt).
### Scenarios
......@@ -39,7 +41,6 @@ if (class_exists('\Civi\Firewall\Firewall')) {
!!! Note: By checking if the class exists the firewall extension can be an optional dependency.
## Requirements
* PHP v7.1+
......@@ -54,3 +55,15 @@ See: https://docs.civicrm.org/sysadmin/en/latest/customize/extensions/#installin
## Administration
* Job.Firewall_cleanup: There is a scheduled job which cleans old entries from the `civicrm_firewall_ipaddress` table after 1 month.
## Future Development / Ideas
Thanks to @artfulrobot for testing and writing down some ideas for future development.
* Some forensic logging of bad things happening would be good. Who made the request, why was it bad, what was the content of the request, what was the user agent and the http method, were they logged in (!) - and as which user, is there any other relevant context? This way sites can use that data to be clevererer with setting limits/identifying traits of spammers.
* All rates/limits should be configurable (limit and period per event; how long logs are kept for).
* csrf tokens could include time limits and getter / checker could also take a param for the purpose - so one token doesn't work across different forms/purposes. Is there an advantage to tying in the IP to the token, too? I know you said this could come later.
* I like the idea that we could use it for more stuff, like thwarting other form submission spam.
* Also, should we log when we've denied someone something? I know there's the server logs with 403s. Just thinking that when I've been in this sort of situation, you can never get enough information. e.g. if it's baddies: need to study their behaviour; if it's goodies getting frustrated, good to understand what happened there, too, as it may help solve a supporter relations issue.
*Currently the records are kept in the database table for one month. So you can work out when an IP was blocked - but it does require a bit of calculation.*
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment