1. Most security breaches are done still XSS
2. Some things to do to increase security
   1. Do not allow full HTML as input to anyone – filtered HTML only
   2. ONly give Super admin privileges to trusted users
3. Some best practices
   1. Change passwords
   3. do not use ftp
   4. Keep your site up to date
4. Online resources
   1. drupal.org/sercurity
   2. drupal.org/security/contrib
   3. Security Review Module

The problem is on the copied site that is on a new domain as we cannot login and go to the admin section because it redirect back to the source/original site. What we need is either disable the securepages module or update the domains. To do this, you need to access your database (ex: phpmyadmin, etc), go to variable table, and search for securepages configurations.

If you want to disable the module change:
securepages_enable s:1:"1";
to
securepages_enable s:1:"0";

Or if you want to update the domain change:
securepages_basepath s:30:"http://www.domain.com";
securepages_basepath_ssl s:31:"https://www.domain.com";
to
securepages_basepath s:30:"http://www.newdomain.com";
securepages_basepath_ssl s:31:"https://www.newdomain.com";

After making the above changes don’t forget to run the update.php (http://www.newdomain.com/update.php)

If you want to uninstall the module, try removing the securepages directory and run update.php.

What we did to eliminate this issue and be able to update the site automatically was to create a copy of the original core modules (located in /modules), add our custom functionality, and put the modified copy into ‘contributed’ modules directory (/sites/all/modules). Drupal read the modules found on /sites/all/modules first and ignore the same copy (original) found on /modules. Also, may want to change the module info or the package name to separate the modified modules from the original ones – ex: modified_core, custom, etc. In the case that Drupal reads both of them, you can just disable the other one.

Here’s our policy on working with Drupal modules:
– contributed or community modules at /sites/all/modules
– custom made modules at /sites/all/modules/custom
– modified core modules at /sites/all/modules/core_modified

Hope this helps.

Well, whether it may or may not be true, we have learned the hard way how much can go wrong when a developer hacks core to meet some requirements and does not tell the sysadmin team about it.  Drupal security updates are essential to the health of the site, as sysadmins, if we want to scale anything that we do, we can not manage many sites whos cores have been hacked.

If you find yourslef in the situation where you have a hacked core… you may enjoy this while you pull your hair out or wipe your tears

Ok, I got the error above when I performed Drupal CVS update on our Debian server (newly installed CVS 1.12.13). The same command works on other server with older CVS installation. The issue is the reference to local cvs directory where I used absolute path (-d /path/drupalsite/), which is a bug (security hole on client side) – it was fixed on newer CVS version to use relative path.

Drupal Checkout Command:
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal co -r DRUPAL-6-15 -d /path/drupalsite/ drupal

Use of Relative Path (sample)
cd /path
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal co -r DRUPAL-6-15 -d drupalsite drupal

Install rpm-build package.
sudo yum install rpm-build

Create build env in your home directory (mine is called ‘max’), do NOT build as root user. I used ‘rpm’ directory as the build location.
mkdir -p rpm/{SOURCES,SRPMS,SPECS,BUILD,RPMS}

Create .rpmmacros file which will identify the build location.
echo "%_topdir /home/max/rpm" > .rpmmacros

Download php5.2.9 rpm source file, i used FC9 version as it is closest to RHEL5.
wget http://kojipkgs.fedoraproject.org/packages/php/5.2.9/1.fc9/src/php-5.2.9-1.fc9.src.rpm

To rebuild php5.2.9 FC9 source RPM for RHEL5.x into binary RPM’s we need to make sure build dependences have been satisfied. I created a file called “php-deps” which contains the build dependencies to be installed via YUM.

bzip2-devel
curl-devel
db4-devel
gmp-devel
httpd-devel
pam-devel
libstdc++-devel
openssl-devel
sqlite-devel
zlib-devel
pcre-devel
readline-devel
libtool
gcc-c++
krb5-devel
libc-client-devel
cyrus-sasl-devel
openldap-devel
mysql-devel
postgresql-devel
unixODBC-devel
libxml2-devel
net-snmp-devel
libxslt-devel
libxml2-devel
mhash-devel
ncurses-devel
libXpm-devel
libjpeg-devel


Install build dependencies via yum
sudo yum install -y `cat php-deps`

Finally perform the build, this could take some time depending on speed of your machine. If everything goes well many php*.rpm files will be created in rpm/RPMS/”arch-type”/ folder. “arch-type” is the hardware-platform of your machine which will match “uname -i” command (mine is i386)
rpmbuild --rebuild php-5.2.9-1.fc9.src.rpm

Now you can install the resulting RPM’s manually but a better way is to create a local YUM repository.
Install createrepo application via YUM.
sudo yum info createrepo

Create a repository location directory and copy your newly generated php5.2.9 RPM files into it.
sudo mkdir /opt/local-repository && cp /home/max/rpm/RPMS/i386/* /opt/local-repository

Initialize the local repository and catalog the files copied there. (run this command anytime you add/remove files from your local repository directory)
sudo createrepo /opt/local-repository/

Configure your local repository with yum by creating a file in /etc/yum.repos.d called “local-repository.repo”
containing:
[local-repository]
name=RHEL5 $releasever - Local Repo
baseurl=file:///opt/local-repository/
enabled=0
gpgcheck=0
#gpgkey=file:///path/to/you/RPM-GPG-KEY


Update yum to register local repository
sudo yum update

Update php using your new rpm files via the local repository
sudo yum --enablerepo=local-repository update php

Restart apache
sudo /etc/init.d/httpd restart

Verify PHP version
php -v

Type: Multi-core (for possible use on other Drupal sites)
Java Servlet Container: Jetty (built-in on Solr)
Drupal version: 6
Java: 1.6

I based this guide plainly from this Drupal  page, and I made this summary for my own future reference.

Process:

You need to have the Java installed first.

1) ApacheSolr Drupal Module

1.1) Download and install ApacheSolr module to your site/s. Traditional download, extract, and enable method.
1.2) Download SolrPHPClient (PHP library) and extract the the files inside of your ApacheSolr Drupal module.
Example: sites/all/modules/apachesolr/SolrPhpClient

2) Solr:

2.1) Select a directory where you want to put your Solr files as long as it is not accessible to the web.
Example: /home/solr
2.2) Download nightly build of Solr and extract to your selected directory.
Example: /home/solr/apache-solr-nightly
2.3) Copy example directory to another directory like drupal.
Example:
cp -r /home/solr/apache-solr-nightly/example /home/solr/apache-solr-nightly/drupal
2.4) Copy schema.xml and solrconfig.xml files from your ApacheSolr Drupal module.
cp /path_to_site/sites/all/modules/apachesolr/schema.xml /home/solr/apache-solr-nightly/drupal/schema.xml
cp /path_to_site/sites/all/modules/apachesolr/solrconfig.xml /home/solr/apache-solr-nightly/drupal/solrconfig.xml
2.5) Copy “/home/solr/apache-solr-nightly/drupal/multicore/solr.xml” to “/home/solr/apache-solr-nightly/drupal/solr/solr.xml”
2.6) Create directory for each site that will use the ApacheSolr inside “/home/solr/apache-solr-nightly/drupal/solr” and copy
/home/solr/apache-solr-nightly/drupal/conf to each of them.
Example:
mkdir /home/solr/apache-solr-nightly/drupal/solr/site_drupalsite1
cp -r /home/solr/apache-solr-nightly/drupal/conf /home/solr/apache-solr-nightly/drupal/solr/site_drupalsite1/
mkdir /home/solr/apache-solr-nightly/drupal/solr/site_drupalsite2
cp -r /home/solr/apache-solr-nightly/drupal/conf /home/solr/apache-solr-nightly/drupal/solr/site_drupalsite2/
2.7) Edit /home/solr/apache-solr-nightly/drupal/solr.xml and add the details/path of your site/s.
Example:
<cores adminPath="/admin/cores">
<core name="drupalsite1" instanceDir="site_drupalsite1" />
<core name="drupalsite2" instanceDir="site_drupalsite2" />
</cores>
2.8) Start the Jetty servlet container.
cd /home/solr/apache-solr-nightly/drupal/
java -jar start.jar
2.9) Finally, visit Drupal Admin settings for ApacheSolr module to set the correct Solr path.
Example:
Drupal Site1: /solr/drupalsite1
Drupal Site2: /solr/drupalsite2

That’s it – we now have our complete ApacheSolr search integration. Check the ApacheSolr documentation for more details on using this module.

Solr server is started manually and to make it running on start up or if you want to be able to start/stop/restart the server, please refer to this blog post.

To add new sites (new sites with ApacheSolr module) just repeat steps 1 and 2.6 – 2.9, and restart the Solr server.

At this time of writing, this module is still on a development version and there’s no guarantee that the installation guide will work out-of-the-box with your system.  And this post will mainly cover my own installation process on our Nagios monitoring server running on Debian and Nagios version 3.0, and Drupal version 6.x sites on web servers running CentOS 5.x.

Installation:
My installation is based on the included README file and with some adjustments to my liking.

Install the Drupal Module:

• Download the Nagios module from Drupal project page.
• Install the module to your Drupal site just like the other modules.  Download tarball, extract to modules directory ex: sites/all/modules/, go to admin->build->modules and enable the module.
• Configure your Nagios module and set the site’s UniqueID and Cron duration.

  UniqueID is your site identifier to be used by the Nagios (check_drupal) to authorize the service check and for security purposes. The author also suggests the use of MD5 or SHA1 string. Refer to README for more info on this parameter.

  Cron Duration – you need to supply the interval of your cron job that checks for Drupal updates. This value should match with your cron settings, ex: daily or every 3 hours..etc.

Configure Nagios checks:

• Copy the plugin file (check_drupal) found on the nagios-plugin directory of the module, to your Nagios plugins directory where the other Nagios check commands are located – in my case it’s on /usr/local/nagios/libexec/ (CentOS).

  If your Nagios installation is on a different machine than your Drupal server, you need to copy the check_drupal file in there.  You can also put it on the same server with Drupal sites and use NRPE instead.

  On my CentOS machine i received an error on check_drupal regarding the location of basename file – it’s on /bin/basename.  You can edit the check_drupal file directly to adjust the path to basename.
  ./check_drupal: line 14: /usr/bin/basename: No such file or directory.

• Add command, host, hostgroup, and service definition:

  Command (commands.cfg): I made small modification on the given commands from the README file to match my setup.
  define command{
command_name check_drupal
command_line $USER1$/check_drupal -H $ARG1$ -U $ARG2$ -t $ARG3$
}

  HostGroup: I created a new Host group because we have other service checks on our server such as SSH, HTTP, LOAD, etc and I want to separate my checks for Drupal sites.
  define hostgroup {
hostgroup_name Drupal
alias Drupal Sites
members MyWebServer
}

  Host: I defined new host for Drupal sites so i can configure and group my them on the same host where they belong.
  define host {
host_name MyWebServer
display_name MyWebServer
address HOSTNAME/IP ADDRESS HERE
hostgroups Drupal
check_command check-host-alive
contact_groups Admins
check_period 24x7
max_check_attempts 10
notification_interval 480
notification_period 24x7
notification_options d,r
notifications_enabled 1
}

  Service: Below is my service checks definition for checking Drupal sites, i only need to copy this and change supply parameters for domain, unique key and the timeout.
  define service {
service_description DRUPAL_SITE 1
host_name MyWebServer
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 3
contact_groups Admins
notification_interval 480
notification_period 24x7
notification_options w,u,c,r
check_command check_drupal!mysite.example.com!mykeyhere!5
notifications_enabled 1
}


If your installation and configuration is correct you will get the Nagios service status similar below. It indicates number of modules, themes, users, nodes, etc.

DRUPAL OK, ADMIN:OK, CRON:OK
SAN=0;SAU=0;NOD=12;USR=7;MOD=23;THM=9

On my initial tests i received Nagios status (below) different than the above info and it was caused by my Apache configuration because i have a default Nagios installation before on my server that hosts my Drupal sites.

HTTP returned an error code. HTTP: HTTP/1.1 301 Moved Permanently
So you need to check first the url of your Nagios module installation ex: http://mysamplesite.com/nagios/, this will give you:

Nagios status page
nagios=UNKNOWN, DRUPAL:UNKNOWN=Unauthorized

Backup: In case the destination site or account have existing contents, you need to backup them first or moved to separate location.

Copy/Transfer Procedures

Database:

1.) Create an sql dump of your source database (use mysqldump)
2.) Update references to domain/url and path or home directory (you can user perl/sed commands)
3.) Import to your destination database (using mysql).

Files/Codes:

1.) Copy all files from your source directory or account to the destination site.
2.) Update references to database name, database user, database password, home directory of drupal installation, and domain name or url.
3.) Update permission and ownership of files and directories, like the sites/default/files to 777.

Notes. If you have CiviCRM installed and on a separate database, then you can use this guide but do not perform or update the references to url and paths. This guide is not applicable if you have CiviCRM installation which uses the same database as the Drupal database. CiviCRM recommended install is to use a separate database.

Shell / Bash Scripts:

1.)  Copy Drupal Site with CiviCRM.  Download here!

2.)  Copy Drupal Site without CiviCRM.  Download here!

Note: You can modify these scripts to work with sub-domains. Let me know if you have questions or suggestions or if you need help.

• Look at the number of requests a page makes to the server
• Use yslow to measure page rendering (often a page performance is perceived, not just based on the server response time)

• Remove search, use alternate solutions such as Apache Solr or Google Search API
• Use CDN as much as possible
• Use Reverse Proxy Cache and memcache
• Obviously use drupal cache

Some other notes that are somewhat related to drupal performance and site performance management in a clustered hosting environment.

Manual updates and rollback

OLD WAY: tar, move/copy untar restart services

OLD WAY: rsync

BETTER WAY: Capistrano

Managing systems:

BETTER WAY: bcfg2

Monitoring Tools

• Capacity Load: analyzing trends, predicting load, checking results of configuration and software changes (cacti, munin)
• Failure: analyzing downtime, notification (nagios – using nrpe agents to monitor diverse services (do we use it this way?) , hyperin)

Use monitoring tools to closely observe cluster replication and cashing as the failures in this area are the most difficult to solve.