Thanks for the help, I've changed the numbers as you suggest. "esmtpd is designed to refuse additional connections when any upper limit is reached."
This makes sense. However, I assume that as old connections disconnect or time out, new ones are once again available. There were no new incoming esmtp connections in the log for a day and a half after the spam storm when the server was rebooted and lots of mail piled up on secondary servers during this time. Does esmptd permanently refuse connections after reaching a limit? Could the couriertcpd process listening on port 25 have crashed or got messed up? Could 75 esmtpd processes somehow got stuck preventing new ones from starting? Unfortunately, we didn't do a ps before the machine was rebooted. I do see a constant stream of successful pop3d connections in the log. Logs on the secondary show mail coming in that would have gone to the primary if it had been able to accept connections. -----Original Message----- From: Sam Varshavchik [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 4:55 PM To: [EMAIL PROTECTED] Subject: [courier-users] Re: Esmtp ddos vulnerability in 0.40.0.20021026? Stephen S. Kelley writes: > A client's courieresmtp service stopped accepting connections until > restarted. Examination of the logs show a storm of spam email > connections from an address with a pattern [EMAIL PROTECTED] where > The email itself was typical spam of size 3KB. The unusual thing was > that the connections were from about 15 different IP addresses > scattered all over the place. > > Logs also show the usual regular "Started ./courieresmtp, pid=xxx, That's outgoing esmtp, has nothing to do with incoming esmtp. > maxdels=40, maxhost=4, maxrcpt=100" messages after the spam storm > stopped though the server refused connections port 25 connections > until restarted about 36 hours later. Esmpt appears to be the only > service that had problems: local mail and pop continued to function. > > The only abnormal thing I noticed in the sar log for the 10min period > containing the spam storm was a bufpg/s=-7 which was unusually low and > a plist-sz=185 which was unusually high. > > /etc/esmtpd contains (among other things): > MAXDAEMONS=75 > MAXPERC=50 > MAXPERIP=10 > > Other than coming from many IP addresses at the same time, this looks > like a typical, though more intense, spam pattern. The amount of > incoming emails was probably the highest the server (dual 300Mhz, > 500MB RAM RedHat 8.0 on 1/4 T1 DSL) ever had, but I don't think close > to overwhelming the hardware or OS. > > Is there anything I can do to prevent the esmptd service from refusing > connections if similar circumstances occur in the future? Why didn't > the courieresmtp restart clear the problem? esmtpd is designed to refuse additional connections when any upper limit is reached. The way you've set up your parameters is that an attacker needs only eight different IP addresses, or two different /24s, to completely use up all available incoming connections. You accept a maximum of 75 incoming ESMTP connections, but allow up to ten connections from the same IP address, or 50 connections from the same /24. The math just doesn't add up. There's no reason to accept more than four concurrent ESMTP connections from the same IP address. Reduce MAXPERC to 10, and MAXPERIP to 4. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
