Re: RFE: dnsbl-support for dovecot

[Stephan Bosch]

On 6/17/2014 7:16 PM, Reindl Harald wrote:
> after having my own dnsbl feeded by a honeypot and even
> mod_security supports it for webservers i think dovecot
> sould support the same to prevent dictionary attacks from
> known bad hosts, in our case that blacklist is 100%
> trustable and blocks before SMTP-Auth while normal RBL's
> are after SASL
>
> i admit that i am not a C/C++-programmer, but i think
> doing the DNS request and in case it has a result block
> any login attemt should be not too complex
>
> setup a own honeypot and feed rbldnsd with the sources
> is quite easy and in case of a own, trustable RBL where
> no foreigners report somebody by mistake it's relieable
> and scales well over many machines and services as long
> services supporting it
>
> mod_security:
> http://blog.inliniac.net/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists/
>

There are some Dovecot developments in that area:

http://www.dovecot.org/talks/berlin-20140513.pptx.pdf (page 22)

Regards,

Stephan.

Re: RFE: dnsbl-support for dovecot

[Reindl Harald]

Am 17.06.2014 21:04, schrieb Jochen Bern:
> On -10.01.-28163 20:59, Reindl Harald wrote:
>> i admit that i am not a C/C++-programmer, but i think
>> doing the DNS request and in case it has a result block
>> any login attemt should be not too complex
> 
> Can't say that I actually ever *did* it, but according to the docs, the
> following should work:
> 
> 1. Use http://wiki2.dovecot.org/Authentication/MultipleDatabases to have
> login requests go through a
> http://wiki2.dovecot.org/AuthDatabase/CheckPassword first. Insert %r
> into the args to pass the rip to the external executable.
> 
> 2. Make that executable return failure if there is a matching DNSBL
> entry. (Note that in the case of a *dictionary* attack, offenders should
> appear in your resolver's local cache shortly, so you can set very low
> timeouts.) Configure the database as "result_failure = return-fail"
> (according to the docs, that should make dovecot generate a log entry)
> and "result_success = continue" (which will pass processing to the
> *actual* userdb/passdb).
> 
> 3. *Now* you can take advantage of having the lookup being done by an
> external executable, instead of (hard)code(d) within dovecot: Use the
> iptables "recent" module to (temporarily) block packets from SRCs on a
> local dynamic blacklist, and let the executable feed any matches it
> encounters to that list through the /proc/net interface as well.
> 
>>echo +addr >/proc/net/xt_recent/DEFAULT
>>   to add addr to the DEFAULT list

thanks - but all that workarounds is wwhat i want to avoid

simply because the gain is not high enough, the possible points
of failures are increased while having already a trustable DNSBL
and how DNSBL is working - any answer means listed - no response
or a NXDOMAIN means "don't block the client"

finally the way a RBL works also means in case of failures
you only have the DNS request timeout but no false positives



signature.asc
Description: OpenPGP digital signature

Re: RFE: dnsbl-support for dovecot

[Jochen Bern]

On -10.01.-28163 20:59, Reindl Harald wrote:
> i admit that i am not a C/C++-programmer, but i think
> doing the DNS request and in case it has a result block
> any login attemt should be not too complex

Can't say that I actually ever *did* it, but according to the docs, the
following should work:

1. Use http://wiki2.dovecot.org/Authentication/MultipleDatabases to have
login requests go through a
http://wiki2.dovecot.org/AuthDatabase/CheckPassword first. Insert %r
into the args to pass the rip to the external executable.

2. Make that executable return failure if there is a matching DNSBL
entry. (Note that in the case of a *dictionary* attack, offenders should
appear in your resolver's local cache shortly, so you can set very low
timeouts.) Configure the database as "result_failure = return-fail"
(according to the docs, that should make dovecot generate a log entry)
and "result_success = continue" (which will pass processing to the
*actual* userdb/passdb).

3. *Now* you can take advantage of having the lookup being done by an
external executable, instead of (hard)code(d) within dovecot: Use the
iptables "recent" module to (temporarily) block packets from SRCs on a
local dynamic blacklist, and let the executable feed any matches it
encounters to that list through the /proc/net interface as well.

