List of security measures taken for this site
Spam Bot Attack
Eagle-rock.org was established in December 2011. After an upgrade in September 2015 I neglected to include security settings that blocked users from creating accounts. In September 2015 the security hole created by this was located and targeted by spam bots[1]. Spam bots have gotten sophisticated enough to create an account and post articles. Once a spam bot gets in, it automatically calls other bots until there is a tidal wave of spam bots hammering the website. I learned this lesson the hard way.
A lesson about attitude
Working on this site is a way to build a relationship with God substantially. Work with God together on the page, grow your relationship and grow as a person. That's the inner meaning of this site for those working on it and it will also prevent big mistakes.
And Abraham spent weeks to prepare the animals, learn about the software, prepare the offering place, learn how the new server works, cut the animals, get rid of annoying bugs in the software, and after he cut the big animals in two he was very tired, and after these weeks of work he was exhausted, and even his wife was shouting at him why he wasn't simply there for her at home, and then he had to make one last cut, but because he was so tired of everything he forgot to add only two lines of code... And then the black angels took over. —John Eagles 9/23/15
Restrict Permissions
The way to guard against Spam Bots and similar malicious code is to restrict permissions[2] that deny bots the ability to create new user accounts. These restrictions should be placed on all Wikis as standard security procedure. User permissions are set in the LocalSettings.php file. Be sure the following two lines of code are in the file before the wiki is activated. Do not download LocalSettings.php directly to the wiki before adding these permission restrictions:
$wgGroupPermissions['*']['createaccount'] = false;
This setting blocks nonusers from creating accounts.[3] All accounts therefore must be created by an Administrator.
$wgGroupPermissions['*']['edit'] = false;
This setting blocks nonusers from editing pages. In order to edit a page, a user must get an account created by an Administrator.
File Upload Security
To prevent users from uploading files with malicious code to the Upload Directory, place a .htaccess file inside the 'images' directory with this content[4]:
# No php execution in the upload area php_admin_flag engine off
Image Directory Security
The upload directory needs to be configured so that it is not possible for an end user to upload and execute other scripts, which could then exploit access to your web directory and damage your wiki or web site.
Set the /images folder to have permission "755"
Backups
A primary security measure is to make and keep regular backups. MediaWiki stores important data in two places:
Database:
Pages and their contents, users and their preferences, metadata, search index, etc.
File system:
Software configuration files, custom skins, extensions, images (including deleted images), etc.
Mysqldump
Database backup is performed using mysqldump[5] from the command prompt. To backup the eagle-rock.org wiki connect to the server through SSH and run this command:
mysqldump -h localhost -u eaglerp5_lfpCgGH -p --default-character-set=utf8 eaglerp5_lfpCgGH > backup.sql
Run mysqldump with Cron
Schedule regular backups with the time based job scheduler Cron[6]. The following code will write a backup file with the weekday in the filename so we will have a rolling set of backups.
Administrators should store backup copies offsite
Just to be safe, administrators could keep backups copies offsite.
