On 4/7/2008, Bill Cole (dovecot-20061108@billmail.scconsult.com) wrote:

...

Hey folks. One feature I'd really like to see in dovecot is the ability to point it at a database (with a configurable query) and have it allow or deny a connection based on looking up the source IP address in that database.

Is there any reason to do this at the application layer rather than the network layer for Dovecot?

I agree...

Fail2ban is perfect for this...

--

Best regards,

Charles

On Apr 7, 2008, at 4:58 PM, Bill Cole wrote:

...

Hey folks. One feature I'd really like to see in dovecot is the
ability to point it at a database (with a configurable query) and
have it allow or deny a connection based on looking up the source
IP address in that database.

I run Postfix, and I've got it configured to use a database
server for its smtpd_client_restrictions checks. Ideally I'd like
to point dovecot at the same database table. I have external
tools that maintain that table.

I was thinking of writing it myself, but I'm running 1.0.10; I'd
assume that any such modifications would need to be rewritten for
1.1. Then I got to thinking that such functionality would likely
be useful to people other than just me, so..

Thoughts?

Is there any reason to do this at the application layer rather than
the network layer for Dovecot?

Yup...see my last post on this topic.

Note that using smtpd_client_restrictions in Postfix *does not*
make it deny connections, it just makes it reject mail that is
offered on connections.

Yes, I'm aware of that (I'm pretty comfortable with Postfix) but I
appreciate your pointing it out. I'm sorry for my overly loose
description above.

It seems to me that for SMTP it is fairly normal to have IP space
that you'd want to reject mail from conditionally, such as
depending on whether/how the client authenticates or to allow mail
to standard role accounts. That sort of conditionality that is only
possible at the application layer makes an argument for
smtpd_client_restrictions in Postfix in some cases rather than
blocking at the network layer (i.e. a packet filter on the host of
an external firewall.)

Yup, I'm right with you there.

I don't see the same sort of cases for IMAP or POP where you'd want
to share a list of not-quite-totally-evil IP addresses with Postfix
or anything else, rather than just barring access completely.

...but here, I have seen a number of correlations (oddly) between
dictionary attacks against my IMAP ports, dictionary attacks against
SMTP authentication, and relay attempts. I have stuff in place that
adds, and later removes via a time-based expiration scheme, the
offending addresses to the database for smtpd_client_restrictions to
chop them. The ability to have that table apply to POP3 (for those
few still using it) and IMAP, as well as the SMTP authentication
requests, would be Awfully Nice here.

But as I explained in my other message on this topic, the big deal
is sharing that list across machines running dovecot in a pseudo-load- balanced configuration. All of my dynamic configuration information
(everything not in dovecot.conf) is stored in a centralized database,
with no local state other than currently-active connections. And if
one IMAP server is getting hammered on by a dictionary attack from a
zombie Windows machine, I want *all* of the servers to block (but
log!) those connections. I suppose I could probably hack together
some method of inserting statements in the access lists on the border
routers (Cisco IOS) but that's a bit dangerous for my taste.

It is possible to restrict specific users to login via specific
networks by using a custom PAM module, the allow_nets extra
authentication field, or a custom checkpassword script. You also
*might* be able to build a SQL query string using the %r variable
and some sort of conditional logic so that authentication from
'bad' IP's fails.

I could investigate that a bit...that is an interesting idea.

      -Dave

-- Dave McGuire Port Charlotte, FL