Re: Apache limit number of login retries

On Sun, Jun 29, Martin Wickman inscribed on the eternal scroll:

> In a nutshell:
>
> A client enters valid user name, but an invalid password. After a
> number of failed attempts, the account should be locked.

Provides any mischief maker with an instant denial-of-service attack.

> In this particular scenario, the action is to block the user, but
> there could be other actions. For instance notifying an admin by mail
> or sms, logging to a database etc.
>
> Obviously this is not trivial,

Seems easy enough to me as stated; just that it rates to create as
much of a problem as it solves.

And 'thanks' to the widespread availability of open proxies on the
internet nowadays (the spammers are already making enthusiastic use of
them), any attempt to confine the blockout to a particular IP could be
easily circumvented.

In article <Pine.LNX.4.53.0306300155200.23158@lxplus083.cern. ch>, Alan J. Flavell wrote:
> On Sun, Jun 29, Martin Wickman inscribed on the eternal scroll:
>
>> In a nutshell:
>>
>> A client enters valid user name, but an invalid password. After a
>> number of failed attempts, the account should be locked.
>
> Provides any mischief maker with an instant denial-of-service attack.

Yup, but then again the mischief needs to know valid user names. On
the other hand, the point is that blocking may be just *one*
action. Everything for just separate logging to automatic CIA
notifications should be possible.

But, yes, I agree there are some issues. But, imho, the gaping
brute-force-guessing issue is a bigger problem -- and lots of
companies have silly security rules which enforces
max-number-of-retries and such which rules out basic authentication
with apache.

>> In this particular scenario, the action is to block the user, but
>> there could be other actions. For instance notifying an admin by mail
>> or sms, logging to a database etc.
>>
>> Obviously this is not trivial,
>
> Seems easy enough to me as stated; just that it rates to create as
> much of a problem as it solves.
>
> And 'thanks' to the widespread availability of open proxies on the
> internet nowadays (the spammers are already making enthusiastic use of
> them), any attempt to confine the blockout to a particular IP could be
> easily circumvented.

Blocking of IP was not my main concern. I was more thinking along the
lines of blocking a certain user, maybe for a specific time. Depending
on where the user databas is, this must of course be done in a
specific way for each auth-module. Besides, in a controlled
environment such as an intranet/vpn, DOS is pretty much a non-issue as
well.


Since I have no clue where to start digging, I would like some
technical input of how to go about it. As I see it, mod_auth_* module
need only to put the failed user name somewhere on the request memory
so that the actual mod_block_user (or whatever) can do its thing.

On Mon, Jun 30, Martin Wickman inscribed on the eternal scroll:

> > And 'thanks' to the widespread availability of open proxies on the
> > internet nowadays (the spammers are already making enthusiastic use of
> > them), any attempt to confine the blockout to a particular IP could be
> > easily circumvented.
>
> Blocking of IP was not my main concern.

I wasn't exactly meaning to "block the IP"; I was taking the reasoning
onwards from the observation that "blanket blocking of a user name
means an easy denial of service for that user", but showing that the
initially attractive option of tying the block to a specific IP
wouldn't really solve the problem either, for the reason I gave.

> I was more thinking along the
> lines of blocking a certain user, maybe for a specific time.

Actually if you could slow down the response to bad credentials, you
might make it impractical to brute-force enough different passwords in
a realistic time, while still permitting bona fide access without much
delay. Disclaimer: I haven't tried this in practice myself, though it
sounds at least a plausible principle; I haven't seen it discussed
more than superficially either (this itself surely carries some kind
of message? - but maybe someone who's got a working solution will be
willing to discuss it here, and then I'll happily defer to their
expertise).

> Besides, in a controlled environment such as an intranet/vpn, DOS is
> pretty much a non-issue as well.

Well, this here usenet group has WWW in its name - it isn't really
on-topic to deal with intranet situations. But evidently this
intranet is considered insecure enough to need defending against
password cracking attacks, so just why isn't denial of service an
issue too, riddle me that?

good luck

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In article <Pine.LNX.4.53.0306302118450.27088@lxplus007.cern. ch>, Alan J. Flavell wrote:
>
> Actually if you could slow down the response to bad credentials, you
> might make it impractical to brute-force enough different passwords in
> a realistic time, while still permitting bona fide access without much
> delay.

