| WFORCE(1) | WFORCE(1) |
wforce - daemon to detect brute-force login attempts and enforce other policies for logins
wforce [OPTION]...
wforce implements a simple HTTP server that accepts JSON formatted commands that report successful/unsuccessful logins and query whether a login should be allowed to proceed.
wforce can act as both a client and server. As a server it typically runs under systemd control, although it can also be run as a traditional daemon or in `interactive' mode. As a client, it connects to a wforce server and provides the same interactive commands.
wforce is scriptable in Lua, see the wforce.conf file for a simple example, and wforce.conf.example for a more sophisticated example. In fact all configuration is done using the Lua language, as wforce.conf is simply a Lua script.
wforce depends on the systems performing login authentication to integrate with it using the HTTP/JSON API. Example clients of the API include Dovecot and OX AppSuite.
wforce provides a simple clustering mechanism through the process of configuring “siblings” in wforce.conf. All modifications to the blacklists or the string stats DB (either from Lua or the REST API) will be replicated to all configured siblings. Replication uses the UDP protocol, so if siblings are not on a local subnet, you should ensure that any firewalls forward UDP on the configured ports.
The following commands can be run from the console when wforce is started with the -c option.
> makeKey()
setKey("CRK+jKBpzXNLmM2A4C7OpFCBxiwpYlreCWgGEAIKAQI=")
> stats()
40 reports, 8 allow-queries (% denies)
> siblings()
Address Send Successes Send Failures Rcv Successes Rcv Failures Note
127.0.0.1:4001 0 0 17 0
127.0.0.1:4002 0 0 0 0 Self
> showNamedReportSinks()
Name Address Successes Failures
trackalert 192.168.1.79:4501 18 0
trackalert 192.168.1.30:4501 19 0
elasticsearch 10.22.2.15:4501 18 0
elasticsearch 10.22.2.16:4501 19 0
> showReportSinks()
Address Successes Failures
192.168.1.79:4501 18 7
192.168.1.30:4501 25 0
> showStringStatsDB()
DB Name/Shards Repl? Win Size/No Max Size Cur Size Field Name Type
MyDB1/1 yes 1/15 524288 0 countLogins int
diffPasswords hll
MyDB2/10 no 600/6 5000 2093 diffIPs hll
> showACL()
127.0.0.0/8
10.0.0.0/8
100.64.0.0/10
169.254.0.0/16
192.168.0.0/16
172.16.0.0/12
::1/128
fc00::/7
fe80::/10
> showWebHooks()
ID Successes Failures URL Events
1 5 2 http://localhost:8080/webhook/ report allow
> showCustomWebHooks()
ID Name Successes Failures URL
1 mycustomhook 10 0 http://localhost:8080/webhook/regression
> showCustomEndpoints()
Custom Endpoint Send to Report Sink?
custom1 true
custom2 false
> showPerfStats()
WTW_0_1=2939287
WTW_1_10=9722
WTW_10_100=4
WTW_100_1000=0
WTW_Slow=0
WTR_0_1=2939229
WTR_1_10=2837
WTR_10_100=131
WTR_100_1000=0
WTR_Slow=0
> showCommandStats()
addBLEntry=0
allow=23942
delBLEntry=0
getBL=0
getDBStats=0
ping=300
report=19232
reset=24
stats=92
customEndpoint=2821
> showCustomStats()
custom1=0
custom2=8405
> reloadGeoIPDBs
reloadGeoIPDBs() successful
> showVersion()
wforce 1.2.0
The replication function of clustering means that as more servers are added to a cluster, incremental performance gains may be less each time, eventually possibly leading to performance degradation. This is because each server keeps a full copy of the stats DBs and the blacklists, and changes to those are replicated to all siblings. This can be mitigated by partitioning siblings into smaller clusters that do not share information, at the expense of missing potential abuse activity.
wforce.conf(5) wforce_webhook(5) wforce_api(7)
Open-Xchange.
| 2018 |