BPS and Nginx

[AITpro Admin]

The BPS Security Log entries are created using the htaccess ErrorDocument directive code in the root htaccess file.  BPS Pro Plugin Firewall AutoPilot Mode checks the BPS Security Log file contents for any blocked frontloading plugin script errors and automatically creates Plugin Firewall whitelist rules based on those Security Log entries.  Since you are not using a Root htaccess file then that is why you are not seeing any other Security Log entries being logged.  If you are using the BPS Pro Plugin and using the BPS Pro Plugin Firewall feature then you will need to manually create whitelist rules for any frontloading plugin scripts that are being blocked. The simplest way to check for plugin scripts that are being blocked and need to be whitelisted in the Plugin Firewall whitelist text area is to use the Google Chrome Developers Tool > click on the Console tab > then navigate your website and click on all the main pages. ie Contact Form page, Gallery page, etc.  You will see 403 errors displayed in the Google Chrome Developers tool Console tab if any 403 errors are occurring. You would then grab the plugin’s js script path and add it in the BPS Pro Plugin Firewall whitelisting text area.

[bbmedia]

Ok, thanks.

I will keep this in mind.

[ChrisN]

Hey there,

Posting here since it seems to be the most relevant thread. If not, let me know and I’ll post anew/ feel free to merge.

I just purchased the BPS pro version and I’d be interested in any pointers to the .htaccess content from BPS Pro that would need migration to nginx server directives. I’m on pure nginx, self-hosted and don’t mind looking into this.

During BPS Pre install, htaccess was disabled. No htaccess files found in the WP tree.

Would it be enough to just re-enable it, have BPS generate the htaccess files (ignored by my nginx setup) and translate the contents of any generated htaccess to nginx server directives, restart nginx, check func, monitor htaccess for changes and add/remove htaccess rulesets to nginx in the future?

Thanks,
Chris

[AITpro Admin]

@ ChrisN – Over the years I have debated creating a custom solution for pure NGINX setups, but the issue is that only a handful of people have pure NGINX setups.  I will revisit this issue again after BPS Pro 15.2 (sometime today) and 15.3 (ETA 14+ days) are released.  I decided to release 15.2 early so that I am not rushing to get the new MScan rebuild/redesign completed in 15.2 and pushed the MScan rebuild/redesign to 15.3.

Since NGINX does not use frontend Apache .htaccess files and NGINX rules are created in the backend NGINX .conf file this adds an additional complication/complexity with automating a pure NGINX solution from within BPS.  Yes, BPS can generate converted Apache .htaccess code for NGINX, but adding that converted code is going to require the manual step of manually copying those converted rulesets into the nginx.conf file > https://www.nginx.com/resources/wiki/start/topics/examples/full/

So to answer your questions – Yes you can enable htaccess files on the BPS Pro > Setup Wizard > Setup Wizard Options tab page > Enable|Disable htaccess Files > htaccess Files Enabled.  Yes the htaccess code/files will be ignored by NGINX.  Or just leave all htaccess features disabled and wait until I have available time to work on a pure NGINX solution (BPS Pro 15.4 – ETA 30+ days).

[ChrisN]

@ AITpro Admin – in which case I will patiently await BPS Pro 15.4. Sounds good.

I do believe that anyone who has a pure nginx install should be willing/ capable to go the manual way.

I for one would love the directives in a domain.bps.conf file that I can then monitor for changes, review and add a copy/.. as an include directive to the main nginx domain.conf file. I’m not sure if that’s a viable solution since I don’t know how often htaccess files are changed through BPS. Might not be the best option after all.. But I’m sure there’s a sensible solution to that specific issue.

Let me know if you want me to beta test and thanks for the quick reply!

[bbmedia]

One of the key structural advantages of NGINX (and the reason why it can be so fast) is that it centralises for the server a lot of things that Apache does at a site/directory level, thereby reducing the amount of processing and disk activity require

I draw your attention to the following:

“Specifically, improved performance is one of the main advantages compared to the .htaccess directory-level configuration system. In the case of standard Apache setups that accommodate .htaccess in any one directory, the server assesses the files in every parent directory leading to the file requested, whenever a request is made. Any .htaccess files found throughout this search will be read before being interpreted.

