Search results

Working fine now, thanks for the quick fix!

In the latest update (4.2.16) you appear to have prepended mod_security logs with the string "[modsecurity]". I'm not sure why you added this, but unfortunately it has broken CSF/LFD's regex for blocking client IP addresses because the line is no longer a traditional Apache format. Can you...

Thanks, I'll raise that with Comodo then.

Strange, you must've changed the build after you told me to update, or there was a delay before it was available. I just force upgraded again via CLI and now it's 403'ing the brute force attempts - which is great. Is it possible to get this to log multiple times still, so that something like...

There is no 403 or any apparent block occuring when these brute force attacks are detected: http://pastebin.com/raw.php?i=nb2diAeG The attack was frequent enough (100's per minute) that this definitely should've been logged multiple times. This does seem to be a problem with Litespeed.

I did update from the CLI, and our binary matches the same size as yours. Anything else you can do to help?

Thanks for the update. I just force updated Litespeed and I'm afraid it's the same behaviour. The brute force is detected and logged once in mod_security, but the attack is continuing and doesn't get logged/detected again until Litespeed is restarted.

We're seeing a similar issue here with the same rules and same ID. We're using the latest version of Litespeed (force upgraded just now to be sure). What's happening is, the CWAF rules are triggering a brute force detection on rule ID 230007. This is working fine, and the detection is correct...

@stormy: Great job of (better) explaining why these pages were also an issue for us, and I'm sure many others! Thank you for that. At the time I couldn't articulate these points as well as you :) @Michael "I think that a template editor may be farther into the hosting control panel realm than...

Michael, Thanks for your response, despite my complaints I do appreciate you being responsive and vocal about this. I found the setting you mentioned, however I think your defaults are extremely intrusive and in poor taste. The setting has now gone from controlling a small "Powered by"...

When addressing an issue with a clients site, I noticed that Litespeed is now generating its own and new custom 403 page by default instead of displaying the previous white 403 error page. Checking the release notes it seems this was added in 4.2.8. The new page is very large, grey and contains...

I agree that it's likely the timeout response means we are not vulnerable, however it would be great if we could determine why the tool is incompatible with Litespeed (why is it providing a different response than expected) and get to a stage where the tool can be used to confirm this. For...

Michael, Thanks for your response, but that's not the case. I'm running the Heartbleed tool from a local machine that is used for testing like this, not from the Heartbleed website.

Thanks for providing the patched update, however the Heartbleed test is failing with a timeout. This is probably a Heartbleed issue, but I wanted to post here and check if it's a problem with the Litespeed release? EDIT: Just to confirm, it's definitely NOT timing out. Telnets to port 443 go...

Currently having an issue where it seems dynamic sites have a rather high TTFB (Time to first byte) causing "Waiting for..." issues when loading them. Static sites seem fine however dynamic sites seem to have anywhere between a 500ms to 2000ms delay before producing results. Server is fine in...

Any update on this, please?

No, there is no cronjob on the server removing this file (why would there be anyway?). It's a brand new server so there is plenty of space on the /tmp partition.

Brand new server, running CloudLinux and a new install of LS 4.2: 2012-09-23 18:43:15.814 [INFO] [142.166.3.122:2444-0#APVH_XXXXXXXX] connection to [uds://tmp/lshttpd/lsphp5.sock] on request #0, confirmed, 0, associated process: -1, running: 0, error: No such file or directory! 2012-09-23...

Thanks for ignoring this issue. Not impressed with the level of support regarding this at all. I'm bringing this one up again because it's happening with your latest release of 4.0.18. PLEASE do something about this, as it's clearly a bug in your software. Debug log information: 2011-01-04...

I told you how to reproduce it.... I'll only grant temp root access to the server via MSN or some other means, since it's a production server and I can't have the downtime whilst I wait for you guys to login and investigate. It'd need to be handled in realtime.