[[PageOutline]] = Web Application Security = == Check File Permissions == We should regularly check all web directories for files and folders with unsafe permissions (world-writable or known sensitive configuration files that are world-readable). See #13688. == Track outgoing connections == Sometimes a compromise results in code periodically checking in with a control center. Often a abuse reporting site will let us know it's happening and will tell us what the IP address of the control center is. It can still be very difficult to figure out which site and which user is compromised. To help catch this behavior: * Edit /etc/default/mf-ip-track-outgoing-connections and add the IP address we are looking for. * Start the service: `systemctl start mf-ip-track-outgoing-connections` * Check journalctl for hits (`journalctl -u mf-ip-track-outgoing-connections -f` == Control Panel Installation == Enable control panel installation of WordPress and Drupal via control panel. This step helps us keep track of which sites are running Drupal and WordPress so we can properly upgrade them and check them for compromises. We currently allow for Drupal 7 installation via the Control panel, but not Drupal 8 (see #11601) WordPress is almost ready (#1608) == General web app maintenance == The script `mf-check-web-app` automates the maintenance of Drupal and WordPress sites on our servers. Usage is: {{{ Usage /usr/local/bin/mf-check-web-app --path [PATH] --action [ACTION] --quiet PATH auto - check all directories on the server based on web-app-security directory files otherwise, only check the single path provided default is current working directory ACTION integrity - check file integrity core - means upgrade just core plugins - upgrade just third party plugins, modules and themes auto - do whatever is defined in the web-app-security directory default is integrity QUIET Output nothing. Check logs. }}} It lives in /usr/local/bin and can be run as root (in which case it drops privileges to the owner of the Drupal or Wordpress site) or as the user that owns the site. The default action (when run with no arguments) is to run an integrity check on the current workding directory. When operating in "auto" mode, it finds web apps by searching for the files `/home/members/*/sites/*/.red/web-app-security/{drupal,wordpress}-{core,plugins,integrity}`. If it finds files, it runs according to the file included. == Monitoring of compromised sites == The monitor script mf-monitor-webapps executes the script mf-check-web-app and triggers a Nagios warning if it finds any web app sites that fail the test. In process, see #13159. == Auto Upgrades == See #11405. May First/People Link provides a service to automatically provide security updates to your web applications. If you opt-in, your web application will be checked every night to see if any security updates are available and, if so, they will be installed. By using this service, you will greatly improve the protection of your web site against compromise while also incurring a very small chance that something might go wrong during the upgrade. This service is currently available for Drupal and WordPress only. The updater will not upgrade all aspects of your site: * The automatic upgrader only performs security/minor updates. It does not perform an upgrade from Drupal 7 to Drupal 8, for example. Or from Wordpress 4.5 to 4.6. * It will not upgrade modules or plugins that are not maintained on the central Drupal or WordPress repositories (for example, CiviCRM is maintained separately, so it won't be upgraded via this script). * WordPress themes are not updated. Drupal themes are updated. [Note: when fully implemented, users can enable via the control panel.] An admin can enable this protection by creating a directory in a sites hidden .red directory (e.g. /home/members/mayfirst/sites/mayfirst.org/.red): web-app-security and place one or more files in it. To indicate that you want to have your web application automatically upgraded, please create a file or files with the following names to indicate what you want upgraded. * drupal-integrity * drupal-core * drupal-modules * wordpress-integrity * wordpress-core * wordpress-plugins The contents of each file should have, one per line, the full, absolute path to the root of your web directory containing WordPress or Drupal. For example, if you want to upgrade both drupal core and drupal modules for a web appication located directly in your web folder, create two files: one called drupal-core and one called drupal-modules in this directory. If you have two WordPress installations, one in the web directory and one in a subdirectory called "outreach" and you just want to auto upgrade the core WordPress code for both of them, create a single file called wordpress-core that contains the absolute path to your main web directory on one line and the absolute path to your outreach directory on the second line. === Technical Details === All upgrades are run as the user who owns the index.php file in the given directory. Drupal core upgrades are run via drush with the following command: {{{ drush -y pm-update drupal --security-only }}} Drupal module upgrade are run with the following command: {{{ drush -y pm-update --no-core --security-only }}} WordPress upgrades are handled via the following wp-cli commands: {{{ wp core update --minor }}} And WordPress plugin updates via: {{{ wp plugin update --all }}} NOTE: WordPress sites with a functioning cron job that are higher than version 3.7 already have [https://codex.wordpress.org/Configuring_Automatic_Background_Updates auto-updates enabled] so this step is not necessary, however, it doesn't hurt either. == Open Tickets tagged `web-app-security` == [[TicketQuery(format=table,status=new|assigned,keywords=~web-app-security)]]