So, NGINX can serve requests in less time, due to its single-directory searches and file-reads for every request. Of course, this is based on files being located in a directory with a conventional structure.

Another benefit NGINX offers with directory-level configuration relates to security. Distributing access also leads to a distribution of security responsibility to single users, and they might not all be trustworthy. When administrators retain control of the whole server, there’s less risk of security-related problems which grant access to people who can’t be relied upon.”

and

“With NGINX designed to parse requests as URIs rather than filesystem positions, it makes for simpler functionality in various areas. Specifically, in the following server roles: web, proxy, and mail. This means NGINX is easily configured by laying out appropriate responses to varied request patterns, and NGINX only checks filesystems when it’s prepared to serve the request. This is why it doesn’t implement .htaccess files.”

We use a server management service to manage our NGINX servers – most of the security is handled by core NGINX directives which already takes care of almost all of the security common to each website.

So as far as I understand, it requires a different approach to the way security is implemented on NGINX servers. Of course that doesn’t rule out creating specific domain .conf sets , even if they duplicate much of what is already being taken care of, but it may (or may not) add additional load where it is not required.

The power of BPS Pro is that it primarily operates htaccess specifically for Apache systems.

We use BPS Pro on a small number of sites which we host on a Cpanel / Litespeed setup where the client wants us to handle their email accounts as well (simply because it works out more cost effective for some businesses that way).

We only use BPS Pro (but only for the non-htaccess related features) on a very few of our NGINX setups where we haven’t got around to replacing it with other solutions that offer similar non-htaccess security functionality, but with greater ease of operation.

[AITpro Admin]

@ bbmedia – “The power of BPS Pro is that it primarily operates htaccess specifically for Apache systems.” – htaccess security protection is only a very small fraction of the website security protection that BPS Pro offers > BPS Pro Features.  Also BPS Pro works on every type of server and the only feature that is currently not working on “pure” NGINX systems is htaccess files since NGINX does not automatically convert Apache htaccess files.  A lot of people have NGINX on the frontend (Reverse Proxy) and Apache on the backend and htaccess files work fine on that setup.  Once the new “pure” NGINX htaccess file/code conversion to NGINX rulesets feature is added in BPS Pro 15.3 then people who have “pure” NGINX setups can do the manual steps required on “pure” NGINX systems.  Unfortunately, the entire process cannot be automated from within BPS Pro since NGINX does not offer distributed configuration files like the Apache .htaccess distributed configuration files. Accessing the nginx.conf file requires root level NGINX server access.

[Rami M]

Any update on this?  “Once the new “pure” NGINX htaccess file/code conversion to NGINX rulesets feature is added in BPS Pro 15.3 then people who have “pure” NGINX setups can do the manual steps required on “pure” NGINX systems.”

[AITpro Admin]

@ Rami M – I installed and configured a pure NGINX testing server and spent several days testing things.  Unfortunately, BPS Pro features like the Plugin Firewall and the Setup Wizard AutoFix|AutoSetup will not work on NGINX because NGINX does not offer a frontloading server configuration file like Apache does (.htaccess files).  BPS Pro cannot access the nginx.conf file to update the nginx.conf file code.  What that would mean is that someone would have to manually update the nginx.conf file every time their IP address changes (Plugin Firewall) or any time they install new plugins or themes that require Setup Wizard AutoFixes or AutoSetups.  I already know what the results of my efforts would be – anyone with a pure NGINX setup would be complaining to me constantly about having to do everything manually any time they change anything on their website.  One of the best overall features about BPS Pro is that everything is automated.  That would not be the case on a pure NGINX setup.  The amount of time required to create the NGINX code (PHP processing code – not just htaccess code converted to nginx code) in BPS and the amount of complaints I will definitely get make this a no-go for now.  I may decide to tackle this monumental headache in the future, but I am not going to do this any time soon.  Right now I am working on the long overdue UI|UX redesign of BPS Pro.  Maybe if a put this off long enough, NGINX will finally create a frontloading server configuration file, which IMO should have been done years ago.

[Rami M]

Just saw your reply. Thanks for your help. UI|UX redesign is great news.

[Author]

Posts