Community
Hi,
In Apache , we used to use deny from all directive to deny access to xmlrpc.php , but this directive doesn’t work in OLS, so there is an alternative way to do
In your .htaccess file , add following code
RewriteRule xmlrpc - [F,L]
And then restart OLS, then when you access /xmlrpc.php , you will have a 403 forbidden result 
Best regards,
Yes, I found this, thanks. But when I tried to use context for that - it doesn’t works for some reason. Will appreciate any advice or direction.
then you need to enable debug log for it
or try rewrite rule way
if only
RewriteRule wp-cron.php$ - [F,L]
does it work ?
then create a phpinfo page, to check the actual value of remote_addr , sometimes if behind proxy , the IP might be different
Just:
RewriteRule wp-cron.php$ - [F,L]
Doesn’t work as well… Still loads white page instead of 403
While this:
RewriteCond %{REQUEST_URI} error_log|wp-config-sample.php|readme.html|readme.txt|license.txt|wp-trackback.php|wp-config.php|php.ini|xmlrpc.php [NC]
RewriteRule .* - [F,L]
Works just fine and shows 403. What is the problem it can be?
what was the URI you entered ? was this placed at top of your htaccess ? did you restart OLS ?
Initially I placed this at the bottom, but now just moved it at the top. No difference. I’m editing Rewrite Rules in Cyberpanel, so it should automatically restart OLS when Rewrite Rules changed isn’t it? And also I pressed Reboot Litesspeed button as well. It doesn’t help. But I didn’t really understand your question about URI.
And this works just perfect right after saving rules:
RewriteCond %{REQUEST_URI} error_log|wp-config-sample.php|readme.html|readme.txt|license.txt|wp-trackback.php|wp-config.php|php.ini|xmlrpc.php [NC]
RewriteRule .* - [F,L]
did you access it by “wp-cron.php” only ? or like “wp-cron.php?doing_cron…” ?
this is more like rewrite rule didn’t match the pattern
you can enable OLS debug log , to see what exactly OLS understood that regex and fix on it
So, I want to block any external access to Domain.com/wp-cron.php
But to allow when server’s cron calling to Domain.com/wp-cron.php?doing_cron…
and yes I access it by “wp-cron.php” only
you need to enable debug log
see how OLS responded to the rewritecond and rewriterule
it will something like
RewriteCond : value XXXXX check against XXXXX : match X
where after match it will show a number , negative number means no match , positive number means matched
so is same to RewriteRule
it will say something like
rewrite rule : URI xxxx , check against pattern xxxxx , match X
this will help you to debug rewrite rule
Debug log in OLS panel or somewhere in Cyberpanel?
Just one moment - when I add wp-cron.php to this sentention:
RewriteCond %{REQUEST_URI} xmlrpc.php|wp-cron.php [NC]
RewriteRule .* - [F,L]
It works. But doesn’t works in:
RewriteRule wp-cron.php$ - [F,L]
that one actually works on me
2021-03-05 19:14:09.446991 [INFO] [29812] [xxx:51931-Q:49B5225303773A50-3#xxx] [REWRITE] strip base: '/' from URI: '/wp-cron.php'
2021-03-05 19:14:09.447071 [INFO] [29812] [xxx:51931-Q:49B5225303773A50-3#xxx] [REWRITE] Rule: Match 'wp-cron.php' with pattern 'wp-cron.php$', result: 1
like I said , enable debug log for rewrite rule , it will log each steps for how it checks
Some news: Domain.com/wp-cron.php?doing_wp_cron - gives 403,
but just a Domain.com/wp-cron.php - gives white page reloading…
And for some reason I have zero [REWRITE] INFO in my logs
My rules looks like:
RewriteCond %{SERVER_ADDR} !^123\.123\.123\.123
RewriteRule wp-cron.php$ - [F,L]
Yes, did it exactly as you said. No such (REWRITE) records…
then you got weirder issue
can try enable full debug log on OLS , that will tell every single action from start up
Yes, did it, and still have only Info/Notice records without a single rewrite record…
go to server conf → log
set Log Level to DEBUG
set Debug Level to HIGH
and this moment is confusing:
RewriteCond %{SERVER_ADDR} !^123\.123\.123\.123
RewriteRule wp-cron.php$ - [F,L]
Why it gives 403 if I request /wp-cron.php?doing_cron
But it doesn’t restrict access if I request just /wp-cron.php
Yes, yes. Exactly like this:
go to server conf → log
set Log Level to DEBUG
set Debug Level to HIGH
you can combine the server add with request uri in rewrite cond , so you can get rid of wp-cron.php in rewrite rule
Please can you show an example? And thanks for your time and patience
RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123
RewriteCond %{REQUEST_URI} xmlrpc.php|wp-cron.php [NC]
RewriteRule .* - [F,L]
somethign like this
this means , if request url is wp-cron or xmlrpc , and client ip is not 123.123.123.123 , then 403
is {SERVER_ADDR} possible here instead of {REMOTE_ADDR} ?
https://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritecond
you need to check this doc first
server addr is the server itself
when request to a page, it is always a remote addr , even it is from 127.0.0.1 or server itself’s public/private ip
Ok, you tired of me )) I will try to recognize these admin’s hieroglyphs
Thanks for your help!
Ok, got it. Thanks you.
not sure what do you mean by tired of you or hieroglyphs ? so far I have been typing/writing on Standard English alphabet, maybe not perfect in grammar as it’s not my native language .
basically when you want to do some condition check on rewritecond , you need to understand what is it to check against
No, no, I don’t want to offend you in any way! Instead I’m very grateful to you for your help. I just meant that things like this one: Documentation: Apache HTTP Server - The Apache HTTP Server Project
Is a kind of hieroglyphs for me.
yeah well , first time I read it is also like “hieroglyphs”
you just need to slow it down , read it line by line , it will sink in : )
Oh, things got weirder:
RewriteCond %{REMOTE_ADDR} !^127\.0\.0\.1
RewriteCond %{REQUEST_URI} wp-cron.php|xmlrpc.php [NC]
RewriteRule .* - [F,L]
xmlrpc.php - shows 403
wp-cron.php - white page, as usual
And why do this? After all, sooner or later hackers will discover another vulnerability that can be exploited.
Type your comment> @alinabeen said:
And why do this? After all, sooner or later hackers will discover another vulnerability that can be exploited.
yeah , why use any software ? sooner or later , hackers will discover another vul that can be exploited
