Search results

you need to configure vhost through httpd.conf in order to use modsecurity rules configured through httpd.conf.

How the rules are configured? Native LSWS configuration? Apache httpd.conf? how vhosts are configured? Native LSWS configuration? Apache httpd.conf? If you want to use the security rule with vhost configured through httpd.conf, you need to configure those rules through httpd.conf.

I think you should print out the parameters passed to call_user_func_array(), if the value of member is not as expected, need to find out why. Can you create a simple test script for us to test?

You can set "SecDebugLogLevel 9" to check what happened. When you test it, the test URL should be a dynamic page.

You Apache and LiteSpeed PHP setup does not match, PHP version is different, the compile options are different. When you check the phpinfo.php page just add those REST parameters. compare the SERVER[] variables. like http://...../phpinfo.php/orderstatus/100001621/shipped/...

you need to check both SetEnvIf and BrowserMatch, BrowserMatch is just a special case. They can do the same thing.

It could because _SERVER["PATH_INFO"] has been populated to different values. please create phpinfo page under /rest/ directory, then compare the result of http://...../rest/phpinfo.php/orderstatus/100001621/shipped/...... under lsphp and Apache php. see if any differences in the _SERVER[] value.

https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:php:503-errors

It could be in the .htaccess. Make sure you have got the latest 4.2.14 build with force update.

indicates the process crashed.

you should avoid using $VH_NAME, use rules like

You need to change the action of rule 230001, remove "nolog" action. it follows the rule.

may I got a temp root access to take a look at this, it looks like the earlier build of 4.2.14 is till running.

Just grep "BrowserMatch" in Apache httpd.conf and .htaccess. comment them out see if it is fixed or not. If yes, send us the configuration for investigation.

Please try force reinstall 4.2.14, it maybe fixed already. There was an issue with certain setup have unnecessary intelligent gzip configuration using BrowserMatch directives. like BrowserMatch blabla no-gzip BrowserMatch blablabla !no-gzip It is to turning off gzip selectively for...

For the one request triggered the logging, does it returns 403? please check the audit_log. You may need to set SecDebugLogLevel to 9, and check the detailed debug logging. and flood it with "POST" requests to the login URL. Remember, the default threshold of triggering the brutal force rule...

I have tested it again in our lab, it is working fine. I think your force update may not be successful, or the server was not restarted properly after the update. . The size of 64bit binary of lshttpd.4.2.14 is 1547936 try the force update from command line instead of from web GUI.

Please turn on debug logging, restart LSWS, check if any error during server startup. Looks like the listener to vhost mapping was not added correctly, so all requests are still going to the default Apache vhost, instead of your customized vhost.

Are you using a hosting control panel? or just plain centos + Apache? Are you using the standard version?

please check if the latest build works properly or not. The older build does not implemented the "block" action, so it does not really deny any request. You can verify it from the audit log, the latest build default "block" to "deny".