On 17 Feb 2014, at 9:59, Thomas Eckardt <[email protected]> wrote:
> hmmm ... "lazy" - to log, or not to log, that is the question :):):) :-) > Be sure, delayed logging will never become a feature in assp. Given that it takes only two lines and that it might be useful, so that some of use can make assp play even more nicely with others, I can’t imagine why not. :-) There are many features and settings in assp that are noted as something like “change at your own risk” and many others that most assp admins never touch; that does not mean that they should be absent. By having a setting in the assp GUI to set the ‘logWriteDelay’ to a few seconds could help those of us who both need it and who do not write perl code. > Like in Trevor’s case, there are several possible solutions, and everyone can > change the code to its needs. True, it’s only two lines, but they would have to be changed at every upgrade. Given that the two lines could so easily be put in once, by one person, that could save a lot of work for assp admins who experience problems like my current one, where there is a sustained SMTP flood/attack that affects the OS in a way that chews up the CPU cycles. FWIW, I started using fail2ban because of there number of POP dictionary attacks on my machine, as well as the many ssh and vac attempts. Each POP attack would last about four hours as the IP tried all kinds of names to get into an account. Usually, the rate of POP attempts was about five to ten per second (assuming only one attack at a time). fail2ban would nuke each attacking IP in about two seconds. I set assp to nuke the IP for six hours. Now, I don’t even notice POP dictionary attacks, because they’re gone in about two seconds. Then, about eighteen months ago, I received some huge, sustained WordPress attacks from Russia and the Ukraine. I just added some filter to fail2ban, and they went away like a bad dream. fail2ban does so much for so many processes, that once one uses it, one is loath to let it go. Indeed, one realizes how it can be a help in many and varied situations, such as adding firewalling SMTP attackers, for which assp admins will use the main assp mail log. The main difference between SMTP attacks is that they tend to come from the many IPs of a botnet, whereas many attacks on other ports tend to be sustained from a single IP, making the latter a little easier to firewall. fail2ban nukes SMTP attacks in a couple of seconds, too, but I have to use the assp log for that. But, in some circumstances, the SMTP attacks seem to come from distributed botnets. Some of the IPs in those networks hammer my server, others only knock once or twice. Many of the attackers have got wise to only sending one request every few minutes or hours, to try to avoid being firewalled. fail2ban can handle those, too; because it becomes a significant factor when the botnet has thousands of computers, each knocking at my door every minute or three. The trick is to set up a fail2ban filter that acts over an appropriate time and then a subsequent ipfw banning that is also tailored to the type of threat. The only filter that has caused me problems is assp, because it can write so much detail to its mail log. That it can write so much detail is a wonderful thing, and I can turn off most of the logging when I’m not debugging, but there are several crack attempts that merit a filter: bad dnsbl, bad recipient, invalid HELO, penalty trap addresses, etc., etc.. To me, these are worth nuking before even assp gets to them. If I do succeed in added code to introduce a few seconds delay to the write, I will report here the effect on the server CPU load, which I expect to show a significant reduction. If it does, I’d ask that you please consider adding this setting to assp. Usually, when there is not an attack of the current magnitude, my server skips along with about 20%-30% use. During an attack like this, however, it groans under about >90%-95% CPU. I’m trying to keep my CPU much calmer than 90% usage. :-) T. ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