>echo +addr >/proc/net/xt_recent/DEFAULT
>   to add addr to the DEFAULT list

Regards,
J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH 
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel

Re: RFE: dnsbl-support for dovecot

[Reindl Harald]

Am 17.06.2014 20:39, schrieb Giles Coochey:
> On 17/06/2014 19:32, Reindl Harald wrote:
>>
>> Am 17.06.2014 20:23, schrieb Giles Coochey:
>>> On 17/06/2014 18:56, Reindl Harald wrote:
 Am 17.06.2014 19:43, schrieb Giles Coochey:
> On 17/06/2014 18:16, Reindl Harald wrote:
>
>>> Iptables has a log option
>> please read again what you quoted
>>
>> iptables logs hardly contain the username
>> postfix rejections based on RBLs contain From/To
>>
>> a huge difference if it comes to analyze logs
>>
>> iptables logs are *packet based*
>>
> Yes, you wouldn't get more information from the (iptables) log other than 
> what can be discerned from the packet
> header & timestamp information.
> 
> You should probably examine the allow_nets code and see to what extent it can 
> be used or perhaps extended if
> necessary.
> 
> http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/AllowNets

to make it short: i know all that options
the question remains in the topic i started

if the answer from Timo is "no" that it's just no
nothing won't change the question



signature.asc
Description: OpenPGP digital signature

Re: RFE: dnsbl-support for dovecot

[Giles Coochey]

On 17/06/2014 19:32, Reindl Harald wrote:


Am 17.06.2014 20:23, schrieb Giles Coochey:

On 17/06/2014 18:56, Reindl Harald wrote:

Am 17.06.2014 19:43, schrieb Giles Coochey:

On 17/06/2014 18:16, Reindl Harald wrote:


Iptables has a log option

please read again what you quoted

iptables logs hardly contain the username
postfix rejections based on RBLs contain From/To

a huge difference if it comes to analyze logs

iptables logs are *packet based*

Yes, you wouldn't get more information from the (iptables) log other 
than what can be discerned from the packet header & timestamp information.


You should probably examine the allow_nets code and see to what extent 
it can be used or perhaps extended if necessary.


http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/AllowNets

--
Regards,

Giles Coochey, CCNP, CCNA, CCNAS
NetSecSpec Ltd
+44 (0) 8444 780677
+44 (0) 7983 877438
http://www.coochey.net
http://www.netsecspec.co.uk
gi...@coochey.net




smime.p7s
Description: S/MIME Cryptographic Signature

Re: RFE: dnsbl-support for dovecot

[Reindl Harald]

Am 17.06.2014 20:23, schrieb Giles Coochey:
> On 17/06/2014 18:56, Reindl Harald wrote:
>>
>> Am 17.06.2014 19:43, schrieb Giles Coochey:
>>> On 17/06/2014 18:16, Reindl Harald wrote:
 after having my own dnsbl feeded by a honeypot and even
 mod_security supports it for webservers i think dovecot
 sould support the same to prevent dictionary attacks from
 known bad hosts, in our case that blacklist is 100%
 trustable and blocks before SMTP-Auth while normal RBL's
 are after SASL

 i admit that i am not a C/C++-programmer, but i think
 doing the DNS request and in case it has a result block
 any login attemt should be not too complex

 setup a own honeypot and feed rbldnsd with the sources
 is quite easy and in case of a own, trustable RBL where
 no foreigners report somebody by mistake it's relieable
 and scales well over many machines and services as long
 services supporting it

 mod_security:
 http://blog.inliniac.net/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists/

>>> If you have the bllist as a file then you may as well drop with iptables 
>>> (in Linux) or ipfw (BSD).
>>>
>>> Use an IP tool for an IP block, not the application.
>>>
>>> Spamhaus project has a kind of script for this type of thing:
>>>
>>> http://www.spamhaus.org/faq/section/DROP%20FAQ
>>>
>>> I'm quite happy to use fail2ban, yes - dovecot has to handle a few failed 
>>> logins for each blocked IP, but it works
>>> for me and pretty much mitigates the attack
>> that's not the point, to achieve the same as with a RBL you
>> need to manipulate iptables on every machine - the RBL is
>> centrally for HTTP/SMTP and so it makes sense to use
>> it also for IMAP/POP3
> Or just do it on the firewall...

