Add second class of service for no-blacklisting

[powerdns]

Add second class of service for no-blacklisting

[sshipway]

We have done something similar; set up an RBL of exceptions, and then have the lua script check against this list to deactivate some of the rules - a bit like a whitelist. Unfortunately, there is no way to process this list before the blacklist takes effect, so if a mailbox gets onto the blacklist, then it cant log in from anywhere, even a whitelisted IP.

It would be good to be able to either have a whitelist (configurable to be processed either before or after the blacklist), or else have some way to make certain checks before the blacklist is processed.

[neilcook]

It would be good to be able to either have a whitelist (configurable to be processed either before or after the blacklist), or else have some way to make certain checks before the blacklist is processed.

This is actually slightly different from Dave’s request, which is actually regarding the standardised policy (which is not open-source, hence not part of this repo). I’ve thought before about a “built-in” (i.e. runs before native blacklisting) whitelist, although my main question there is always- if you have the concept of a whitelist for IPs, why not use that and just not add the IP to the blacklist in the first place? Neil

…

On 21 May 2018, at 02:18, Steve Shipway ***@***.***> wrote: We have done something similar; set up an RBL of exceptions, and then have the lua script check against this list to deactivate some of the rules - a bit like a whitelist. Unfortunately, there is no way to process this list before the blacklist takes effect, so if a mailbox gets onto the blacklist, then it cant log in from anywhere, even a whitelisted IP. It would be good to be able to either have a whitelist (configurable to be processed either before or after the blacklist), or else have some way to make certain checks before the blacklist is processed. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#203 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOWv2MqFGd97wikWMjS7ngaLcKyIoGO9ks5t0hXhgaJpZM4T4PhH>.

[davelugo]

I can't speak as to Steve's needs, but for us, it was (to rephrase my original post), to segment the IPs and usernames reported to wforce into three groups, having these classes of service when thresholds are exceeded:

. whitelisted - no detrimental policy applied to these
. subscriber - tarpit applied to these
. other - tarpit N times, then blacklist for T time applied to these

[sshipway]

We were considering implementing the class-of-service aspect by doing an LDAP lookup to determine a class, then simply switching rules off and on (or adjusting thresholds) in the lua code. Alternatively an RBL lookup on the IP could provide the CoS. I've not seen the 'standardised policy' so can't comment on that.

With regard to the whitelist/blacklist aspect, although I can see @neilcook 's point, I would like to have both so as to follow the more unix-y principle of giving users several ways of achieving their goals and let them choose which works best for their needs. You don't need to use all the options, but if they are there, then you run a better chance of being able to work with everyone.

[neilcook]

Steve, I'll add an issue for implementing a native whitelist

[neilcook]

We were considering implementing the class-of-service aspect by doing an LDAP lookup to
determine a class, then simply switching rules off and on (or adjusting thresholds) in the lua code.

Did you know you can use Dovecot to do this rather than do the LDAP lookup yourself from Lua? Anything that Dovecot can get from userdb as a variable can be passed to wforce.

Alternatively an RBL lookup on the IP could provide the CoS. I've not seen the 'standardised policy'
so can't comment on that.

The standardised policy is available by installing wforce-policy package if you want to take a look (it won't trash your existing config).

[neilcook]

FYI for the original request by Dave, I'm creating a new "IPGraylist". IPs on this list will never be rejected or blacklisted, only tarpitted. Tarpits will also count towards 24 hour totals.

[neilcook]

From the policy documentation:

IP graylist

The IP graylist consists of a list of IP addresses (these can be in CIDR format) that will be graylisted. Graylisted IPs will never be rejected or blacklisted, only tarpitted.

The number of seconds that graylisted IPs will be tarpitted for is configured using the "graylist_tarpit_secs" configuration field, e.g.

config.initConfig({graylist_tarpit_secs=5})
The IPs to be graylisted can be configured in one of two ways.

Firstly by passing a table containing the required IPs to the "loadGraylist()" function:

config.loadGraylist({ip_gl = { "127.0.0.1/8" }})
Secondly, they can be loaded from a file:

config.loadGraylistFromFile("graylist.lua")
The file must have the following format:

ip_gl = { "127.0.0.0/8", "192.168.0.0/16" }
If the graylist is changed while wforce is running, it can be reloaded simply by typing "config.loadGraylistFromFile(filename)" at the wforce console (or running the console as follows: wforce -c -e "config.loadGraylistFromFile(filename)".

Remember that wforce will change working directory to that of the specified configuration file, so filenames can be relative to that point.