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?
Am 21.10.2014 um 23:28 schrieb Cliff Hayes:
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?
no - but you can set "auth_failure_delay = 5" and limit new connections per IP to something around 40 per 5 minutes and 100 per 30 minutes which stops many of them or at least limit the amount of tries dramatically
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 21.10.2014 um 23:28 schrieb Cliff Hayes:
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?
no - but you can set "auth_failure_delay = 5" and limit new connections per IP to something around 40 per 5 minutes and 100 per 30 minutes which stops many of them or at least limit the amount of tries dramatically
Am 22.10.2014 um 05:59 schrieb Cliff Hayes:
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?
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 10/21/2014 5:02 PM, Reindl Harald wrote:
Am 21.10.2014 um 23:28 schrieb Cliff Hayes:
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?
no - but you can set "auth_failure_delay = 5" and limit new connections per IP to something around 40 per 5 minutes and 100 per 30 minutes which stops many of them or at least limit the amount of tries dramatically
Good idea! Thanks!
On 10/22/2014 3:55 AM, Reindl Harald wrote:
Am 22.10.2014 um 05:59 schrieb Cliff Hayes:
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?
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/240.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 10/21/2014 5:02 PM, Reindl Harald wrote:
Am 21.10.2014 um 23:28 schrieb Cliff Hayes:
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?
no - but you can set "auth_failure_delay = 5" and limit new connections per IP to something around 40 per 5 minutes and 100 per 30 minutes which stops many of them or at least limit the amount of tries dramatically
On Tue, 21 Oct 2014 16:28:46 -0500 Cliff Hayes chayes@afo.net wrote:
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?
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 October 22, 2014 12:57:34 AM Anders Wegge Keller wegge@wegge.dk wrote:
On Tue, 21 Oct 2014 16:28:46 -0500 Cliff Hayes chayes@afo.net wrote:
Does dovecot have any dictionary attack defenses yet? In my opinion, fail2ban is the right strategy to deal with a dictionary attack.
Fokus should just be reversed to allow ip ranges not deny ip ranges
On Wed, 22 Oct 2014 01:12:02 +0200 Benny Pedersen me@junc.eu wrote:
On October 22, 2014 12:57:34 AM Anders Wegge Keller wegge@wegge.dk wrote:
On Tue, 21 Oct 2014 16:28:46 -0500 Cliff Hayes chayes@afo.net wrote:
Does dovecot have any dictionary attack defenses yet? In my opinion, fail2ban is the right strategy to deal with a dictionary attack.
Fokus should just be reversed to allow ip ranges not deny ip ranges
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
Am 22.10.2014 um 01:12 schrieb Benny Pedersen:
On October 22, 2014 12:57:34 AM Anders Wegge Keller wegge@wegge.dk wrote:
On Tue, 21 Oct 2014 16:28:46 -0500 Cliff Hayes chayes@afo.net wrote:
Does dovecot have any dictionary attack defenses yet? In my opinion, fail2ban is the right strategy to deal with a dictionary attack.
Fokus should just be reversed to allow ip ranges not deny ip ranges
*loool*
participants (4)
-
Anders Wegge Keller
-
Benny Pedersen
-
Cliff Hayes
-
Reindl Harald