* you need to centralize it
* it don't fit my environment

>> additionally you have no log - thats bad with a RBL you have a
>> dedicated log containign much more data than source / target IP
>> and ports
> Iptables has a log option

please read again what you quoted

iptables logs hardly contain the username
postfix rejections based on RBLs contain From/To

a huge difference if it comes to analyze logs

iptables logs are *packet based*

>> also i don't want to have fail2ban on every machine, the point
>> of a RBL with a honeypot is that bad machines are blocked
>> for 7 days just beause they touch any unused IP and likely
>> before they even hit the production servers
> That's your personal choice

yes, and that's why i asked for RBL support and not fail2ban

>> iptables-rules are managed here also centralized over a lot
>> of machines and i really don't want to marry the honeypot with
>> the iptables
> That's specific to your deployment

yes, that's why i ask for a feature
i know fail2ban and like tools well

> I don't know how much use such a feature within dovecot would get as there 
> are quite a few specific tools that
> could accomplish pretty much the same goals of what you're looking for -  it 
> is just unfortunate that they don't
> fit in your own environment.

yes




signature.asc
Description: OpenPGP digital signature

Re: RFE: dnsbl-support for dovecot

[Giles Coochey]

On 17/06/2014 18:56, Reindl Harald wrote:


Am 17.06.2014 19:43, schrieb Giles Coochey:

On 17/06/2014 18:16, Reindl Harald wrote:

after having my own dnsbl feeded by a honeypot and even
mod_security supports it for webservers i think dovecot
sould support the same to prevent dictionary attacks from
known bad hosts, in our case that blacklist is 100%
trustable and blocks before SMTP-Auth while normal RBL's
are after SASL

i admit that i am not a C/C++-programmer, but i think
doing the DNS request and in case it has a result block
any login attemt should be not too complex

setup a own honeypot and feed rbldnsd with the sources
is quite easy and in case of a own, trustable RBL where
no foreigners report somebody by mistake it's relieable
and scales well over many machines and services as long
services supporting it

mod_security:
http://blog.inliniac.net/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists/


If you have the bllist as a file then you may as well drop with iptables (in 
Linux) or ipfw (BSD).

Use an IP tool for an IP block, not the application.

Spamhaus project has a kind of script for this type of thing:

http://www.spamhaus.org/faq/section/DROP%20FAQ

I'm quite happy to use fail2ban, yes - dovecot has to handle a few failed 
logins for each blocked IP, but it works
for me and pretty much mitigates the attack

that's not the point, to achieve the same as with a RBL you
need to manipulate iptables on every machine - the RBL is
centrally for HTTP/SMTP and so it makes sense to use
it also for IMAP/POP3

Or just do it on the firewall...

additionally you have no log - thats bad with a RBL you have a
dedicated log containign much more data than source / target IP
and ports

Iptables has a log option.

also i don't want to have fail2ban on every machine, the point
of a RBL with a honeypot is that bad machines are blocked
for 7 days just beause they touch any unused IP and likely
before they even hit the production servers

That's your personal choice.

iptables-rules are managed here also centralized over a lot
of machines and i really don't want to marry the honeypot with
the iptables


That's specific to your deployment.

I don't know how much use such a feature within dovecot would get as 
there are quite a few specific tools that could accomplish pretty much 
the same goals of what you're looking for -  it is just unfortunate that 
they don't fit in your own environment.


Perhaps others on the list would have opinions on it.

--
Regards,

Giles Coochey, CCNP, CCNA, CCNAS
NetSecSpec Ltd
+44 (0) 8444 780677
+44 (0) 7983 877438
http://www.coochey.net
http://www.netsecspec.co.uk
gi...@coochey.net




smime.p7s
Description: S/MIME Cryptographic Signature

Re: RFE: dnsbl-support for dovecot

[Reindl Harald]

