chrisleck

Well that was fast! I just saw the update, installed it, and Anti-Malware ran fine. Will try it again later,perhaps at random times over the next few days. Thanks!

—Chris

One advantage of downloading the signature file each time is be that it could contain the latest updates. A background anti-malware process running on the host is a good thing; being notified of actions taken would be a good thing too.

[No additional info, I just forgot to enable email notification of updates to thread.]

I had the same issue. Setting the PHP memory limit to 368Mb seems to have gotten rid of the error. However, 368Mb is way too high an allocation for one of my sites using a limited account, so I’m looking for alternatives.

The Anti-Malware signatures file is gone again. I haven’t found its deletion in the file change logs. NinjaFirewall itself hasn’t reported it. Fortunately, Anti-Malware is not why I’m evaluating NinjaFirewall. All else seems fine.

@nintechnet: Success! I replaced the file, then successfully ran two scans. Thank you!

Uploading the file through file manager got it flagged as ‘YARA.Safe0ver_Shell__Safe_Mod_Bypass_By_Evilc0der_php.’ Maybe something else on my server also interpreted the file as malicious and deleted it. I have another, similarly-configured site with both NinjaFirewall and Jetpack. Jetpack updated without losing the signature file on that site.

—Chris

@nintechnet, thank you for your quick reply and the link to the signatures file! I’ll get those replaced and report back.

Yes, it’s a bit weird. I don’t know for sure that that Jetpack did this. However, I found the deletion in the middle of an iThemes file change log after a Jetpack update. Everything else was about the update, so it seems to point at Jetpack. The deletion itself was silent, the update was not interactive.

Jetpack isn’t supposed to have any malware functionality. It would have no business messing with NinjaFirewall files. I’m already a little annoyed with Jetpack lately; today’s update fixed one problem.

—Chris

@pronl
You are correct, a restore was expedient and the site is back up. Thank you very much for your help! While troubleshooting took far longer than a restore, it was a good experience for me. This isn’t may day job, which probably is obvious.

A correction is in order here: The restored public_html/.htaccess is the same as as after the failed update. It does not appear that the iThemes Security Update overwrote it with a faulty version, as I wrote above.

I plan to skip this update. If it happens again on a later update, I’d be inclined just to run a restore instead of trying to understand or fix it. It would be good to know if this is an odd, one-off failure or if it’s something that I should expect from the product.

Cheers,
Chris

There’s a .htaccess file in the public_html/wp folder. It seems to look OK, but I can’t be sure. Not shown is the iThemes Security section.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /wp/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /wp/index.php [L]
</IfModule>

# END WordPress

What I tried prior was Method I from Giving WordPress Its Own Directory. It didn’t work, but maybe I’ve made an error somewhere. Method II requires WP to be running. Will need to sleep on this. Thanks for your help!

Summary: It appears that the iThemes Security Update overwrote public_html/.htaccess, leaving out references to where WP actually is installed. Recreating .htaccess as it presumably was prior to the update didn’t fix the problem.

• This reply was modified 7 years, 11 months ago by chrisleck.
• This reply was modified 7 years, 11 months ago by chrisleck.

I changed public_html/.htaccess to the following with no change, still loads a blank page:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(www.)?marchmusicmoderne.org$
RewriteCond %{REQUEST_URI} !^/wp/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /wp/$1
RewriteCond %{HTTP_HOST} ^(www.)?marchmusicmoderne.org$
RewriteRule ^(/)?$ wp/index.php [L] 
</IfModule>

Server logs don’t show errors for my access. They do show that the downed site now is attracting international ‘visitors.’

Alternately, I’m wondering if .htaccess got hosed and there wasn’t an index.php. IIRC, the instructions were used from https://codex.www.ads-software.com/Giving_WordPress_Its_Own_Directory to move the WP directory from root to /wp. .htaccess may have created from this example:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(www.)?example.com$
RewriteCond %{REQUEST_URI} !^/my_subdir/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /my_subdir/$1
RewriteCond %{HTTP_HOST} ^(www.)?example.com$
RewriteRule ^(/)?$ my_subdir/index.php [L] 
</IfModule>

Will try this and see what happens.

@pronl, thank you very much for your reply and suggestions!

The evident problem is that /home/marchmus/public_html/index.php has gone missing. I’m searching for a backup or a way to recreate it.

Any ideas here? I have DB backups, but not sure about the file system.

The server logs also show the missing index.php as the error (and also show someone trying to look at the file system).

Here’s the .htaccess file:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Thanks again!
–Chris

Thanks, I figured it out. FWIW, my site is https://chrisleck.com/wp/ if you want to look at it.