We use clustering on all of our servers that are strictly controlled by us and it works great! The power of clustering comes in particularly handy when a DDoS attack is underway as denies for an entire botnet get distributed around to all of our servers if only one gets hit first, preventing future attacks.
We'd love to do the same for servers that we manage for our clients, however they also have root access and we don't want to provide them with our cluster key.
I'm wondering if there's a way to set up a 'read-only' option purely for receiving IP denies but not being able to send denies that somehow doesn't use the cluster key. It would still require the IP of the sending server be listed in CLUSTER_RECV_FROM to ensure only authorized servers can send to it.
Or perhaps alternatively we have our cluster set up its own RBL and the servers where others have root access can be configured to use the internal RBL? Thoughts on ways to make something like this work?
-Jordan
Cluster read-only (w/o key) option
Re: Cluster read-only (w/o key) option
I've been working on something similar and my only solution so far was to have a master node, have everyone send their blocks to the master and then copy the blocks into a directory accessible from apache/nginx and serve them in the GLOBAL_DENY directive to the clients.
This way when the master node receives bans it will write it in csf.deny and serving that file in GLOBAL_DENY on the clients would effectively share the ban list.
Listing it in RBL bans could be possible but the way the RBL handles the text in file could be a problem (haven't tested it yet) but the option in RBL to limit the list would be ideal.
This way when the master node receives bans it will write it in csf.deny and serving that file in GLOBAL_DENY on the clients would effectively share the ban list.
Listing it in RBL bans could be possible but the way the RBL handles the text in file could be a problem (haven't tested it yet) but the option in RBL to limit the list would be ideal.