It might be possible to adapt the Apache::SpeedLimit module from the
book _Writing Apache Modules with Perl and C_ to this purpose. The
module itself is designed to compute the number of accesses over a
period of time (per minute, in the example), and if that number exceeds
a set value access is denied. There's a grace period, so setting it
low enough might be able to do what the OP desired. (The module could
probably be modified to enforce the speed limit only when the HTTP
response would be 401, so initial logins may experience a delay but
subsequent accesses would be undelayed.)

- --keith

- --
kkeller-mmmspam@wombat.san-francisco.ca.us
(try just my userid to email me)
alt.os.linux.slackware FAQ: http://wombat.san-francisco.ca.us/cgi-bin/fom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj8AxswACgkQhVcNCxZ5ID+XDwCfWvfJXXOUaS YkyF02kFiPhC2X
gAkAnR7rZ0NIzAqi+cdx+QObPWW8KNxG
=9gTR
-----END PGP SIGNATURE-----

In article <gsgqdb.kku.ln@goaway.wombat.san-francisco.ca.us>, Keith Keller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In article <Pine.LNX.4.53.0306302118450.27088@lxplus007.cern. ch>, Alan J. Flavell wrote:
>>
>> Actually if you could slow down the response to bad credentials, you
>> might make it impractical to brute-force enough different passwords in
>> a realistic time, while still permitting bona fide access without much
>> delay.
>
> It might be possible to adapt the Apache::SpeedLimit module from the
> book _Writing Apache Modules with Perl and C_ to this purpose. The
> module itself is designed to compute the number of accesses over a
> period of time (per minute, in the example), and if that number
> exceeds a set value access is denied. There's a grace period, so
> setting it low enough might be able to do what the OP desired. (The
> module could probably be modified to enforce the speed limit only
> when the HTTP response would be 401, so initial logins may
> experience a delay but subsequent accesses would be undelayed.)

It's a good idea, and I suppose using mod_perl would be the smartest
way to do a proof-of-concept solution.

After reading a bit about handlers in mod_perl, here is my outline:

Create a mod_delay module in the Authen-phase and add it after the
true mod_auth entry in httpd.conf. Make sure mod_auth is
non-authoritive so apache will run the next module (mod_delay) when
the attempt fails (DECLINED). Now we know that the http response is
401 and we also know the user name, so just up the invalid-retries
count for this user and sleeps for x^nretries seconds.

The actual job with keeping the nretries info alive could be done lots
of ways (files, db etc), so it's a non-issue I guess.


Thoughts?

On Thu, Jul 3, Martin Wickman inscribed on the eternal scroll:

> It's a good idea, and I suppose using mod_perl would be the smartest
> way to do a proof-of-concept solution.

Caution: this is still off the top of my head, I haven't thought it
through in detail...

Based on what you're writing, it looks as if you're already on the way
to a production solution - to be honest, if I was just aiming for a
proof of concept trial, I reckon I would define a CGI script to be my
ErrorDocument 401, and do the work in the CGI script.

That way, I could play around with the options in a fairly stand-alone
way without having to mess with the server itself or any persistent
processes.

Indeed you'd probably want to keep some persistent data, but that
could be done in a database (even in a flat file etc.).

Efficiency is no big issue IMHO, since the code would only be invoked
after a failure. If an attacker could slow the error handling down by
hitting it harder, then so much the better ;-) as long as it didn't
too adversely affect bona fide access.

It'll be interesting to hear the results of whatever scheme is tried
out. As I say, I found relatively little practical experience
reported when I tried some plausible web search terms.

In article <Pine.LNX.4.53.0307031154590.16393@lxplus100.cern. ch>, Alan J. Flavell wrote:
> On Thu, Jul 3, Martin Wickman inscribed on the eternal scroll:

[ ... mod_auth_slowdown ... ]

>
>> It's a good idea, and I suppose using mod_perl would be the smartest
>> way to do a proof-of-concept solution.
>
> Caution: this is still off the top of my head, I haven't thought it
> through in detail...

It just struck me, using a slowdown approach like this makes it, even
easier to perform a DOS attack on the server. Just spawn a couple of
'wget joe:pwd@http://host' in a loop and the whole site will be
unavailable for *everyone* since each apache process will be in a
sleep() state. :-(

Unless I am mistaken, this makes the user-banning approach look much
better. At least then, only a specific account is affected, not the
whole server.