[Dovecot] avoid log message when using nagios check
Hello, I'm using a nagios check to monitor dovecot status, since dovecot v2 I see those syslog messages on every nagios check:
pop3-login: Aborted login (no auth attempts in 0 secs) imap-login: Aborted login (no auth attempts in 0 secs)
I tried to avoid those messages sending a logout string:
check_imap -H localhost -e 'OK' -s 'a logout' check_pop -H localhost -e 'OK' -s 'quit'
but now I get
imap-login: Disconnected (no auth attempts in 0 secs) pop3-login: Disconnected (no auth attempts in 0 secs)
what can I do to avoid a log message on every nagios check?
thanks! Lluís
W dniu 10.07.2013 10:59, lluis pisze:
Hello, I'm using a nagios check to monitor dovecot status, since dovecot v2 I see those syslog messages on every nagios check:
pop3-login: Aborted login (no auth attempts in 0 secs) imap-login: Aborted login (no auth attempts in 0 secs)
I tried to avoid those messages sending a logout string:
check_imap -H localhost -e 'OK' -s 'a logout' check_pop -H localhost -e 'OK' -s 'quit'
but now I get
imap-login: Disconnected (no auth attempts in 0 secs) pop3-login: Disconnected (no auth attempts in 0 secs)
what can I do to avoid a log message on every nagios check? Hi Lluis! Maybe just filter it in your syslog? Marcin
Hi Marcin, filtering in syslog is an option, but then I will not be able to get those messages when are not generated from a nagios check
there is something I can send to silently exit?
El dc 10 de 07 de 2013 a les 11:15 +0200, en/na Marcin Mirosław va escriure:
W dniu 10.07.2013 10:59, lluis pisze:
Hello, I'm using a nagios check to monitor dovecot status, since dovecot v2 I see those syslog messages on every nagios check:
pop3-login: Aborted login (no auth attempts in 0 secs) imap-login: Aborted login (no auth attempts in 0 secs)
I tried to avoid those messages sending a logout string:
check_imap -H localhost -e 'OK' -s 'a logout' check_pop -H localhost -e 'OK' -s 'quit'
but now I get
imap-login: Disconnected (no auth attempts in 0 secs) pop3-login: Disconnected (no auth attempts in 0 secs)
what can I do to avoid a log message on every nagios check? Hi Lluis! Maybe just filter it in your syslog? Marcin
On 10.7.2013, at 12.44, lluis lluis@ingent.net wrote:
there is something I can send to silently exit?
No. Attackers would otherwise use that. Although I suppose something could be added if the source IP is from login_trusted_networks.. Wonder what would be a good way. I guess the same commands that are used to pass IPs through proxies, so maybe:
IMAP:
a ID ("x-silent-logout" "y") b LOGOUT
POP3:
XCLIENT SILENT-LOGOUT QUIT
But would those work well enough everywhere? Should it be a LOGOUT/QUIT parameter instead?.. Such parameters could be troublesome though.
Am 10.07.2013 10:59, schrieb lluis:
Hello, I'm using a nagios check to monitor dovecot status, since dovecot v2 I see those syslog messages on every nagios check:
pop3-login: Aborted login (no auth attempts in 0 secs) imap-login: Aborted login (no auth attempts in 0 secs)
I tried to avoid those messages sending a logout string:
check_imap -H localhost -e 'OK' -s 'a logout' check_pop -H localhost -e 'OK' -s 'quit'
but now I get
imap-login: Disconnected (no auth attempts in 0 secs) pop3-login: Disconnected (no auth attempts in 0 secs)
what can I do to avoid a log message on every nagios check?
Just do a complete login/logout sequence. I have developed some perl scripts to do so.
This is fine for the nagios checks, but we are facing similar problems with our loadbalancer, which is just doing TCP Healthchecks on the IMAP/POP3/SIEVE ports, so being able to disable the warning for trusted networks would be really helpful.
Regards Daniel
Dipl.-Inf. Daniel Parthey System Engineer Metaways Infosystems GmbH Pickhuben 2, D-20457 Hamburg
E-Mail: d.parthey@metaways.de Web: http://www.metaways.de Tel: +49 (0)40 317031-537 Fax: +49 (0)40 317031-937
Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel Handelsregister: Amtsgericht Lübeck HRB 4508 AH Geschäftsführung: Hermann Thaele, Lüder-H.Thaele
On 2013-07-10 05:16, Daniel Parthey wrote:
Just do a complete login/logout sequence.
If you aren't doing a complete login/logout sequence and possibly even pulling down a message you aren't performing an accurate health check to begin with. We don't use nagios but I'd be surprised if those scripts don't optionally take a username and password.
This is fine for the nagios checks, but we are facing similar problems with our loadbalancer, which is just doing TCP Healthchecks on the IMAP/POP3/SIEVE ports, so being able to disable the warning for trusted networks would be really helpful.
Same here. We use LVS with surealived and LUA scripting to do a complete login/logout cycle as part of the health check. Even the ancient Alteon's had similar functionality (and supported common protocols like pop and imap out of the box.)
-- Kelsey Cummings - kgc@corp.sonic.net sonic.net, inc. System Architect 2260 Apollo Way 707.522.1000 Santa Rosa, CA 95407
On 10.7.2013, at 21.48, Kelsey Cummings kgc@corp.sonic.net wrote:
This is fine for the nagios checks, but we are facing similar problems with our loadbalancer, which is just doing TCP Healthchecks on the IMAP/POP3/SIEVE ports, so being able to disable the warning for trusted networks would be really helpful.
Same here. We use LVS with surealived and LUA scripting to do a complete login/logout cycle as part of the health check. Even the ancient Alteon's had similar functionality (and supported common protocols like pop and imap out of the box.)
So it would have to disable logging also for the logout message after login.. Can those load balancers be configured to send these kind of extra XCLIENT/ID commands? Is it really worth the effort that it really works in enough systems?
Timo Sirainen tss@iki.fi schrieb:
On 10.7.2013, at 21.48, Kelsey Cummings kgc@corp.sonic.net wrote:
This is fine for the nagios checks, but we are facing similar problems with our loadbalancer, which is just doing TCP Healthchecks on the IMAP/POP3/SIEVE ports, so being able to disable the warning for trusted networks would be really helpful.
Same here. We use LVS with surealived and LUA scripting to do a complete login/logout cycle as part of the health check. Even the ancient Alteon's had similar functionality (and supported common protocols like pop and imap out of the box.)
So it would have to disable logging also for the logout message after login.. Can those load balancers be configured to send these kind of extra XCLIENT/ID commands? Is it really worth the effort that it really works in enough systems?
No. It does simple TCP connects, doesn't know about IMAP at all and won't send any string, it just checks if the TCP port is available. Would it be a problem to remove the log message altogether, at least for trusted IPs or make it a warning, not an error. What is so bad with TCP connects/disconnects without any IMAP traffic, especially when they originate from trusted IPs?
On 10.7.2013, at 22.39, Daniel Parthey d.parthey@metaways.de wrote:
So it would have to disable logging also for the logout message after login.. Can those load balancers be configured to send these kind of extra XCLIENT/ID commands? Is it really worth the effort that it really works in enough systems?
No. It does simple TCP connects, doesn't know about IMAP at all and won't send any string, it just checks if the TCP port is available. Would it be a problem to remove the log message altogether, at least for trusted IPs or make it a warning, not an error. What is so bad with TCP connects/disconnects without any IMAP traffic, especially when they originate from trusted IPs?
They are regular info messages, not errors or warnings..
Am 10.07.2013 21:41, schrieb Timo Sirainen:
On 10.7.2013, at 22.39, Daniel Partheyd.parthey@metaways.de wrote:
So it would have to disable logging also for the logout message after login.. Can those load balancers be configured to send these kind of extra XCLIENT/ID commands? Is it really worth the effort that it really works in enough systems?
No. It does simple TCP connects, doesn't know about IMAP at all and won't send any string, it just checks if the TCP port is available. Would it be a problem to remove the log message altogether, at least for trusted IPs or make it a warning, not an error. What is so bad with TCP connects/disconnects without any IMAP traffic, especially when they originate from trusted IPs?
They are regular info messages, not errors or warnings..
You're right, TCP connections don't seem to be a real problem here.
I confused it with the following messages, we get every few minutes in the dovecot-director.log, but I'm not sure of their origin yet, there are some other imap proxies/balancer in front of the director:
Jul 10 21:51:46 10.129.3.233 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 21:51:49 10.129.3.213 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 21:54:46 10.129.3.233 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 21:56:22 10.129.3.233 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 21:57:51 10.129.3.200 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 21:59:23 10.129.3.213 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 22:00:48 10.129.3.213 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 22:03:47 10.129.3.213 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 22:06:51 10.129.3.213 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 22:11:14 10.129.3.200 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 22:12:52 10.129.3.213 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 22:15:50 10.129.3.200 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 22:15:50 10.129.3.233 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 22:24:51 10.129.3.213 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 22:24:53 10.129.3.200 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 22:35:21 10.129.3.200 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 22:39:52 10.129.3.213 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 22:41:22 10.129.3.233 dovecot: director: Error: read(login connection) failed: Connection reset by peer
Regards Daniel
Dipl.-Inf. Daniel Parthey System Engineer Metaways Infosystems GmbH Pickhuben 2, D-20457 Hamburg
E-Mail: d.parthey@metaways.de Web: http://www.metaways.de
Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel Handelsregister: Amtsgericht Lübeck HRB 4508 AH Geschäftsführung: Hermann Thaele, Lüder-H.Thaele
On 10.7.2013, at 23.47, Daniel Parthey d.parthey@metaways.de wrote:
You're right, TCP connections don't seem to be a real problem here.
I confused it with the following messages, we get every few minutes in the dovecot-director.log, but I'm not sure of their origin yet, there are some other imap proxies/balancer in front of the director:
Jul 10 21:51:46 10.129.3.233 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 21:51:49 10.129.3.213 dovecot: director: Error: read(login connection) failed: Connection reset by peer
Those aren't really errors. They should just be ignored. This gets rid of them: http://hg.dovecot.org/dovecot-2.2/rev/ebbe00999da8
I'm not sure why I haven't seen these before though. Was this with Linux? Or I guess more likely it's because you're not using it in high performance mode as explained in http://wiki2.dovecot.org/LoginProcess
Am 12.07.2013 02:09, schrieb Timo Sirainen:
On 10.7.2013, at 23.47, Daniel Partheyd.parthey@metaways.de wrote:
You're right, TCP connections don't seem to be a real problem here.
I confused it with the following messages, we get every few minutes in the dovecot-director.log, but I'm not sure of their origin yet, there are some other imap proxies/balancer in front of the director:
Jul 10 21:51:46 10.129.3.233 dovecot: director: Error: read(login connection) failed: Connection reset by peer Jul 10 21:51:49 10.129.3.213 dovecot: director: Error: read(login connection) failed: Connection reset by peer
Those aren't really errors. They should just be ignored. This gets rid of them: http://hg.dovecot.org/dovecot-2.2/rev/ebbe00999da8
I'm not sure why I haven't seen these before though. Was this with Linux?
Yes, this was with Linux.
Or I guess more likely it's because you're not using it in high performance mode as explained in http://wiki2.dovecot.org/LoginProcess
Indeed we're currently using the default (high security mode).
Regards Daniel
Dipl.-Inf. Daniel Parthey System Engineer Metaways Infosystems GmbH Pickhuben 2, D-20457 Hamburg
E-Mail: d.parthey@metaways.de Web: http://www.metaways.de
Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel Handelsregister: Amtsgericht Lübeck HRB 4508 AH Geschäftsführung: Hermann Thaele, Lüder-H.Thaele
Le 10 juil. 2013 à 21:41, Timo Sirainen a écrit :
On 10.7.2013, at 22.39, Daniel Parthey wrote:
So it would have to disable logging also for the logout message after login.. Can those load balancers be configured to send these kind of extra XCLIENT/ID commands? Is it really worth the effort that it really works in enough systems?
No. It does simple TCP connects, doesn't know about IMAP at all and won't send any string, it just checks if the TCP port is available. Would it be a problem to remove the log message altogether, at least for trusted IPs or make it a warning, not an error. What is so bad with TCP connects/disconnects without any IMAP traffic, especially when they originate from trusted IPs?
They are regular info messages, not errors or warnings..
Really, I'm not sure it is the role of Dovecot to bother with such things. As a mail-related software, it is essential to know it will report any potentially useful info.
So, if the admin ins't interested in info messages emitted by Dovecot, just filter those messages at the logging system level; no need to have Dovecot implement sophisticated logging policies.
If Nagios insists on natively perform incomplete logins, it isn't Dovecot's responsibility to try to filter such log messages on the basis of sophisticated rules: on the contrary, such messages are useful to understand that something is worth a deeper investigation than just asking Dovecot to implement more complexity for more than probably futile reasons.
If a device or a surveyor software behaves like an attacker, couldn't be argued that the device or the surveyor software is somehow flawed, instead of asking Dovecot to hide those flaws?
Axel
participants (6)
-
Axel Luttgens
-
Daniel Parthey
-
Kelsey Cummings
-
lluis
-
Marcin Mirosław
-
Timo Sirainen