DoS (was IMAP-auth on LAN and otherwise)
Today the problem raised its head again, with a twist. A LAN client lost the DNS setting that pointed directly to the LAN address of the IMAP server, and two things happened: the LAN client could not connect to IMAP as we know, and a telephone call from the external client reported the same. When the LAN client closed Thunderbird, then the external client regained access. There were no other clients online at the same time. It turns out that the single LAN client was making enough requests to saturate dovecot's authentication service. I already described the detail with wireshark.
On Tue, May 2, 2017 at 3:46 PM, Rupert Gallagher ruga@protonmail.com wrote: Hello,
Thunderbird has been bugging us with connection errors. Dovecot is installed on a local server that carries a local IP and a public IP. When Thunderbird on a local client connects successfully, Wireshark shows a SYN request from the client's IP on LAN to the public IP of the server, followed by the ACK from the same public IP. When Thunderbird on the same local client fails to connect, Wireshark shows a SYN request from the client's IP on LAN to the public IP of the server, followed by the ACK from the server's LAN address, the client does not accept the ACK as valid and sends a new SYN request. The loop eventually leads to time-out. At the client's console, the DNS query of the IMAP server always responds with the server's public IP address.
It is evident from Wireshark that the dovecot server sends ACKs from two IPs. Is it possible to instruct Dovecot to use the public IP only?
On Monday 08 May 2017 19:25:26 Rupert Gallagher wrote:
Today the problem raised its head again, with a twist. A LAN client lost the DNS setting that pointed directly to the LAN address of the IMAP server, and two things happened: the LAN client could not connect to IMAP as we know, and a telephone call from the external client reported the same. When the LAN client closed Thunderbird, then the external client regained access. There were no other clients online at the same time. It turns out that the single LAN client was making enough requests to saturate dovecot's authentication service. I already described the detail with wireshark.
On Tue, May 2, 2017 at 3:46 PM, Rupert Gallagher ruga@protonmail.com wrote: Hello,
Thunderbird has been bugging us with connection errors. Dovecot is installed on a local server that carries a local IP and a public IP. When Thunderbird on a local client connects successfully, Wireshark shows a SYN request from the client's IP on LAN to the public IP of the server, followed by the ACK from the same public IP. When Thunderbird on the same local client fails to connect, Wireshark shows a SYN request from the client's IP on LAN to the public IP of the server, followed by the ACK from the server's LAN address, the client does not accept the ACK as valid and sends a new SYN request. The loop eventually leads to time-out. At the client's console, the DNS query of the IMAP server always responds with the server's public IP address.
It is evident from Wireshark that the dovecot server sends ACKs from two IPs. Is it possible to instruct Dovecot to use the public IP only?
I think is better to fix that using iptables, depending on your network topology (if you NAT the local lan traffic with destination the external IP of dovecot, it will answer with the external IP) . In yours case, looks like the trafic to the external IP isn't NAT-ed, which could cause troubles also for other kind of traffic.
We use PF instead of IPTABLES, where overloading leads to banning of specific IP (hence the useful absence of NAT). One such "workaround" would have to be managed, for example with an e-mail to alert sysadmin followed up by some manual labour. It is doable, but it does not solve the problem with dovecot, as shown with wireshark. A solution would consist in dovecot limiting the number of connections from the same IP, so that no IP is blacklisted by PF and the server keeps going without any denial of service. Only the specific TB client would be temporarily affected.
Sent from ProtonMail Mobile
On Tue, May 9, 2017 at 8:36 AM, Mihai Badici mihai@badici.ro wrote: I think is better to fix that using iptables, depending on your network topology (if you NAT the local lan traffic with destination the external IP of dovecot, it will answer with the external IP) . In yours case, looks like the trafic to the external IP isn't NAT-ed, which could cause troubles also for other kind of traffic.
participants (2)
-
Mihai Badici
-
Rupert Gallagher