mehmetg

Thanks!

Wow! I didn’t know it was that simple. Thank you so much!

Thanks a lot. But this only blocks scripts added using the code in the example I gave above. It doesn’t block scripts that already exist. I mean it doesn’t block javascripts that already exist in the head or footer of the site.

Understood. Thanks for your suggestions.

Frankly, when I click the js, f.txt continues to download. In other words, we can understand the problem without activating it again on a site. For several hours there was no problem. But suddenly f.txt started to download again. Try clicking the js from time to time. You will download f.txt. I am sure of that. It also downloads f.txt in a different browser. So it’s not just for Chrome.

I am also sending f.txt ( https://drive.google.com/file/d/1_FkOnPlbLmDhvQOA0TvwyG-hhNhEQqV5/view?usp=sharing ). When you check, you will see that some letters have changed.

Yes it’s really strange. When I try a different browser, this js still downloads “f.txt”. Tested/received feedback from different country IPs as well. Unfortunately, the result does not change.

+1. It pisses me off that plugins use “Site Health”! Please remove this nonsense. (If you don’t want to remove it completely, you can at least move it to the recommendation area)

Ok, I got it. I ran the SEO Data Optimization from the SEO → Tools page. It ended successfully after waiting for a while. Then the notification disappeared. Thanks for info.

Alright what now? What will I do? So is it compulsory to use the new indexable feature? How can I disable the new indexable feature completely? Is it enough to turn off the ryte integration feature?

I haven’t done anything yet. The notification stays the same. Does this feature have anything to do with indexables? I did not activate the indexables feature when you updated to the 14.0. Because I don’t want to use indexables feature. So, if this has something to do with the indexable feature, I don’t want to confirm this SEO Data Optimization in any way.

Hi @alimir Ok. Thanks. Hope this doesn’t cause security issue. Because I was blocking all requests that started with /wp-admin . Anyway.

Recently I noticed that some users are abusing the cookie method. They clean the cookies and like them again and again. So I will change the cookie log option. But I cannot change the cookie log option due to some issues:

3. There is no IP option in the logging method section. There are only 3 options.(no log, cookie, username)

4. Also, when you change the log type, all the old likes disappear.

I just only hide my domain address. (example.com) I haven’t changed anything else. And I didn’t name my files like aa, bb.

Here a raw deails:

Module 404 Detection
Type Notice
Description https://example.com/wp-aa.php?up2018info=1
Timestamp 2019-11-15 10:46:57
Host 193.106.30.99
User
URL https://example.com/wp-aa.php?up2018info=1
Raw Details
Hide Raw Details

id => 186
module => four_oh_four
type => notice
code => found_404
timestamp => 2019-11-15 07:46:57
init_timestamp => 2019-11-15 07:46:57
remote_ip => 193.106.30.99
user_id => [empty string]
url => https://example.com/wp-aa.php?up2018info=1
memory_current => 26732552
memory_peak => 26806824
data => Array
SERVER => Array
SERVER_SOFTWARE => Apache
REQUEST_URI => /wp-aa.php?up2018info=1
LSPHP_ENABLE_USER_INI => on
PATH => /usr/local/bin:/usr/bin:/bin
TEMP => /tmp
TMP => /tmp
TMPDIR => /tmp
PWD => /
HTTP_ACCEPT => */*
HTTP_ACCEPT_ENCODING => gzip, deflate
HTTP_CONNECTION => keep-alive
CONTENT_LENGTH => [empty string]
HTTP_HOST => example.com
HTTP_USER_AGENT => Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36
HTTP_X_HTTPS => 1
REDIRECT_UNIQUE_ID =>
REDIRECT_SCRIPT_URL => /wp-aa.php
REDIRECT_SCRIPT_URI => https://example.com/wp-aa.php
REDIRECT_HTTPS => on
REDIRECT_SSL_TLS_SNI => example.com
REDIRECT_STATUS => 200
UNIQUE_ID =>
SCRIPT_URL => /wp-aa.php
SCRIPT_URI => https://example.com/wp-aa.php
HTTPS => on
SSL_TLS_SNI => example.com
SERVER_SIGNATURE => [empty string]
SERVER_NAME => example.com
SERVER_ADDR => example.com host adress
SERVER_PORT => 443
REMOTE_ADDR => 193.106.30.99
DOCUMENT_ROOT => /home/example/public_html
REQUEST_SCHEME => https
CONTEXT_PREFIX => [empty string]
CONTEXT_DOCUMENT_ROOT => /home/example/public_html
SERVER_ADMIN => [email protected]
SCRIPT_FILENAME => /home/example/public_html/index.php
REMOTE_PORT => 46164
REDIRECT_URL => /wp-aa.php
REDIRECT_QUERY_STRING => up2018info=1
SERVER_PROTOCOL => HTTP/1.1
REQUEST_METHOD => GET
QUERY_STRING => up2018info=1
SCRIPT_NAME => /index.php
PHP_SELF => /index.php
REQUEST_TIME_FLOAT => 1573804016.9814
REQUEST_TIME => 1573804016

Thanks for your interest and help.

No, that IP address isn’t mine. That’s IP of the person who attacked my website. Everyone should ban this IP. It’s a very dirty host. (https://www.abuseipdb.com/check/193.106.30.99)

I understand from your answer that the danger is gone. Then there’s nothing to worry about?

I checked the error_log file from the Cpanel by converting it to txt format. Only have SSL notifications. The last notification on 4 November. No matches.

Could be. What really worried me was a dirty host’s attempts on my site:

404 Detection Notice https://example.com/wp-aa.php?up2018info=1 2019-11-15 07:46:57 – 9 hours ago 193.106.30.99 View Details
404 Detection Notice https://example.com/wp-bb.php?up2018info=1 2019-11-15 06:25:45 – 11 hours ago 193.106.30.99 View Details
404 Detection Notice https://example.com/wp.php?up2018info=1 2019-11-15 04:50:56 – 12 hours ago 193.106.30.99 View Details
404 Detection Notice https://example.com/wp.php?up2018info=1 2019-11-15 04:50:56 – 12 hours ago 193.106.30.99 View Details

Fatal Error and this attack timing are the same.