Category: Information Technology

Recent Posts

File permissions on computer systems have long been the go-to security mechanism to protect files and restrict access for authorized use only but file permissions can only work when they are configured correctly. WordPress, like all other client/server web content platforms has files that are presented to a webserver which makes them accessible to a browser. These files, if configured incorrectly, can introduce malware into WordPress sites or provide attackers a way to escalate privileges.

WordPress.org publishes strict hardening guidance around file permissions here. To make configuring WordPress permissions easier, I wrote a script to automate the process.

For this script to work, I made a few assumptions about your environment:

  • Your web server is Apache installed on a Linux operating system
  • The root directory for your WordPress installation is located at /var/www/{virtual_host}/

To Run the script, supply the virtual host folder on the command line as a script parameter.

You can find the script below.

https://github.com/derricksmith/wordpress/blob/master/Permissions/wordpress.sh

!/bin/bash
SITE_FOLDER=$1
echo "Change owner on all sites"
echo ""
echo "chown -R -F www-data:www-data /var/www"
chown -R -f www-data:www-data /var/www
echo "Securing the entire site $SITE_FOLDER"
echo ""
echo "chmod 755 -type d /var/www/$SITE_FOLDER"
find /var/www/$SITE_FOLDER -type d -exec chmod 755 {} \;
echo "chmod 755 -type f /var/www/$SITE_FOLDER"
find /var/www/$SITE_FOLDER -type f -exec chmod 644 {} \;
echo "chmod 640 /var/www/$SITE_FOLDER/.php" chmod 640 /var/www/$SITE_FOLDER/.php
echo "chmod 640 -type f /var/www/$SITE_FOLDER/wp-admin"
find /var/www/$SITE_FOLDER/wp-admin -type f -exec chmod 640 {} \;
echo "chmod 640 -type d /var/www/$SITE_FOLDER/wp-admin"
find /var/www/$SITE_FOLDER/wp-includes -type f -exec chmod 640 {} \;
echo "chmod 440 /var/www/$SITE_FOLDER/.htaccess"
chmod 644 /var/www/$SITE_FOLDER/.htaccess
echo "chmod 766 /var/www/$SITE_FOLDER/sitemap." chmod 766 /var/www/$SITE_FOLDER/sitemap.
echo "chown -R www-data:www-data /var/www/$SITE_FOLDER/wp-content/uploads"
chown -R -f www-data:www-data /var/www/$SITE_FOLDER/wp-content/uploads
chmod 777 -R /var/www/$SITE_FOLDER/wp-content/uploads
find /var/www/$SITE_FOLDER/wp-content/uploads -type f -exec chmod 660 {} \;
chmod 770 -R /var/www/$SITE_FOLDER/wp-content/upgrade
chmod 750 -R /var/www/$SITE_FOLDER/wp-content/plugins
find /var/www/$SITE_FOLDER -name 'index.php' -exec chmod 640 {} \;
echo "Done"

If this script helped you with your WordPress permissions please leave me a comment below.

This post is an update to an earlier post regarding integrating Nagios with GLPI that can be found here.  Due to recent improvements in the GLPI distribution I decided to rewrite the eventhandlers.  You can find a link to GitHub at the bottom of this post.

One of the key pillars of information security is availability of resources and as a proponent of using open source solutions whenever possible I have chosen to utilize Nagios for monitoring and GLPI for helpdesk solutions.  Nagios provides powerful monitoring capabilities for equipment, hosts and services but doesn’t integrate with ticketing systems directly which can make tracking and reporting difficult.  GLPI is an ITIL based helpdesk solution that provides asset and incident/request management.  It offers generous reporting out of the box and a webservices API that can be used to extend the system.  When used together these two systems can provide a way to track host and service availability and a way to report on the health and resolution metrics of those systems over time.

As shown in my previous post regarding the integration of Nagios and GLPI, the marriage of the two systems is done using the built-in Nagios eventhandler action and the GLPI webservices API.  In previous versions of GLPI, a webservices plugin was used to create the API endpoints.  As of GLPI version 9.1, a webservices API is included in the core package.  The following procedure for integrating GLPI with Nagios will only work with GLPI 9.1+.  The event handlers have also been improved and use an object oriented approach.  The PHP xml_rpc extension has been replaced with the curl extension.  Be sure curl is installed before using these scripts.

GLPI Configuration

First, enable the API and create an API client on the API Settings page in GLPI located under Setup > General > API.   Enable both Authentication settings to allow your API client to login with credentials and an authentication key.  Be sure to copy the API URL and the API key for the client.  Although the event handler scripts can use any GLPI account that has ticket creation permission to create new tickets, it is recommended to create a new user account that will be used specifically for API transactions.

Nagios Configuration

Depending on the version of Nagios and the base operating system, Nagios could be installed into several possible locations.  I typically use Ubuntu Server and the directories listed below are for Nagios3 – your directories may be different.

First, open the host and service event handlers and change the variables at the top of each script to reflect your environment.  The scripts include the following variables:

## Required ##
$glpi_user				= '';
$glpi_password				= '';
$glpi_apikey				= '';
$glpi_host				= '';
$nagios_host				= '';
$verifypeer				= FALSE; // SETS curl_setopt ($curl, CURLOPT_SSL_VERIFYPEER, FALSE);
$logging				= TRUE;
$critical_priority			= 5;
$warning_priority			= 3;

