Broken LAMPS; WordPress (PART 4)
In parts 1-3 of this series, we have prepared an apache webserver to act as the host for a WordPress installation; it is now time to install WordPress and apply application-level configurations.
As WordPress Installation and configuration articles abound on the internet, I will not waste my time or the reader’s time covering that which has been arduously documented in minute detail elsewhere.
We will begin just before WordPress installation; at this point, the actual application is in place within the /var/www/html directory, and ownership has been adjusted. We have created our database, database user, and proper privileges on the database for the user within the MySQL host. It is now time to edit the /var/www/html/wp-config.php file and set some parameters. We will deal with the basics of database connectivity, but we shall also change the “Authentication Unique Keys and Salts”; one can generate new keys and salts from the WordPress API site.
In the last verse of this overly long stanza, we shall change the WordPress Table Prefix to something, not the predictable and targetable “wp_”, perhaps “wptest1234_”. (DO USE YOUR OWN HERE)
# sudo nano /var/www/html/wp-config.php
# we will set the following to match our database creation
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'database_name_here' );
/** MySQL database username */
define( 'DB_USER', 'username_here' );
/** MySQL database password */
define( 'DB_PASSWORD', 'password_here' );
/** MySQL hostname */
define( 'DB_HOST', 'localhost' );
# ------------------------------
# Begin Unique Keys and Salts
# Comment out existing; paste in new from https://api.wordpress.org/secret-key/1.1/salt/
#
# GET YOUR OWN KEYS - DO NOT COPY / PASTE THESE
#
#define( 'AUTH_KEY', 'put your unique phrase here' );
#define( 'SECURE_AUTH_KEY', 'put your unique phrase here' );
#define( 'LOGGED_IN_KEY', 'put your unique phrase here' );
#define( 'NONCE_KEY', 'put your unique phrase here' );
#define( 'AUTH_SALT', 'put your unique phrase here' );
#define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
#define( 'LOGGED_IN_SALT', 'put your unique phrase here' );
#define( 'NONCE_SALT', 'put your unique phrase here' );
define('AUTH_KEY', '{D fKz4zPJDbH3}aO2A!FojA3H,XI0A+khy;tm-bv#{AbuySV+6#1h)A4;Axr[v');
define('SECURE_AUTH_KEY', 'UA=-I9H2X.zqRAM|o)xvNnr;$NpO9|3AwA2R;H(6sv_>IzU}`7}6OEV2hGglvf#W');
define('LOGGED_IN_KEY', 'd,+7Vio;#}@x5Z@X(,]9[TPZLy2^LyP1{A~gAs+QxS0C#]sV,@pLZXWQq.`~k2wH');
define('NONCE_KEY', ']A}C xsq|Fq%l4:{!QtbQgZ-nF.y~Js-mAbSe[y6QZ_2dB,X-W(yx?-nEw_/o:P)');
define('AUTH_SALT', '4mO[-ovv-[wtP{+-M,}8N|VcNWs .cgf>%#2AIp[@zxKEq{=WUPT+r|:nI{f`wf2');
define('SECURE_AUTH_SALT', '6|yAH##aD9*`y-*S5|J5y+H}EPBm^hiYctIFAtA`s?]f,~p{r~}{=p--4~3Af!*G');
define('LOGGED_IN_SALT', '>yS`-1+|xyuYz?s,J`7KD$InS|mp_9Qkcr.mYlwAZnsq0v..Ym+d1 0.WB7 /q8;');
define('NONCE_SALT', '^,4,$tq/x#8wWSq~APRp7U%aW*38SBpP?c6X3?$AsmZ1W%{5sR(Kop@Yq`T6eS4(');
# Change the wp table prefix.
# DO FOLLOW THE NAMING CONVENTION.
$table_prefix = 'wptest1234_';Once we have saved the file, it is time to run the WordPress install script. We have set this specific environment up as a single host / WordPress installation, and thence our installation URL will be https://test.techhell.org/wp-admin/install.php.
Browsing to the indicated URL we are presented with a choice of language, and upon that selection, we are presented with a configuration screen:
In the Site Title, we will place our site name for a Username; one suggests something NOT ADMIN or root, or any classic administrator names. It is STRONGLY suggested that a STRONG password be used. If remembering a strong password is problematic, a password manager is highly recommended.
Set an email address to receive notifications from wordpress, and click install.
If all is well, one will be directed to login with the credentials previously provided.
After a successful login we have the administrators dashboard.
One of the many myths of WordPress security is that moving the wp-admin and wp-login pages will enhance resilience against brute force attacks. It may provide a small inconvenience for the simplest attacks, but for anyone with a website scanner, this is somewhat of a non-event. One may very well break any other plugins that depend on these files being in the expected position in moving these. In my opinion, (Remember the old saying about Opinions and Arses.), the best way is to install a Web Application Firewall plugin.
Popular WordPress WAF’s are:
Choice of plugin is left to the reader, installation of a WAF plugin is considered MANDATORY. Use of a free or paid service is left to the reader and thier budget.
Whilst we are talking WordPress Security, (Yes some do consider that an oxymoron.), let’s look at that fallacy that has become Internet Lore:
Myth: WordPress is an Insecure Platform.
The most damaging WordPress security myth is that WordPress itself is insecure. This is not true. WordPress is the most popular content management system globally, and it didn’t get that way by not taking security seriously.
The truth is that the biggest WordPress security vulnerability is its users. Most WordPress hacks on the platform can be avoided with a little effort from the site owners. Keep your system software updated. (Mentioned prior, “Over 40% of all PHP websites use version 5.6 or older“, Keep your WordPress core updated, keep your plugins updated.
Nearly 80 percent of actual security threats and infections are due to a vulnerability caused by outdated software/password exploits.
To combat these, my recommendations are:
- Require strong passwords.
- Enforce multi-factor authentication for any account over the user level.
- Ensure proper backups are in place (and TEST THEM).
- Enable auto-updates for core and plugins.
- Send WAF alerts to a group mailbox that is READ.
- Log all web traffic and perform analysis on this. (Not just google analytics).
- Review WAF reports regularly.
