Re: [Clamav-users] Memory limit per process hit
Pablo Alsina wrote: On 5/28/05, Matt Fretwell <[EMAIL PROTECTED]> wrote: If this is not your preferred solution, how do you suggest to stop those scumbags searching for my user-database? Remember I'm not stopping spammers, I'm stopping user-db harvesters (probably future spammers). My patch does this. And this is not a clear cut issue as you have no objective mechanism for determining what is plain and simple a wrong email address and what is probe attempts. All current mechanisms are subjective, to the tune of "If X bad rcpts, then probably probing" or "if bad Rcpts look to be random <-- (subjective), than it is probing" So you can make educated guesses but there is no way to be 100 percent certain 100 percent of the time (or any other close value for that matter) I would encourage you to use DNSBL blocklists intensively, they are currently the only (relatively) cheap mechanism for keeping unwanteds away from your system. (my patch works for those as well) Of course you will also need to couple that with aggressive whitelisting. I would recommend you setup a DNSWL for that exact purpose. One proposed solution was to run another SMTP box, redirect SMTP traffic to it, and stop those attempts there, either with tarpitting, or directly terminate connections that reach a certain ratio of bad rcpts (as Joe Maimon suggested with a provided patch). This seems OK, but introduces another single point of failure, as this works if I disable SMTP directly to my real box (no secondary MX register allowed). No new box needed for my patch The other thing with this is if I terminate the connection when a threshold is reached, what avoids having this client reconnect, and continue with its mission? The whole point of tarpitting is that it does not stop them, just make it more expensive. sendmail rate-limiting of connection attempts. Interesting concept would be to prejudice rate-limiting code against "previous offenders", but in practice, I have found the current setup to be more than effective without causing ANY reported issues. Regards. ___ http://lurker.clamav.net/list/clamav-users.html ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Memory limit per process hit
> On 5/28/05, Matt Fretwell <[EMAIL PROTECTED]> wrote: > G.W. Haywood wrote: > > > > We added a sort of tarpitting solution to our sendmail... > > > clamav-milter seems to be suffering. What happens is that the > > > maximum number of childs are reached in a 2-4 hour period > > > > People with far more experience than I tell me that this isn't the > > way. > > And the above is the exact reason why they say it isn't the correct way > to do it. Adding this 'delay' to smtp negotiations can literally lead to > you Dos'ing, (or whichever phraseology you prefer), yourself :) > On 5/29/05, Joe Maimon <[EMAIL PROTECTED]> wrote: > To DOS your box, all I have to do is open a few hundred connections to > it and try to send email to a few dozen fake users. If that does not do > it, I can simply open a few hundred more. > > Cheap for me, expensive for you. > > > I would recommend a different approach, using this patch > [snip] Thank you all for your responses. Let me note two things: a) this tarpitting solution is not implemented on clamd, clamav-milter nor sendmail, but in the autentication layer. Sendmail seems to behave well with it, clamav-milter is the one "suffering" because of memory issues. b) Along with this tarpitting, a "firewall centered" solution is also in-place, preventing a single MTA to make too many connections concurrently, in order to avoid being DoS-ed by too many active connections. However, under normal circumstances, clamav-milter hits its max. memory limit, so I'll agree with you that I'm exposed to a DoS (its now turned off..so dont bother to try :-)) If this is not your preferred solution, how do you suggest to stop those scumbags searching for my user-database? Remember I'm not stopping spammers, I'm stopping user-db harvesters (probably future spammers). One proposed solution was to run another SMTP box, redirect SMTP traffic to it, and stop those attempts there, either with tarpitting, or directly terminate connections that reach a certain ratio of bad rcpts (as Joe Maimon suggested with a provided patch). This seems OK, but introduces another single point of failure, as this works if I disable SMTP directly to my real box (no secondary MX register allowed). The other thing with this is if I terminate the connection when a threshold is reached, what avoids having this client reconnect, and continue with its mission? The whole point of tarpitting is that it does not stop them, just make it more expensive. Regards. ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Memory limit per process hit
Pablo Alsina wrote: Hi We have been having some problems lately with our installation. We are using Sendmail+clamav-milter+clamd as our antivirus solution, over an RedHat Linux with a 2.4.21 kernel (RH9). This is somewhat outdated. Might I recommend you use the newer Fedora Core's or switch to a always-current distribution such as Debian Testing? We added a sort of tarpitting solution to our sendmail in order to stop people from scanning our userbase. What this means is that responses to SMTP "rcpt to" gets delayed when the envelope user is unknown. The more you miss, the more you get delayed (its exponential). So what happens is that some SMTP clients may have to wait up to 15 minutes for a response from Sendmail if the miss to many recipents. I cant help thinking that this is a bad idea as the cost you pay in overhead is far greater than the cost to the attacker. You have all these sendmail proccesses hanging around and all those milter threads. To DOS your box, all I have to do is open a few hundred connections to it and try to send email to a few dozen fake users. If that does not do it, I can simply open a few hundred more. Cheap for me, expensive for you. I would recommend a different approach, using this patch http://www.jmaimon.com/sendmail/patches/badrcpt_shutdown.v1.81301.patch http://www.jmaimon.com/sendmail/#badrcptshutdown This patch terminates connections that have a (configurable) high ratio of bad user attempts. This feature is compatible with sendmails delaying feature, so you can delay the connection for the first X bad users and shutdown the connection after Y bad users. Use that with sendmail rate-limiting. In this day and age all MTA's need to implement some kind of rate-limiting, otherwise all it takes is a few aggressive mta's out there and a joe job to put you out of business. I have been using this setup for quite some time. Works fine and dandy. ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Memory limit per process hit
On 27/05/05, Pablo Alsina <[EMAIL PROTECTED]> wrote: > So what we did was to increment the number of childers to an even > bigger value. But then we started to hit with other problems: > > clamav-milter[1932]: ClamAv: thread_create() failed: 12, try again > > We did an strace to that process, only to find out that we are running > out of memory: I had a similar problem using MIMEdefang rather than clamav-milter. See what default stack size is (ulimit -s). Reducing this in your sendmail init script, e.g. "ulimit -s 2048" can help. Worked for me. See earlier thread on this one: http://www.mail-archive.com/clamav-users@lists.sourceforge.net/msg08540.html And then you might be able to inconvenience 10 spammers instead of 1 before they DoS your mail service. But have fun! :) des -- des -- http://frommars.org/ ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Memory limit per process hit
On Fri, 27 May 2005 18:28:09 -0300 Pablo Alsina <[EMAIL PROTECTED]> wrote: > Hi > > We have been having some problems lately with our installation. We are > using Sendmail+clamav-milter+clamd as our antivirus solution, over an > RedHat Linux with a 2.4.21 kernel (RH9). Which version of ClamAV? -- oo. Tomasz Kojm <[EMAIL PROTECTED]> (\/)\. http://www.ClamAV.net/gpg/tkojm.gpg \..._ 0DCA5A08407D5288279DB43454822DC8985A444B //\ /\ Fri May 27 23:32:22 CEST 2005 pgpKkNGFjKbwB.pgp Description: PGP signature ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Memory limit per process hit
Hi We have been having some problems lately with our installation. We are using Sendmail+clamav-milter+clamd as our antivirus solution, over an RedHat Linux with a 2.4.21 kernel (RH9). We added a sort of tarpitting solution to our sendmail in order to stop people from scanning our userbase. What this means is that responses to SMTP "rcpt to" gets delayed when the envelope user is unknown. The more you miss, the more you get delayed (its exponential). So what happens is that some SMTP clients may have to wait up to 15 minutes for a response from Sendmail if the miss to many recipents. This has worked well with our sendmail, but clamav-milter seems to be suffering. What happens is that the maximum number of childs are reached in a 2-4 hour period, after that, we have to reset the clamav-milter and start over. clamav-milter[9957]: hit max-children limit (240 >= 240): waiting for some to exit This seems reasonable, as each SMTP client tend to stay more time "online", locking for more time a clamav-milter thread. So what we did was to increment the number of childers to an even bigger value. But then we started to hit with other problems: clamav-milter[1932]: ClamAv: thread_create() failed: 12, try again We did an strace to that process, only to find out that we are running out of memory: mmap2(NULL, 10489856, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) This is consistent with what a ps -axu reports. It reports more that 3 GB of memory in use, which is AFIK the max memory one single process can address. However, it does not seems to be reasonable to have each thread reserve 10MB of memory (note the mmap2 call). Is it possible to reduce that value? I did not find that call on the code. We tried to reduce the StreamMaxLength and ArchiveMaxFileSize on clamd.conf without success (just blind-shooting :-)) Any clue how this can be approached? Regards, Pablo ___ http://lurker.clamav.net/list/clamav-users.html
