dictionary attack defense
Does dovecot have any dictionary attack defenses yet? In the past I have had to implement defense from outside dovecot, but since dovecot is at the front lines and therefore is the first to know I'm hoping by now there is something we can set. For example, a limit on access failures per minut/hour/day or some such. If not why not?
a) I read about auth_failure_delay even before I posted my question and I could not figure out the one-line explanation in the dovecot wiki: "Number of seconds to delay before replying to failed authentications." It's delaying a reply. Does that mean the hacker can keep asking as fast as he wants? Is it per user or per IP?
b) I'm familiar with mail_max_userip_connections = x, but I'm not familiar with the time limit you mention.
On 10/21/2014 5:02 PM, Reindl Harald wrote:
Am 22.10.2014 um 05:59 schrieb Cliff Hayes:
it does not help him to ask fast he needs responses too and can't open endless connections parallel
b) I'm familiar with mail_max_userip_connections = x, but I'm not familiar with the time limit you mention.
iptables
0 0 REJECT tcp -- eth0 * !192.168.196/24 0.0.0.0/0 multiport dports 110,143,993,995 ctstate NEW recent: UPDATE seconds: 1800 hit_count: 100 name: dovecot2 side: source mask: 255.255.255.255 reject-with icmp-port-unreachable 4 256 REJECT tcp -- eth0 * !192.168.196/24 0.0.0.0/0 multiport dports 110,143,993,995 ctstate NEW recent: UPDATE seconds: 300 hit_count: 50 name: dovecot1 side: source mask: 2 55.255.255.255 reject-with icmp-port-unreachable 0 0 REJECT tcp -- eth0 * !192.168.196/24 0.0.0.0/0 multiport dports 25,465,587 ctstate NEW recent: UPDATE seconds: 1800 hit_count: 75 name: postfix2 side: source mask: 255.2 55.255.255 reject-with icmp-port-unreachable 9 448 REJECT tcp -- eth0 * !192.168.196/24 0.0.0.0/0 multiport dports 25,465,587 ctstate NEW recent: UPDATE seconds: 300 hit_count: 40 name: postfix1 side: source mask: 255.25 5.255.255 reject-with icmp-port-unreachable 0 0 DROP udp -- eth0 * !192.168.196/24 0.0.0.0/0 ctstate NEW recent: UPDATE seconds: 2 hit_count: 75 name: udpflood side: source mask: 255.255.255.255 0 0 DROP tcp -- eth0 * !192.168.196/24 0.0.0.0/0 ctstate NEW recent: UPDATE seconds: 2 hit_count: 75 name: DEFAULT side: source mask: 255.255.255.255 0 0 DROP tcp -- eth0 * !192.168.196/24 0.0.0.0/0 multiport dports 25,80,443,465,587 tcp flags:0x17/0x02 #conn src/32 > 75 0 0 DROP tcp -- eth0 * !192.168.196/24 0.0.0.0/0 multiport dports 25,80,443,465,587 tcp flags:0x17/0x02 #conn src/24 > 150 0 0 DROP tcp -- eth0 * !192.168.196/24 0.0.0.0/0 multiport dports 25,80,443,465,587 tcp flags:0x17/0x02 #conn src/16 > 175 0 0 DROP tcp -- eth0 * !192.168.196/24 0.0.0.0/0 multiport dports 25,80,443,465,587 tcp flags:0x17/0x02 #conn src/8 > 200
On Tue, 21 Oct 2014 16:28:46 -0500 Cliff Hayes <chayes@afo.net> wrote:
In my opinion, fail2ban is the right strategy to deal with a dictionary attack. Instead of adding a layer of attack detection and handling onto every outward facing service running on your server, you can centralize the detection and blocking at one place.
-- //Wegge
On Wed, 22 Oct 2014 01:12:02 +0200 Benny Pedersen <me@junc.eu> wrote:
Even if you have the luxury of not having users accessing their mail from all over the world, you still need to defend against a breach of safety on a legitimate users machine. Even in a strongly restricted corporate environment.
-- //Wegge
participants (4)
-
Anders Wegge Keller
-
Benny Pedersen
-
Cliff Hayes
-
Reindl Harald