1
|
|
2
|
-- ABOUT --
|
3
|
|
4
|
Security Review automates checking many of the configuration errors that lead
|
5
|
to an insecure Drupal site and looks for existing vulnerabilities and attack
|
6
|
attempts.
|
7
|
|
8
|
The primary goal of the module is to elevate your awareness of the importance of
|
9
|
securing your Drupal site. The results of some checks may be incorrect depending
|
10
|
on unique factors, this module does not make your site more secure. You should
|
11
|
use the results of the checklist and its resources to manually secure your site.
|
12
|
|
13
|
Refer to the support section below if you are interested in securing your Drupal
|
14
|
site.
|
15
|
|
16
|
-- INSTALLATION --
|
17
|
|
18
|
Place the security_review directory and its contents under sites/all/modules or
|
19
|
under an appropriate sites/ directory if you are using Drupal's multisite
|
20
|
capabilities.
|
21
|
|
22
|
Enable the module at Administer >> Modules and refer to the
|
23
|
following sections for configuration and usage.
|
24
|
|
25
|
-- CONFIGURATION --
|
26
|
|
27
|
Two permissions are provided and required to use the module. Navigate to
|
28
|
Administer >> People >> Permissions to enable
|
29
|
'access security review list' and 'run security checks' for trusted roles.
|
30
|
|
31
|
NOTICE: This module provides information on the state of your site's security so
|
32
|
it is imperative you grant these permissions to trusted roles and users only.
|
33
|
For instance, if you have an admin role, be sure that all the users who have
|
34
|
been granted this role are indeed users you trust if you grant them these
|
35
|
permissions.
|
36
|
|
37
|
After you have granted permissions to the module you should inform the system
|
38
|
what roles are not trusted. Navigate to
|
39
|
Administer >> Reports >> Security Review >> Settings to mark which roles are
|
40
|
untrusted. Most checks only care if the resource is usable by
|
41
|
untrusted roles.
|
42
|
|
43
|
On this page you can also define the level of logging. The result
|
44
|
of the last checklist is always stored but you can enable watchdog logging of
|
45
|
each check if you like.
|
46
|
|
47
|
-- USAGE --
|
48
|
|
49
|
Navigate to Administer >> Reports >> Security Review to run the checklist.
|
50
|
|
51
|
If a check is enabled it will be run. You can enable or skip a check on this
|
52
|
page only after it has been run. Clicking on the 'Help' link beside each check
|
53
|
will provide details on why the check exists and what was found on the last run.
|
54
|
|
55
|
-- DRUSH USAGE --
|
56
|
|
57
|
Running the Security Review checklist using Drush is a great way to build
|
58
|
automated security audits of your site into your site development lifecycle and
|
59
|
as part of continuous integration.
|
60
|
|
61
|
With the module installed invoke 'drush secrev' from within your Drupal root.
|
62
|
|
63
|
Call 'drush help secrev' to see available options.
|
64
|
|
65
|
For running specific checks pass the '--check' option. Be sure to remove any
|
66
|
whitespace characters separating check names.
|
67
|
|
68
|
Consult implementations of hook_security_checks() for exact list of available
|
69
|
check options. Standard Security Review checks are:
|
70
|
|
71
|
file_perms, input_formats, field, error_reporting, private_files, query_errors,
|
72
|
failed_logins, upload_extensions, admin_permissions, untrusted_php,
|
73
|
executable_php, base_url_set, temporary_files
|
74
|
|
75
|
For custom checks you may prefix the check name with the module name and
|
76
|
colon (:) character. For example:
|
77
|
|
78
|
'drush secrev --check=my_module:my_check'
|
79
|
|
80
|
Note, custom checks require that its module be enabled. Also, should you be
|
81
|
skipping any check the 'store' option will not allow that check to be run.
|
82
|
|
83
|
-- SITE AUDIT USAGE --
|
84
|
|
85
|
Security Review also integrates with https://www.drupal.org/project/site_audit ,
|
86
|
a static site analysis platform that generates reports with actionable best
|
87
|
practice recommendations. Security Review can be installed on an entire
|
88
|
platform, eliminating the need for module installation.
|
89
|
|
90
|
To use, put Security Review either in your codebase or in your Drush command
|
91
|
locations, then:
|
92
|
|
93
|
# Clear Drush cache.
|
94
|
drush cc drush
|
95
|
# Audit security.
|
96
|
drush audit_security
|
97
|
|
98
|
### Marking field content as known to be safe
|
99
|
|
100
|
The "Dangerous tags in content" check may indicate problems with fields that
|
101
|
you known are safe. You can create a list of field contents and entities
|
102
|
that you want to be skipped in future runs by creating a SHA-256 hash of the
|
103
|
entity_id, entity_type, and field contents. See security_review_check_field
|
104
|
function in security_review.inc for details.
|
105
|
|
106
|
-- SUPPORT --
|
107
|
|
108
|
Please use the issue queue at https://drupal.org/project/security_review for all
|
109
|
module support. You can read more about securely configuring your site at
|
110
|
http://drupal.org/security/secure-configuration and http://drupalscout.com
|
111
|
|
112
|
Acquia, the provider of this module, offers detailed,
|
113
|
targetted security review and support for Drupal websites and can be contacted
|
114
|
at http://wwww.acquia.com or via email at sales@acquia.com.
|
115
|
|
116
|
You can read more about our Drupal security review service at
|
117
|
http://www.acquia.com/products-services/professional-services/offerings#security_audit
|
118
|
|
119
|
|
120
|
-- CREDIT --
|
121
|
|
122
|
Security Review module written by Benjamin Jeavons, drupal.org user coltrane,
|
123
|
with thanks to Greg Knaddison, drupal.org user greggles, for the idea and
|
124
|
mentorship.
|