1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260
|
Lockout plugin for SquirrelMail
===============================
Ver 1.6, 2008/04/01
Copyright (c) 2008 Paul Lesniewski <paul@squirrelmail.org>
Description
===========
This plugin allows you to create a list of users and/or
domains that should be disallowed (or allowed) login
access to SquirrelMail.
It also allows you to block brute-force password guessing
attacks, although please note that this will ONLY help
fight such attacks in the SquirrelMail interface, and
should really be implemented in your mail system's
authentication backend.
Tips on implementing this kind of security measure in the
mail server's authentication backend:
For Unix-like systems, there is a high probability that
your backend authentication method is PAM. For PAM-based
authentication, look at the pam_tally or pam_lockout add-on
modules, both of which will prevent this kind of attack
in a much more robust manner.
For OpenLDAP-based authentication, you would set
ppolicy_use_lockout and related configuration parameters
(all the ppolicy parameters are password related) in the
openldap configuration.
License
=======
This plugin is released under the GNU General Public
License (see COPYING for details).
Donations
=========
If you or your company make regular use of this software, please
consider supporting Open Source development by donating to the authors
or inquire about hiring them to consult on other projects. Donation
links for the author(s) are as follows:
Paul Lesniewski: https://sourceforge.net/donate/index.php?user_id=508228
Requirements
============
* SquirrelMail version 1.4.1 or above
* Compatibility plugin version 2.0.11 or above
Security Considerations
=======================
When configuring IP-based blacklisting with
$max_login_attempts_per_IP, username-based blacklisting
with $max_login_attempts, or adding a CAPTCHA requirement
with $activate_CAPTCHA_after_failed_attempts, you should
carefully consider your users' habits and the kinds of
potential attacks you are trying to mitigate.
The most risk-free of these features is to configure the
CAPTCHA plugin to activate after a certain number of
failed login attempts. This makes SquirrelMail somewhat
harder to attack in an automated fashion while not creating
any need for the administrator to have to manually unlock
any account or IP address. If you use a very strong
CAPTCHA backend (beware, however, that most CAPTCHA
implementations are not very strong) and are only fighting
off an *automated* attack, this step alone may suffice.
Adding IP-based blacklisting is effective at blocking an
attacker who is trying multiple user account names as long
as it is triggered at a reasonably high level of login
failures (the threshold should be especially high if you
have a lot of users who log in from a small number of
client addresses).
Username-based blacklisting could be useful when an attacker
is targetting a known user or small group thereof, although
because locking the user's account is also inconvenient to
the legitimate user, IP-based blacklisting will usually
still be a better solution. However, if this feature is set
with a fairly high threshold (higher than all others), it
can be used to halt someone who consistently attacks the
same account from a range of IP addresses. After triggering
a lockdown on such an account, it might be prudent to change
the username or take other (real world?) measures.
See the configuration file for more information about how
to configure each of the settings discussed above.
If your SquirrelMail installation resides behind a proxy
server that sends X_FORWARDED_* headers, you should turn on
$obey_x_forwarded_headers, but in all other environments,
please leave this setting off, otherwise an attacker might
be able to thwart a domain lockout rule by tampering with
the request headers.
In the same vien, if a client is able to forge the regular
HTTP_HOST request header, domain-based lockout rules
defined in the lockout table may be compromised. The only
solution for this kind of problem beside using user-based
lockout rules or enforcing login restrictions in the IMAP
server (which is ALWAYS more robust than implementing them
in the mail client) is to make sure that your usernames are
in the format of a full email address (that is, that they
always carry a domain name in them, and are not, for
instance, in the same format as local account usernames).
Configuration
=============
Please copy the sample configuration (config.sample.php)
file in this plugin's data sub-directory to your own
config.php and then edit it as necessary. If you choose
to enable the $use_lockout_rules setting, you must also
copy the sample lockout table (lockout_table.sample.php)
in the data sub-directory into your own lockout_table.php
and edit it as follows:
Users and domains can be indicated using wildcards and can
each have their own page that will be displayed when they
are locked out. See the sample lockout_table.sample.php
file in the data directory for help building this table.
You may want to edit the file(s) you have indicated as the
target lockout page to be displayed in order to customize
the message that will be seen when someone is locked out, or
send them to a special web page elsewhere or redirect them
to the standard SquirrelMail "bad username or password"
error page if you desire this plugin to be more stealthy.
Note that this will typically catch locked out users no
matter which of your domains they attempt to log in through.
Note also that if you enable reverse lockout functionality,
the users and domains listed in the lockout table will all
be ALLOWED to log in, all OTHERS will be locked out.
Troubleshooting
===============
* If you have some SMTP authentication method configured
in the main SquirrelMail configuration (or perhaps
POP before SMTP is turned on) and administrative alert
emails are not getting sent when a user is locked out,
this is because the SMTP authentication credentials
are not yet available before a user has logged in, so
you need to provide administrative credentials for
sending such emails. See $lockout_smtp_auth_mech
(and related settings) in the configuration file.
Help Requests
=============
Before looking for help elsewhere, please try to help yourself:
* Read the Troubleshooting section herein.
* Look to see if others have already asked about the same issue.
There are tips and links for the best places to do this in
the SquirrelMail mailing list posting guidelines:
http://squirrelmail.org/wiki/MailingListPostingGuidelines
You should also try Google or some other search engine.
* If you cannot find any information about your issue, please
first mail your help request to the squirrelmail-plugins
mailing list. Information about it can be found here:
http://lists.sourceforge.net/mailman/listinfo/squirrelmail-plugins
You MUST read the mailing list posting guidelines (see above)
and include as much information about your issue (and your
system) as possible. Including configtest output, any debug
output, the plugin configuration settings you've made and
anything else you can think of to make it easier to diagnose
your problem will get you the most useful responses. Inquiries
that do not comply with the posting guidelines are liable to
be ignored.
* If you don't get any replies on the mailing list, you are
welcome to send a help request to the authors' personal
address(es), but please be patient with the mailing list.
Change Log
==========
v1.6 2008/04/01 Paul Lesniewski <paul@squirrelmail.org>
* Allow overrides of SquirrelMail SMTP/Sendmail settings
when sending administrative alert emails
v1.5 2008/03/11 Paul Lesniewski <paul@squirrelmail.org>
* Updated to use sq_send_mail for notification messages
* Added ability to log lockout events in Squirrel Logger plugin
* Remove use of login_top hook
v1.4.1 2007/08/24 Paul Lesniewski <paul@squirrelmail.org>
* Very small change due to change in SM 1.5.2; does not affect
plugin functionality - no upgrade needed for anyone who does
not want to bother
v1.4 2007/07/12 Paul Lesniewski <paul@squirrelmail.org>
* Added ability to disable accounts that have too
many successive login failures, including
optional administrative alert email
* Added IP-based blacklisting
* Added ability to enable the CAPTCHA plugin
for IP addresses that have too many successive
login failures
* Move lockout check to hook that occurs BEFORE
user is actually logged in
* Updated for compatibility with SM 1.5.2+
* Updated for use with new Compatibility plugin
* Miscellaneous cleanup
* Security considerations/audit thanks to Ben at reCAPTCHA.net
1.3 - Paul Lesniewski <paul@squirrelmail.org>
* Added abilty to reverse lockout functionality
(lock out everyone *except* those listed in the
lockout table)
1.2 - Paul Lesniewski <paul@squirrelmail.org>
* Fixed typo in INSTALL
1.1 - Paul Lesniewski <paul@squirrelmail.org>
* Added ability to redirect to another web page or
to the standard SquirrelMail "bad username or
password" page (with simulated bad login delay)
1.0 - Paul Lesniewski <paul@squirrelmail.org>
* Initial release
Future Work
===========
* Ideas?
|