Gridvision.net is built on a foundation of Ubuntu Linux, Nginx, and ModSecurity, with WordPress as our content management system, and with Project Honey Pot providing some clever blacklist features in exchange for using our site to identify and catalog evil spambots.
Other than a few details we prefer to keep to ourselves, this is how we did it:
Our core is Ubuntu 18.04 on a minimalist server we spun up at Digital Ocean. We locked the server down with UFW immediately upon boot, and made some dramatic changes to our SSH configuration which we prefer not to detail here. Without giving away too much, we recommend sys-admin usernames that are random strings rather than any Proper Names or anything similar to them, and totally bolt down your SSH services. It turns out our SSH server gets attacked every few seconds while our website receives an attack every few minutes.
We use Nginx instead of Apache, and we’ve found both the software and the Nginx team to be user friendly, advanced, and cutting edge. When Nginx put out the document, “ModSecurity 3.0 and NGINX: Quick Start Guide” on how to incorporate ModSecurity into the Nginx way of doing things, we jumped in without reservation. You can find the Nginx tutorial at this link. Use this link to a treasure trove of How-To documentation regarding Nginx/ModSec/Project HoneyPot all in one location.
Compiling the Shared Object Libraries
Our server couldn’t handle the compile demands of building the ModSecurity shared object library, so we had to compile on a separate machine with slightly more RAM. This required matching our server version of Nginx with the one to be used in compile efforts, and also matching the machine architectures. We used the opportunity to upgrade Nginx on our production machine, and were pleasantly surprised at how easy it was. Backup first though. Particularly config files. As both machines were spun up at Digital Ocean, and nearly identical, we didn’t need to cross-compile. Everything went smoothly with a bit more RAM. Note that Nginx Plus is a paid version of the Nginx server software which gives users the option of installing pre-built binaries if compiling isn’t something you want to get into.
Once the ModSec shared-object library compiled, we rsync’d the library and its various files/directories into our /usr/local directory in production. We then followed Nginx instructions for compiling and positioning the Nginx/ModSec Connector Dynamic Module that get the two working together.
After a few quick [nginx -t] and [nginx -s reload] commands we had the entire setup active and running.
Within the Nginx instructions was info on Project Honey Pot. What a marvelous set of tools! And the administrators over there are to be commended for creating work for the Greater Good of all Mankind.
Christian Folini’s tutorials on tweaking ModSec with Nginx are here. He succinctly explains storage directories, debug modes, log entries, and fundamental operations of ModSec. From his notes, we quickly found the crs_exclusions_wordpress=1 setting, and activated it for our WordPress site. There is a similar catchall (catchmost) setting for you Drupal users out there. Everything needed to operate ModSec is in Christian’s tutorials.
At this point, we created an account at Project Honey Pot, received our personalized honeypot script, and “blacklist” code, and went to work on this most recent piece of kit in our fight against the evil demons of the net and their spambots.
Using Christian Folini’s notes, we learned how to identify the rules causing our honeypot activation to fail, and we made the appropriate adjustments. ModSec has about 200 rules in their core ruleset, and one of those was catching the honeypot script. (Identify the rule in the ModSec logs that is triggering when your honeypot activation attempt fails, and follow Folini’s notes on how to modify or turn off that specific rule). If you configured according to the Nginx ModSec document mentioned above, you will be modifying your ModSec config file located in /etc/nginx/modsec/. We also tweaked a few settings that were causing our online e-commerce site to incur false alarm security blocks.
After those few rule changes were made, we then stumbled upon the final piece of the pie: The WordPress HoneyPot Toolkit by Jeff Sterup. What a perfect piece of work to round out our configuration!
Nginx provides excellent instructions for getting Project HoneyPot’s blacklist tools integrated into one’s site, but the plugin by Jeff Sterup is so thorough, we made the exception of installing it rather than writing our own code. It is a very nice piece of work, and includes features that every WordPress site can benefit from. Open your Project Honey Pot account first, then install Sterup’s plugin.
Without going into a lot of our specific settings, this short overview is how we harnessed the tools of world-class programmers who have written code for fighting the Good Fight, and made it available to the world. If I’ve had any reservations about the future of mankind, it is the people and organizations mentioned above that give me a pinch of optimism in what has become a rather cynical, if not downright cranky, outlook. Special thanks to the Admins at Project Honey Pot for getting us through the project.