## Optional ##
$glpi_requester_user_id		= '';
$glpi_requester_group_id	= '';
$glpi_watcher_user_id		= '';
$glpi_watcher_group_id		= '';
$glpi_assign_user_id		= '';
$glpi_assign_group_id		= '';

The initial variables are self-explanatory.  The ssloff variable should be set to true if your site is http, you are using a self-signed certificate for https or your ssl configuration prevents successful certificate validation.  The optional variables are used to control how new tickets are opened and if initial watchers and ticket owners are used.  Use these variables to control which groups or users are notified of new tickets and when tickets are closed.

After you have modified the scripts, copy them and the glpi_api class to the Nagios eventhandler directory.  Next, modify the Nagios commands.cfg file to include the following commands.  Be sure to replace the directory with the correct event handler directory for your Nagios installation.

# 'manage-host-tickets' command definition
define command{
command_name manage-host-tickets
command_line php /usr/share/nagios3/plugins/eventhandlers/manage-host-tickets.php hoststate="$HOSTSTATE$" hoststatetype="$HOSTSTATETYPE$" eventhost="$HOSTNAME$" hostattempts="$HOSTATTEMPT$" maxhostattempts="$MAXHOSTATTEMPTS$" hostproblemid="$HOSTPROBLEMID$" lasthostproblemid="$LASTHOSTPROBLEMID$"
}

# 'manage-service-tickets' command definition
define command{
command_name manage-service-tickets
command_line php /usr/share/nagios3/plugins/eventhandlers/manage-service-tickets.php servicehost="$HOSTNAME$" servicestate="$SERVICESTATE$" servicestatetype="$SERVICESTATETYPE$" hoststate="$HOSTSTATE$" eventhost="$HOSTNAME$" service="$SERVICEDISPLAYNAME$" serviceattempts="$SERVICEATTEMPT$" maxserviceattempts="$MAXSERVICEATTEMPTS$" lastservicestate="$LASTSERVICESTATE$" servicecheckcommand="$SERVICECHECKCOMMAND$" serviceoutput="$SERVICEOUTPUT$" longserviceoutput="$LONGSERVICEOUTPUT$"
}

Next, modify your host and service templates to include the above event handler commands,

define host{
        name                            generic-host    ; The name of this host template
        notifications_enabled           1       	; Host notifications are enabled
        event_handler_enabled           1       	; Host event handler is enabled
        flap_detection_enabled          1       	; Flap detection is enabled
        failure_prediction_enabled      1       	; Failure prediction is enabled
        process_perf_data               1       	; Process performance data
        retain_status_information       1       	; Retain status information across program restarts
        retain_nonstatus_information    1       	; Retain non-status information across program restarts
		check_command                   check-host-alive
		event_handler		            manage-host-tickets
		max_check_attempts      1
		notification_interval   0
		notification_period     24x7
		notification_options    d,u,r
		contact_groups          admins
        register                        0       	; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!
        }
define service{
        name                            generic-service ; The 'name' of this service template
        active_checks_enabled           1       ; Active service checks are enabled
        passive_checks_enabled          1       ; Passive service checks are enabled/accepted
        parallelize_check               1       ; Active service checks should be parallelized (disabling this can lead to major performance problems)
        obsess_over_service             1       ; We should obsess over this service (if necessary)
        check_freshness                 0       ; Default is to NOT check service 'freshness'
        notifications_enabled           1       ; Service notifications are enabled
        event_handler_enabled           1       ; Service event handler is enabled
        flap_detection_enabled          1       ; Flap detection is enabled
        failure_prediction_enabled      1       ; Failure prediction is enabled
        process_perf_data               1       ; Process performance data
        retain_status_information       1       ; Retain status information across program restarts
        retain_nonstatus_information    1       ; Retain non-status information across program restarts
		notification_interval           0		; Only send notifications on status change by default.
		event_handler		            manage-service-tickets
		is_volatile                     0
		check_period                    24x7
		normal_check_interval           5
		retry_check_interval            1
		max_check_attempts              4
		notification_period             24x7
		notification_options            w,u,c,r
		contact_groups                  admins
        register                        0       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
        }

After you are finished be sure to restart the Nagios service.  You will now receive helpdesk tickets in GLPI when alerts are created in Nagios and those tickets will be removed when the service or host has been restored.  GLPI will handle the appropriate  notifications.

Download Here

I recently needed a BuddyPress compatible Wiki component for a project and couldn’t exactly find what I needed with the available plugins in the WordPress repository. The first solution I found was BuddyPress Docs, which is a great plugin but was overly complicated for what I needed. The second solution I found was the Buddypress Wiki Component (bp-wiki). This plugin seemed to fulfill all of my requirements but it had a few bugs. Support for the plugin was lacking and the developer hadn’t updated it in over 2 years. Numerous people had opened support threads indicating it was not compatible with the latest version of WordPress. As a result, I downloaded the plugin and got to work. At this point, I’ve updated the plugin to be compatible with WordPress 3.8+. The frontend editor has been updated to use the wp_editor function in WordPress and javascript has been fixed to allow for inserts and updates to wiki entries. With the permission of the original developer, I’ve placed the updated code on GitHub. You can find the updated code here.