Re: [vchkpw] chkuser: Let chkuser kill qmail-smtpd
Hi Tobias, I don't think that quitting qmail-smtpd is the best action. When you enable these thresholds settings and enable delay, chkuser simply aborts further rcpt to: with the message you see, and for each new rcpt waits for CHKUSER_ERROR_DELAY (default 1000) milliseconds, increased, for each aborted rcpt, of a value of CHKUSER_ERROR_DELAY_INCREASE (default 100) milliseconds. So, based on standard settings, if you have 100 aborted recipients, you have a delay of 11 seconds for the 101th rcpt (N.B.: all that happens only if you have defined the variables needed to enable this check). So, you can decrease these values, or define CHKUSER_ERROR_DELAY_INCREASE to zero, or disable these controls. As conseguence, chkuser cannot waste any resource, as the most used instruction in such conditions is delay. I feel this is the most suitable way to fight intruders, making them lose time and/or resources without giving them valuable informations. If you just quit the process after the initial threshold, they will start a qmail-smtpd process and gain real information for the initial rcpts of the new process. I've been attacked a lot of times. First times intruders did not note the you are violating... message, and wasted some days. After that, they made the same job, with a unique rcpt to for each session. So, when I saw a lot of CHKUSER rejected messages from the same IP, and watched the strange sequence of rcpt looked for, I denied that IP in my tcp.smtp. I was asked also to keep trace automatically of these intruders between sessions, but I feel this is out of chkuser scopes and very dangerous to perform. I've controlled my logs, and sometimes I see remote senders (i.e. mailing lists or systems answering back to viruses) that look hundreds of times for the same broken addresses, and I feel I cannot automatically create a black list for those remote IP. You can make a simple script checking for CHKUSER logs, alerting you when numbers are strange (see http://www.interazioni.it/opensource/chkuser/documentation/logging_summary.html for a very simple example). Ciao, Tonino At 17.53 29/03/2005, you wrote: Am Dienstag, 29. März 2005 18:37 schrieb Jeremy Kitchen: On Tuesday 29 March 2005 10:31 am, Tobias Orlamuende wrote: After intensive logging I found out, that chkuser sends something like You are violating my security policy when CHKUSERRCPTLIMIT and / or CHKUSER_WRONGRCPTLIMIT is reached. That's fine so far, but the other side is still sending masses of rcpt to. This causes qmail-smtpd to stay open for a very long time until the sender finishes sending his spam. so? the resources consumed by a single copy of qmail-smtpd hanging around for some spammer to give up are minimal. IMHO not :-( qmail-smtpd is running for 40 minutes and counts up (until now) to 105 processes where the oldest one dates from one minute after startup of qmail-smtpd. Load of this Dueal-Opteron (240) is about 100. Timeoutsmtpd is set in control... Most of the started qmail-smtpd's are closed correctly, but some stay open which gives this amount... I am not 100% sure if this problem is caused by chkuser, but for me it looks like. The strange thing is, that most of these open sessions are using STARTTLS. Btw: Anybody made bad experiences with this patch ? http://www.arda.homeunix.net/store/qmail/starttls-2way-auth-20050307.patch I started with Bill Shupp's tls-auth-patch but the loead was even going much higher than now. Wouldn't it make sense to let chkuser terminatie this specific qmail-smtpd instance if one of the above limits is reached? perhaps, but why? See above. If yes, how could it be implemented? just edit the code. Find the place where it flips on the ok, we're not accepting anymore limit... and have it exit. Nice. But for me as somebody who has nearly no knowledge of C it is quite difficult. Maybe you, Jeremy, or somebody else on this list has any hints for the above situation... Greetings Tobias
Re: [vchkpw] chkuser: Let chkuser kill qmail-smtpd
On Tuesday 29 March 2005 10:31 am, Tobias Orlamuende wrote: After intensive logging I found out, that chkuser sends something like You are violating my security policy when CHKUSERRCPTLIMIT and / or CHKUSER_WRONGRCPTLIMIT is reached. That's fine so far, but the other side is still sending masses of rcpt to. This causes qmail-smtpd to stay open for a very long time until the sender finishes sending his spam. so? the resources consumed by a single copy of qmail-smtpd hanging around for some spammer to give up are minimal. Wouldn't it make sense to let chkuser terminatie this specific qmail-smtpd instance if one of the above limits is reached? perhaps, but why? If yes, how could it be implemented? just edit the code. Find the place where it flips on the ok, we're not accepting anymore limit... and have it exit. -Jeremy -- Jeremy Kitchen ++ Systems Administrator ++ Inter7 Internet Technologies, Inc. [EMAIL PROTECTED] ++ inter7.com ++ 866.528.3530 ++ 815.776.9465 int'l kitchen @ #qmail #gentoo on EFnet IRC ++ scriptkitchen.com/qmail GnuPG Key ID: 481BF7E2 ++ jabber:[EMAIL PROTECTED] pgpN4R7jB71Bd.pgp Description: PGP signature
Re: [vchkpw] chkuser: Let chkuser kill qmail-smtpd
Am Dienstag, 29. Mrz 2005 18:37 schrieb Jeremy Kitchen: On Tuesday 29 March 2005 10:31 am, Tobias Orlamuende wrote: After intensive logging I found out, that chkuser sends something like You are violating my security policy when CHKUSERRCPTLIMIT and / or CHKUSER_WRONGRCPTLIMIT is reached. That's fine so far, but the other side is still sending masses of rcpt to. This causes qmail-smtpd to stay open for a very long time until the sender finishes sending his spam. so? the resources consumed by a single copy of qmail-smtpd hanging around for some spammer to give up are minimal. IMHO not :-( qmail-smtpd is running for 40 minutes and counts up (until now) to 105 processes where the oldest one dates from one minute after startup of qmail-smtpd. Load of this Dueal-Opteron (240) is about 100. Timeoutsmtpd is set in control... Most of the started qmail-smtpd's are closed correctly, but some stay open which gives this amount... I am not 100% sure if this problem is caused by chkuser, but for me it looks like. The strange thing is, that most of these open sessions are using STARTTLS. Btw: Anybody made bad experiences with this patch ? http://www.arda.homeunix.net/store/qmail/starttls-2way-auth-20050307.patch I started with Bill Shupp's tls-auth-patch but the loead was even going much higher than now. Wouldn't it make sense to let chkuser terminatie this specific qmail-smtpd instance if one of the above limits is reached? perhaps, but why? See above. If yes, how could it be implemented? just edit the code. Find the place where it flips on the ok, we're not accepting anymore limit... and have it exit. Nice. But for me as somebody who has nearly no knowledge of C it is quite difficult. Maybe you, Jeremy, or somebody else on this list has any hints for the above situation... Greetings Tobias
Re: [vchkpw] chkuser: Let chkuser kill qmail-smtpd
On Tuesday 29 March 2005 10:53 am, Tobias Orlamuende wrote: Am Dienstag, 29. Mrz 2005 18:37 schrieb Jeremy Kitchen: On Tuesday 29 March 2005 10:31 am, Tobias Orlamuende wrote: After intensive logging I found out, that chkuser sends something like You are violating my security policy when CHKUSERRCPTLIMIT and / or CHKUSER_WRONGRCPTLIMIT is reached. That's fine so far, but the other side is still sending masses of rcpt to. This causes qmail-smtpd to stay open for a very long time until the sender finishes sending his spam. so? the resources consumed by a single copy of qmail-smtpd hanging around for some spammer to give up are minimal. IMHO not :-( qmail-smtpd is running for 40 minutes and counts up (until now) to 105 processes where the oldest one dates from one minute after startup of qmail-smtpd. Load of this Dueal-Opteron (240) is about 100. Timeoutsmtpd is set in control... Most of the started qmail-smtpd's are closed correctly, but some stay open which gives this amount... I am not 100% sure if this problem is caused by chkuser, but for me it looks like. The strange thing is, that most of these open sessions are using STARTTLS. Btw: Anybody made bad experiences with this patch ? http://www.arda.homeunix.net/store/qmail/starttls-2way-auth-20050307.patch I started with Bill Shupp's tls-auth-patch but the loead was even going much higher than now. Try running: /var/qmail/bin/update_tmprsadh Then add a nightly root crontab entry: 0 2 * * * /var/qmail/bin/update_tmprsadh 21 /dev/null Without this, qmail-smtpd will generate a unique key pair for each TLS session, which is *very* cpu intensive. Ken Jones snip
