rebornhairppp

Hi Steve,

Thanks for responding so quickly!

I completely understand. Yes, it’s true the rules need to be parsed only once if I wasn’t going to enable or disable certain features of a plugin. Every time I make a tiny change, I have to first remember to enable .htaccess and then modify the virtual hosts file.

Given my concerns, I guess I have to eat the bullet.

Question #1: Once I transfer all my rewrite rules under the <Directory root path> block, I should disable .htaccess to prevent apache for having to read it?

Question #2: I have an https permanent redirect in my port 80 virtual host file. Do I include the rewrite rules in the port 80 or port 443 virtual host file? I am thinking it’s the port 80 file.

Thanks again Steve!

All my best,

Joe

Hi Slava,

Here is the debug report:

Versions:
WordPress: 4.9.2
WordPress MS: No
PHP: 7.2.2-1+ubuntu16.04.1+deb.sury.org+1
WP Mail SMTP: 1.2.4

Params:
Mailer: gmail
Constants: No
Client ID/Secret: Yes
Auth Code: Yes
Access Token: Yes

Server:
OpenSSL: Yes
PHP.allow_url_fopen: No
PHP.stream_socket_client(): Yes
PHP.fsockopen(): Yes
PHP.curl_version(): Yes

Debug:
GuzzleHttp requires cURL, the allow_url_fopen ini setting, or a custom HTTP handler.
GuzzleHttp requires cURL, the allow_url_fopen ini setting, or a custom HTTP handler.
Error while sending via Gmail mailer: GuzzleHttp requires cURL, the allow_url_fopen ini setting, or a custom HTTP handler.
GuzzleHttp requires cURL, the allow_url_fopen ini setting, or a custom HTTP handler.

According to phpinfo() my curl support is enabled otherwise I would run into some trouble possibly an “Update Failed: Download failed. No working transports found” error if I updated any plugins or themes.

By default, my php.ini comments out the curl extension as in ;extension=curl. I am not sure if this setting should be uncommented.

Thanks again for all your timely help!

All my best,

Joe

Hi Slava,

Thanks for getting back to me so quick. I really appreciate your timeliness!

I am running PHP 7.2 on Apache. I am on a dedicated VPS.

All my best,

Joe

Hey wpsolutions,

Just saw your new comment come through.

YES! We are on the same work page!!

Take care man and God bless you guys. I will mark this thread as resolved!

All my best,

Joe

Hi mbrsolution,

Hmm I think you have a good point, though I am adamant of switching over to the older PHP version. Everything else works fine, so I might just keep it for the time being since I made substantial progress thus far.

Again, Whois can always be utilized on the web.

Thanks again for still trying to diagnose this issue.

All my best,

Joe

Hey mbrsolution,

I was originally running PHP 7.0 without any problems with the Whois feature. Looking more closely at my timeline of changes, I decided to upgrade to PHP 7.2 removing all PHP 7.0 files and folders on 12/17/2017. Since Ubuntu 16.04 doesn’t have a repository for PHP 7.2, I had to download the PPA repository ppa:ondrej/php from https://launchpad.net/~ondrej/+archive/ubuntu/php.

When I look more sharply at the PHP error log, I noticed the first time I ran Whois after the PHP 7.2 upgrade with this white screen of death problem was on 1/5/2018. My timeline of changes shows an update for PHP 7.2 on 1/14/2018. I know I said “this function worked prior to 2018”, but I think taking all this into perspective, my calculation was off. My apologies.

In reality, I have strong reason to believe the initial PHP 7.2 upgrade back on 12/17/2017 caused the hiccup. I don’t recall using the Whois Lookup in 2017 after the PHP upgrade until sometime in the beginning of 2018. My error log showing the first instance of this hiccup on 1/5/18 seems to correlate with my recollection.

In summary, the cause of this hiccup is obviously not the PHP 7.2 update conducted on 1/14/2018, since there was already a problem with this feature on 1/5/18. Rather, it was most likely the PHP 7.2 upgrade on 12/17/2017.

It’s strange that all other features work as expected on PHP 7.2 just not the Whois.

Any help would be appreciated! Again, don’t sweat it if you can’t find a resolution. I think I can live without this function!

Take care my friends and I hope the team is in good spirits!!!!!

All my best,

Joe

@wpsolutions – One other thing I forgot to mention and I think it’s quite important. If you can add this on your to do list to incorporate in future updates that would be incredible!

I noticed blacklisting IP addresses under 404 event logs can be extremely laborious if there are many different IPs appearing on multiple pages. I just cleared my event logs three days ago, and I already have 11 pages of new IPs which I need to blacklist. The problem is the bulk action option to blacklist the IPs are page-specific meaning I have to click on the next page to blacklist any new IPs not appearing on page 1, or 2, or 3…

