On 03/03/2015 11:03 PM, Earl Killian wrote:> On 2015/3/2 10:03, Reindl Harald wrote: >> >> that is all nice >> >> but the main benefit of RBL's is always ignored: >> >> * centralized >> * no log parsing at all >> * honeypot data are "delivered" to any host >> * it's cheap >> * it's easy to maintain >> * it don't need any root privileges anywhere >> >> we have a small honeypot network with a couple of ipranges detecting >> mass port-scans and so on and this data are available *everywhere* >> >> so if some IP hits there it takes 60 seconds and any service >> supportings DNS blacklists can block them *even before* the bot hits >> the real mailserver at all >> > I would like to reiterate Reindl Harald's point above, since subsequent > discussion has gotten away from it. If Dovecot had DNS RBL support > similar to Postfix, I think quite a few people would use it, and thereby > defeat the scanners far more effectively than any other method. It is > good that other people are suggesting things that will work today, but > in terms of what new feature would be the best solution, I can't think > of one better than a DNS RBL.Please add this support to iptables instead of Dovecot. It's a waste of effort to code it into every application that listens on the network. Combined with "--ctstate NEW" and a chain for IMAP packets, it would be no less efficient.
Am 04.03.2015 um 20:12 schrieb Michael Orlitzky:> On 03/03/2015 11:03 PM, Earl Killian wrote: >> On 2015/3/2 10:03, Reindl Harald wrote: >>> >>> that is all nice >>> >>> but the main benefit of RBL's is always ignored: >>> >>> * centralized >>> * no log parsing at all >>> * honeypot data are "delivered" to any host >>> * it's cheap >>> * it's easy to maintain >>> * it don't need any root privileges anywhere >>> >>> we have a small honeypot network with a couple of ipranges detecting >>> mass port-scans and so on and this data are available *everywhere* >>> >>> so if some IP hits there it takes 60 seconds and any service >>> supportings DNS blacklists can block them *even before* the bot hits >>> the real mailserver at all >>> >> I would like to reiterate Reindl Harald's point above, since subsequent >> discussion has gotten away from it. If Dovecot had DNS RBL support >> similar to Postfix, I think quite a few people would use it, and thereby >> defeat the scanners far more effectively than any other method. It is >> good that other people are suggesting things that will work today, but >> in terms of what new feature would be the best solution, I can't think >> of one better than a DNS RBL. > > Please add this support to iptables instead of Dovecot. It's a waste of > effort to code it into every application that listens on the network. > > Combined with "--ctstate NEW" and a chain for IMAP packets, it would be > no less efficientyou don't want a dns client in a kernel module with full permissions and you will never convince any sane kernel developer doing that nor does it much help for the users on a different operating system dovecot is not linux only ____________________________________ > In the case of HTTP, IMAP, etc. things are not so easy. > Just think about NAT and CGN that don't matter if i blacklist a client because he starts a dictionary attack in SMTP i want it also bock on IMAP without use a dozen of different tools because teh via IMAP now catched account password will be used for send spam later when the SMTP RBL entry expires and frankly that 100% trustable RBL lives *before* "permit_sasl_authenticated" because it would be pointless anywhere else ordinary blacklists are score based on the MX, that is a complete differet machine with no business for POP3/IMAP or even outgoing mail -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20150304/9cad6e72/attachment.sig>
On 03/04/2015 02:12 PM, Michael Orlitzky wrote:>> I would like to reiterate Reindl Harald's point above, since subsequent >> discussion has gotten away from it. If Dovecot had DNS RBL support >> similar to Postfix, I think quite a few people would use it, and thereby >> defeat the scanners far more effectively than any other method. It is >> good that other people are suggesting things that will work today, but >> in terms of what new feature would be the best solution, I can't think >> of one better than a DNS RBL. > > Please add this support to iptables instead of Dovecot. It's a waste of > effort to code it into every application that listens on the network.<head explodes> Would you care to integrate it into IOS on my Cisco as well? There are things connected to the Internet that aren't PCs running Linux, you know. It may be hard to accept, but that's the way it is. -Dave -- Dave McGuire, AK4HZ/3 New Kensington, PA
Am 04.03.2015 um 21:03 schrieb Dave McGuire:> On 03/04/2015 02:12 PM, Michael Orlitzky wrote: >>> I would like to reiterate Reindl Harald's point above, since subsequent >>> discussion has gotten away from it. If Dovecot had DNS RBL support >>> similar to Postfix, I think quite a few people would use it, and thereby >>> defeat the scanners far more effectively than any other method. It is >>> good that other people are suggesting things that will work today, but >>> in terms of what new feature would be the best solution, I can't think >>> of one better than a DNS RBL. >> >> Please add this support to iptables instead of Dovecot. It's a waste of >> effort to code it into every application that listens on the network. > > <head explodes> > > Would you care to integrate it into IOS on my Cisco as well? > > There are things connected to the Internet that aren't PCs running > Linux, you know. It may be hard to accept, but that's the way it is. >I assume your dovecot runs on some kind of *nix so there should be some sort of netfilter available which you can put in front of your listening ports. It might be also an option to create some kind of "hooks" in dovecot that can be used to connect to a DNSBL checker - so configuration can happen outside of dovecot. Oliver -- Protect your environment - close windows and adopt a penguin! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4074 bytes Desc: S/MIME Cryptographic Signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20150304/30d8cefc/attachment.p7s>
> Am 04.03.2015 um 20:31 schrieb Reindl Harald <h.reindl at thelounge.net>: > > > In the case of HTTP, IMAP, etc. things are not so easy. > > Just think about NAT and CGN > > that don't matter > > if i blacklist a client because he starts a dictionary attack in SMTP i want it also bock on IMAP without use a dozen of different tools because teh via IMAP now catched account password will be used for send spam later when the SMTP RBL entry expiresThat?s the point why DNSBLs are good: You can use them for many different services at once. However, the idea is to block attackers before they are able to succeed identifying a valid login credential AND not to block your customers that expect a service that just works. This is a trade off. If both the attacker (or a malware infected computer etc.) and your valid user sit behind the same CGN gateway then it does matter and that scenario is not uncommon. Blocking a rude boy for some time from continuing with the attack will likely cause him to stop entirely, at least for a much longer time than you blocking the address. If he proceeds afterwards, then you have no other choice than blocking the IP for longer anyway and maybe tell your users you are suffering an attack. I am not against block lists. I just say their use should be justified as they may decrease overall service quality as well. There is another solution for auth based services: As soon as you detect a possible attack (# auth reqs > x etc.), keep the connection open, slow it down and just never let it succeed regardless of the credentials provided. This is done on a per-connection basis. No block list needed. Can be accomplished with fail2ban and iptables and therefore uses minimal server resources. Cheers, Felix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://dovecot.org/pipermail/dovecot/attachments/20150304/dbcadee6/attachment.sig>