Email Security once enabled CPU 100%

The first question that I have is what version of V7 are you running?  The latest, V7.005 has some performance enhancements that help to bring down CPU and memory usage a bit. 
 
Have you tried to reboot the 220?  This can help to clear out anything that may be "stuck" in memory causing the high CPU usage.
 
I'm running V7.005 on a 220 with all of the email protection enabled and generally run at 10-25% CPU and 75-85% memory.

I´m running V7.005. I´ve already tried a reboot with no effect.

Greets

Dolph

Hi,
maybe the queue of mails is too long.
check in /var/chroot-smtp/spool/input by ssh

is pfliter-reporte what you are referring to?  If so then you've probably hit another variant of the DOS bug.  I can't test that variant because i don't have a mail encryption license..i'm wondering if something in the packet filter needs to be modified for the encryption to work?

email security / encryption is completely unrelated to the packetfilter reporter.

email security / encryption is completely unrelated to the packetfilter reporter.

andreas,

instead of a knee-jerk reactive denial,  read his post the pfilter is causing his issue when he turn mail encryption on.  sounds like it's related to me.  You may want to ask around here i don't say things to pull them out of my hinderparts..[:)]

Well, it's certainly true that there are currently performance issues related to the packetfilter reporter, due to the fact that we're doing a lot of reporting-related operations on every dropped packet. And yes, this is one of the places we're going to work on in the near future.
But since the packetfilter reporter only operates on dropped/rejected packets, on detected portscans and on sip/h323 packets (since those are also logged by the kernel on v7) I can't think of any way how the packetfilter reporter can be related to email security/encryption. I am not the expert for email security/encryption, but I don't think it is capable of creating any of the above mentioned events.

If you want to see what the packetfilter reporter currently does, you can turn on debugging mode for the reporters by creating a /var/log/debug directory and doing a "/etc/init.d/syslogng reload". The reporters will detected the presence of the directory and start extended logging there, every processed event will be logged, as well as database operations etc. I'd be interested to hear what's causing the work load of the packetfilter reporter in the email enc/sec case.

Well, it's certainly true that there are currently performance issues related to the packetfilter reporter, due to the fact that we're doing a lot of reporting-related operations on every dropped packet. And yes, this is one of the places we're going to work on in the near future.

So I take it 7.006 does not address the DoS vulnerability the pfilter-reporte process causes. If this is the case, I want to know why I was told this issue would be addressed in the next update by support. I also will be dealing with my distributor demanding a refund of this crap and going else where. I have never seen such a disorganized, non-customer committed organization as Astaro. This is a security gateway that is being DoS by its own reporting daemon. This is ridiculous, this should have been escalated as high priority issue, and fixed straight away, instead of adding new features![:@]

Yeah the pfilter process goes nuts on my system.. 40-100% CPU

Simon can you confirm that 7.006 does not fix the pfilter-reporte exploit? Even with 7.006, it is still chewing 40%-100% CPU utilisation?