Would there be a way to permanently or temporarily with a click of a blacklist or temp block button block ALL IPs appearing on multiple event log pages similar to the delete all 404 event logs button?

Thanks wpsolutions again!

@wasca – Thank you again. That’s what I exactly did! ??

@wpsolutions – I did a test run by removing the Require All Granted syntax from the .htaccess file while enabling 6G and 404 detection. The good news: I only see NEW IP addresses in my 404 Event Log. The bad news: as soon as I blacklist those NEW IP addresses, the Require All Granted syntax gets automatically added in my .htaccess file under the Apache >= 2.3 section.

As such, I have to manually jump into the .htaccess file and remove that syntax. I have to manually perform this step each time I blacklist a NEW IP address given that both the 6G firewall and 404 detection features are ENABLED!

Do either of you have recommendations to automate the process of removing the problematic syntax every time a NEW IP address is blacklisted?

Thank you again, wpsolutions and Wasca for your utmost assistance and kind diligence. My monetary support was well spent for your plugin.

As a warm reminder, @wpsolutions, if you can be so kind to keep me under your radar (I know you have mountain of users and requests you need to attend to) about any updates on when your plugin will support public IPv6 address I would be graciously thankful!

Take care like always and God Bless you too for a job well done!

Hey Wasca,

Just want to thank you from the bottom of my heart. You’re an absolute life saver.

I went ahead and disabled the 6G ruleset and I don’t see any previous blacklisted IP addresess; only new IP addresses are appearing

Quick question. Would it be better from a security standpoint to enable 6g and disable 404 detection?

Much love and thanks brother!

God bless you!

Hey wpsolutions,

I tried disabling 6G and deleted the IP addresses with the require not ip syntax in my .htaccess file.

No luck. I still see the same IP addresses being recycled in the event log history like 179.43.146.230 even though I deleted the require not ip syntax for this particular address.

Argghh!! Hope we can find a resolution. This is so irritating.

Hey wpsolutions,

Sorry for the large influx of messages. I just blacklisted a new IP address 62.210.105.116 and noticed in my .htaccess file that same address appears twice like the other one in two places: deny from 62.210.105.116 and require not ip 62.210.105.116. All the other previously blacklisted IP address also have the require not ip syntax.

All and in all, my blacklisted IP addresses are showing up in two sections of the .htaccess file while I think they should only show up under one, which is the deny from.

The require not ip syntax gets added under the section <IfModule mod_authz_core.c> in the .htaccess file for your info.

Hopefully this analysis sheds some light on the culprit.

Hey wpsolutions,

I think I found what’s causing the issue specifically for the blacklisted IP address 93.174.93.71. When I check my .htaccess file, I see two syntaxes for this address. One says Deny from 93.174.93.71 and the other Require not ip 93.174.93.71. I am not sure why the require not syntax is getting added.

Maybe it’s because when the IP addresses appear on my event log, some are blacklisted while others are not. The order is mixed up as there are gaps. For example, the above IP address was on the 1 of 50 pages on my event log. It was in the middle labeled as blacklisted under the Locked Status column, but there were also other new/non-blacklisted IP addresses on top and on the bottom of that one.

Instead of having to select the new addresses and check the blacklist option, I checked the box on the top to select ALL addresses on that page including the addresses that were previously blacklisted to blacklist everything all at once. I notice I have to perform this action twice, that is check the box to select everything, click blacklist, click the popup OK box. These same steps are repeated a second time, otherwise, only a few addresses are blacklisted not the entire list of fresh ones.

I think what I will do is delete all the blacklist addresses and start fresh. I will blacklist one address and monitor the .htaccess file to see what gets logged.

I will report my findings.

Thanks again!

Hey wpsolutions,

Do you know if more blacklisted IP addresses results into slower performance due to apache having to read more content in the .htaccess file?

Hey wpsolutions,

I also just noticed something really bizarre. Certain IP addresses, like 163.172.153.12, are being “temporarily blocked” not blacklisted without my approval. I didn’t even select “temp block IP” from the action dropdown box.

My 404 detection options are as follows:
1. Enable 404 IP Detection and Lockout: Checked
2. Time Length of 404 Lockout (min): 60
3. 404 Lockout Redirect URL: https://127.0.0.1

I will try disabling 6G since that’s the active one.

Hey wpsolutions,

I see. Do you know if I need to modify my apache.conf virtual hosts file? My presumption is once an IP address is blacklisted, I shouldn’t see that same address pop up in my event log, correct? Any IP address that appears in the event log are only the ones which I haven’t blacklisted, correct?

Also, I am not sure if it’s normal to have a “blank” Locked Status column when the event log is exported via cvs.

I strongly believe my Apache directives are set up properly. I just don’t know if I need to tweak Apache to make this recurrence vanish.

Thanks for your help as always!