Am 17.06.2014 19:43, schrieb Giles Coochey:
> On 17/06/2014 18:16, Reindl Harald wrote:
>> after having my own dnsbl feeded by a honeypot and even
>> mod_security supports it for webservers i think dovecot
>> sould support the same to prevent dictionary attacks from
>> known bad hosts, in our case that blacklist is 100%
>> trustable and blocks before SMTP-Auth while normal RBL's
>> are after SASL
>>
>> i admit that i am not a C/C++-programmer, but i think
>> doing the DNS request and in case it has a result block
>> any login attemt should be not too complex
>>
>> setup a own honeypot and feed rbldnsd with the sources
>> is quite easy and in case of a own, trustable RBL where
>> no foreigners report somebody by mistake it's relieable
>> and scales well over many machines and services as long
>> services supporting it
>>
>> mod_security:
>> http://blog.inliniac.net/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists/
>>
> If you have the bllist as a file then you may as well drop with iptables (in 
> Linux) or ipfw (BSD).
> 
> Use an IP tool for an IP block, not the application.
> 
> Spamhaus project has a kind of script for this type of thing:
> 
> http://www.spamhaus.org/faq/section/DROP%20FAQ
> 
> I'm quite happy to use fail2ban, yes - dovecot has to handle a few failed 
> logins for each blocked IP, but it works
> for me and pretty much mitigates the attack

that's not the point, to achieve the same as with a RBL you
need to manipulate iptables on every machine - the RBL is
centrally for HTTP/SMTP and so it makes sense to use
it also for IMAP/POP3

additionally you have no log - thats bad with a RBL you have a
dedicated log containign much more data than source / target IP
and ports

also i don't want to have fail2ban on every machine, the point
of a RBL with a honeypot is that bad machines are blocked
for 7 days just beause they touch any unused IP and likely
before they even hit the production servers

iptables-rules are managed here also centralized over a lot
of machines and i really don't want to marry the honeypot with
the iptables



signature.asc
Description: OpenPGP digital signature

Re: RFE: dnsbl-support for dovecot

[Giles Coochey]

On 17/06/2014 18:16, Reindl Harald wrote:

after having my own dnsbl feeded by a honeypot and even
mod_security supports it for webservers i think dovecot
sould support the same to prevent dictionary attacks from
known bad hosts, in our case that blacklist is 100%
trustable and blocks before SMTP-Auth while normal RBL's
are after SASL

i admit that i am not a C/C++-programmer, but i think
doing the DNS request and in case it has a result block
any login attemt should be not too complex

setup a own honeypot and feed rbldnsd with the sources
is quite easy and in case of a own, trustable RBL where
no foreigners report somebody by mistake it's relieable
and scales well over many machines and services as long
services supporting it

mod_security:
http://blog.inliniac.net/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists/

If you have the bllist as a file then you may as well drop with iptables 
(in Linux) or ipfw (BSD).


Use an IP tool for an IP block, not the application.

Spamhaus project has a kind of script for this type of thing:

http://www.spamhaus.org/faq/section/DROP%20FAQ

I'm quite happy to use fail2ban, yes - dovecot has to handle a few 
failed logins for each blocked IP, but it works for me and pretty much 
mitigates the attack.


--
Regards,

Giles Coochey, CCNP, CCNA, CCNAS
NetSecSpec Ltd
+44 (0) 8444 780677
+44 (0) 7983 877438
http://www.coochey.net
http://www.netsecspec.co.uk
gi...@coochey.net




smime.p7s
Description: S/MIME Cryptographic Signature

RFE: dnsbl-support for dovecot

[Reindl Harald]

after having my own dnsbl feeded by a honeypot and even
mod_security supports it for webservers i think dovecot
sould support the same to prevent dictionary attacks from
known bad hosts, in our case that blacklist is 100%
trustable and blocks before SMTP-Auth while normal RBL's
are after SASL

i admit that i am not a C/C++-programmer, but i think
doing the DNS request and in case it has a result block
any login attemt should be not too complex

setup a own honeypot and feed rbldnsd with the sources
is quite easy and in case of a own, trustable RBL where
no foreigners report somebody by mistake it's relieable
and scales well over many machines and services as long
services supporting it

mod_security:
http://blog.inliniac.net/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists/



signature.asc
Description: OpenPGP digital signature