> Am 04.03.2015 um 20:31 schrieb Reindl Harald <h.rei...@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 expires
That’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
signature.asc
Description: Message signed with OpenPGP using GPGMail
