Interesting ideas. To make it possible to disable authentication from specific
locations, I suppose the easiest way would be to make the "smtp-auth-level"
option valid in a configuration directory. Then you could create directories
using the IP ranges or rDNS names of those countries and include the command
"smtp-auth-level=none". Right now "smtp-auth-level" can't be used that way, so
it would take a little work but shouldn't be impossible. I'll look into that.
As for still enforcing filters after authentication happens... that's more
problematic. Beyond the coding required, I'm having trouble imagining what the
configuration file would look like. Specifying one filter is enabled before
authentication but not after, while another filter is enabled both before and
after will get very confusing and error-prone. My gut tells me this kind of
feature would be much more trouble than it's worth.
This just occurred to me while I'm typing so I haven't tested it, but if you
want some filters to be always enforced whether the client authenticates or
not, what about running spamdyke twice? In your "run" or "smtp_psa" file, do
this:
spamdyke -f /etc/spamdyke.conf1 spamdyke -f /etc/spamdyke.conf2
/var/qmail/bin/qmail-smtpd
In the second spamdyke, set "smtp-auth-level" to "none" so authentication is
ignored. That configuration should also enable the filters that are always on
-- missing rDNS and so on. For the first spamdyke, set "smtp-auth-level" to
"always" (or "always-encrypted") and enable the filters that can be bypassed by
authentication. When a connection begins, the first spamdyke will offer and
process any authentication and disable any filters it has enabled. The second
spamdyke won't see the authentication (the first one will "consume" that input)
and will always enforce all of its filters. Your logs would get a little more
confusing because any rejections from the second spamdyke will be logged by the
first one as "DENIED_OTHER", but that's a minor problem. I think it would
accomplish what you're trying to do.
As for stopping a spammer from staying connected for hours on end, you should
be able to do that with the "connection-timeout-secs" option -- it enforces an
absolute time limit whether the connection is idle or not. Of course, it won't
stop the spammer from immediately reconnecting.
This may come as some surprise, but I've been finishing up the next version of
spamdyke and I hope to have it ready for release soon. This version will
include recipient validation, which is what's holding up the entire release --
testing that feature has required running 237000 test scripts, which takes a
very long time (especially when I find errors in the scripts and have to start
over). But I mention it because I've also added filters to the authentication
process to require an authenticated connection to send "from" the same address
or domain they used during authentication. That may help in your situation.
-- Sam Clippinger
On Apr 9, 2013, at 6:58 AM, Faris Raouf wrote:
>> I have a doubt:
>> If a user authenticates with SMTP auth. All filters are ignored?
>> If true, Why?
>>
> All filters other than the reply delay (earlytalker filter) are, as far as
> I'm aware, disabled when smtp authentication happens.
>
> But I was going to post about this too. I also would love the *option* to
> enable filters even if there's authentication. Sam, please can you consider
> this for a future version?
>
> I know it is unusual to want filtering enabled if there's authentication
> going on. Let me explain why I want it:
>
> We get 100s of connections from botnets (almost every connection is from a
> different IP, so fail2ban etc is no good) trying smtp auth dictionary
> attacks. They also use username/password combos from hacked third party
> sites (some of which made the news) where the password were not
> encrypted/didn't have salt.
>
> In order to reduce the impact of such attacks, I want to block smtp auth
> from certain countries - countries where we have no customers and therefore
> nobody should be authenticating from them. These countries are where the
> bulk of these attacks are coming from. Firewalling is not an option as there
> are too many IPs involved.
>
> I already have an local dnsbl set up with country-specific IP ranges loaded,
> which I already use in conjunction with mod_security on port 80 (and also
> via spamdyke on port 25 ). But I want to use this on port 587 too, even when
> someone authenticates correctly.
>
> Yes, I know, there is the potential for some issues -- what if a customer
> goes on vacation to a country that I've blocked. But in general I'm willing
> to risk this.
>
> I also want to block smtp auth if the connecting IP has no rDNS. I've been
> looking at my logs, and not one single legitimate auth in the past 30 days
> has come from an IP with no rDNS. But a reasonable proportion of botnet auth
> attempts have come from IPs with no rDNS.
>
> So basically that's why I would like the option to enable the usual dnsbl,
> rdns, etc etc filtering rules even if authentication happens.
>
> Ideally I'd like a special error message when there's a successful auth from
> a "filtered" IP. This would immediately tell me that the bad guys most
> likely have someone's real username/password combo, allowing me to change
> the password on that account before any damage has occurred.
>
> In addition, please can there also be a time limit option on successful smtp
> auth connections please? Last week I had a spammer who authenticated and
> stayed connected for two and a half hours sending spam after spam (not too
> much damage was done as I saw it happen and stopped the outgoing queue -- I
> just got confused and didn't think to kill the qmail-smtpd process manually.
> But that's another story).
>
>
>
>
> _______________________________________________
> spamdyke-users mailing list
> spamdyke-users@spamdyke.org
> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
