drupal-security
Drupal leverages many open source advanced web features into one interface that conceivably could be handed off to a "non developer" to maintain.
Along with all of the installation / implementation (often customized to fit the customers' needs) there are two further things that should be considered, Security and Useability.
Drupal is a Content Management System that allows remote users to run scripts and access databases on your web server.
Restrict the PHP scripts access from ANONYMOUS USERS ON THE INTERNET
"index.php" should be allowed (it's your home page) but...
*Cron is the method in linux to run scheduled tasks.
Drupal requires regular scheduled actions for maintenance (e.g. update content in search, cleaning up log files, checking for updates, etc.)
http://drupal.org/cron.php is not accessible but http://yourdomain.com/cron.php may be accessible to ANYONE (as that's the default install).
To secure the cron.php file in .htacess, you have to do that manually after installation:
To block remote access to cron.php, in the server's .htaccess file or vhost configuration file:
<Files "cron.php">
Order Deny,Allow
Deny from all
Allow from localhost
Allow from 127.0.0.1
Allow from xx.xx.xx.xx <-- your remote IP address
</Files>
Or protect update.php too in the .htaccess file:
# add allowed remote IP addresses
allow from a.b.c.d
allow from a.b.c.d
NOW ANONYMOUS ACCESS TO CRON.PHP should return either "access denied" or "page not found"...
You can still run cron manually from either of the options below: Administer -> Reports -> Status
CHECK ON THE REPORTS VIA: http://domain.com/admin/reports/status/run-cron
TROUBLESHOOTING drupal cron.php on cpanel
Common workarounds are:
45 * * /usr/bin/lynx -source http://example.com/cron.php
45 * * /usr/bin/wget -O - -q -t 1 http://www.example.com/cron.php
45 * * curl --silent --compressed http://example.com/cron.php
wget -O /dev/null http://DOMAIN.com/cron.php 2>/dev/null
In a locked down environment like the above .htaccess file you might need to test using:
-
-
-
-
- php /home/USERNAME/public_html/cron.php
-
-
-
I then check at my Drupal site when cron was last run: http://DOMAIN.com/admin/reports/status
NOTE: to eliminate any log or email of this job you might add:
0 0 * * * php /home/USERNAME/public_html/cron.php > /dev/null 2>&1
unfortunately the -q parameter by itself gave weird errors...
Cpanel -> Advanced -> Cron Jobs
-
-
-
-
- http://domain.com/cron.php
-
-
-
(e.g. for rochen or bluehost cpanelx command should be the 8 char directory)
php -q /home/yoursite/public_html/cron.php
OR if you have multiple subdomains running different drupal installs: php -q /home/8chars/public_html/subdomain/cron.php
Check using your drupal admin to ensure that the cron job has run Administer -> Reports -> Status
This will allow you to test if your cpanel really has the correct permissions as Administer -> Reports -> Status should now show the cron job status as updated frequently! =)
Here is a diagram of the general crontab syntax, for illustration:
+---------------- minute (0 - 59)
| +------------- hour (0 - 23)
| | +---------- day of month (1 - 31)
| | | +------- month (1 - 12)
| | | | +---- day of week (0 - 7) (Sunday=0 or 7)
| | | | |
-
-
-
-
- command to be executed
-
-
-
e.g. 2 13 28 12 * /bin/execute/this/script.sh
the five stars (with a space in between each!) represent wildcards:
- when minute = 2
- when hour = 13
- when day = 28
- when month = 12
- every day (could be = 5 for every friday)
For further linux cron tips see: http://kittyandbear.net/john/linux-tutorials/linux-cron-schedule-scripts-crontab-list-user.php
/sites/default/settings.php should definitely have:
$update_free_access = FALSE;
Administer > Site configuration > File uploads "Default permitted file extensions field" for each role should be limited, because obviously you don't want ANONYMOUS users uploading .php files!