Обсуждение: brute force attacking the password
LS, is there a way of securing the postgresql-server against brute force password cracking ? iow: is there a way of setting eg a maximum number of login attempts, or using a time-out or ..? + securing on server level tnx,
Wim Bertels wrote: > LS, > > is there a way of securing the postgresql-server against brute force > password cracking ? > iow: is there a way of setting eg a maximum number of login attempts, or > using a time-out or ..? > > + securing on server level No, there is not. Does anyone want to suggest a possible implementation for the TODO list? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> No, there is not. Does anyone want to suggest a possible implementation
> for the TODO list?
I would like to see a combination of number of login failures and a
timeout, configurable via the conf file. Say, X login failures
disables further logins for that account for Y minutes.
That would be groovy. :)
Benny
--
Nixon: "Hello, Morbo! How's the family?"
Morbo: "Beligerant and numerous."
-- Futurama
C. Bensend wrote: > > > No, there is not. Does anyone want to suggest a possible implementation > > for the TODO list? > > I would like to see a combination of number of login failures and a > timeout, configurable via the conf file. Say, X login failures > disables further logins for that account for Y minutes. > > That would be groovy. :) I would like to pick something that matches what a typical Unix system does because I think the _fancy_ solutions actually cause weird problems like denial-of-service attacks by just trying to log in. How do typical open source Unix's handle it? It think they slow down prompting for a password --- but as I remember we only allow one password attempt per connection so that is already covered. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> > No, there is not. Does anyone want to suggest a possible implementation
> > for the TODO list?
> I would like to see a combination of number of login failures and a
> timeout, configurable via the conf file. Say, X login failures
> disables further logins for that account for Y minutes.
>
> That would be groovy. :)
And dangerous. Imagine a system with say, apache accound used
from some Apache application. And a maluser who purposefully
tries to log in to "apache" account and fails, thus causing a DoS
on the web application. :)
...of course with careful planning and right implementation it
would be very good.
Anyway, a simple 'sleep 2 seconds before telling that password
was wrong' would be a good addition anyhow. [ if it already is
inside PgSQL, please forgive me :) ]
Regards,
Dawid
> And dangerous. Imagine a system with say, apache accound used
> from some Apache application. And a maluser who purposefully
> tries to log in to "apache" account and fails, thus causing a DoS
> on the web application. :)
Yes, I absolutely agree. Any scheme of the sort would have some
risks. And a risk I might be willing to take, might not be
acceptable for others.
> ...of course with careful planning and right implementation it
> would be very good.
And this is where I lay my trust in the PostgreSQL developers. I
am no power user, but I certainly appreciate the impressive
quality of the software. Thanks, folks. :)
Benny
--
Nixon: "Hello, Morbo! How's the family?"
Morbo: "Beligerant and numerous."
-- Futurama
Dawid Kuroczko <qnex42@gmail.com> writes:
> Anyway, a simple 'sleep 2 seconds before telling that password
> was wrong' would be a good addition anyhow.
Seems pretty useless, unless we change things to also delay 2 seconds
before telling the password was good, which I doubt anyone will like ;-)
Otherwise, the attacker can simply abandon each connection after say
50 msec, or whatever the expected success time is. He need not wait
until the postmaster drops the connection before launching another
attempt.
(No, I wouldn't like to stop that by putting a throttle on allowed
connection rates, either ...)
regards, tom lane
On Mon, Apr 18, 2005 at 16:55:45 -0400, Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > I would like to pick something that matches what a typical Unix system > does because I think the _fancy_ solutions actually cause weird problems > like denial-of-service attacks by just trying to log in. > > How do typical open source Unix's handle it? It think they slow down > prompting for a password --- but as I remember we only allow one > password attempt per connection so that is already covered. Can't people use PAM to get this effect if they want it? For most people password guessing isn't going to be a big problem as the database won't be accessible from totally untrusted places and watching the log files for guessing will probably be a good enough solution.
Bruce Momjian schreef: >Wim Bertels wrote: > > >>LS, >> >>is there a way of securing the postgresql-server against brute force >>password cracking ? >>iow: is there a way of setting eg a maximum number of login attempts, or >>using a time-out or ..? >> >>+ securing on server level >> >> > >No, there is not. Does anyone want to suggest a possible implementation >for the TODO list? > > evident remarks: http://www.woodmann.com/fravia/protec.htm SHS instead of MD5? http://www.secinf.net/firewalls_and_VPN/Firewalls_Complete/Firewalls_Complete__Cryptography_Is_it_Enough.html ..
>Can't people use PAM to get this effect if they want it? what if u use pam with ldap, then u can use pg brute force cracking to obtain the ldap password, which is probably a biggerproblem >For most people password guessing isn't going to be a big problem as >the database won't be accessible from totally untrusted places and watching >the log files for guessing will probably be a good enough solution. what if u do want the database to be globally accessible..
On Tue, Apr 19, 2005 at 17:00:15 +0200, Wim Bertels <wim.bertels@khleuven.be> wrote: > >Can't people use PAM to get this effect if they want it? > > what if u use pam with ldap, then u can use pg brute force cracking to > obtain the ldap password, which is probably a bigger problem You don't have to use it with LDAP. It does provide some password controls, that should slow things down a little. However, you are going to have a tough time preventing password guessing without making denial of service attacks easy. > > >For most people password guessing isn't going to be a big problem as > >the database won't be accessible from totally untrusted places and watching > >the log files for guessing will probably be a good enough solution. > > what if u do want the database to be globally accessible.. Then you have a much more difficult situation. One option is to bind user names to specific allowed IP addresses.
On Tuesday 19 April 2005 22:37, Bruno Wolff III seinde rooksignalen: > On Tue, Apr 19, 2005 at 17:00:15 +0200, > > Wim Bertels <wim.bertels@khleuven.be> wrote: > > >Can't people use PAM to get this effect if they want it? > > > > what if u use pam with ldap, then u can use pg brute force cracking to > > obtain the ldap password, which is probably a bigger problem > > You don't have to use it with LDAP. It does provide some password controls, > that should slow things down a little. However, you are going to have a > tough time preventing password guessing without making denial of service > attacks easy. anayway, it makes sense to use ldap if one has several services over different machines,.. > > > >For most people password guessing isn't going to be a big problem as > > >the database won't be accessible from totally untrusted places and > > > watching the log files for guessing will probably be a good enough > > > solution. > > > > what if u do want the database to be globally accessible.. > > Then you have a much more difficult situation. One option is to bind > user names to specific allowed IP addresses. not a option, due to user requirements not an easy problem: it always seems to end up in DoS vs Brute Force Cracking. So the only good and simple solution i can think of: use the best possible password encrytion (or sufficient, a statistically zero chance when trying as much connections -to brute force crack the password- as possible for a significant amount of time.) -- Wim Bertels
Вложения
On Tue, Apr 19, 2005 at 22:54:32 +0200, Wim Bertels <wim.bertels@khleuven.be> wrote: > > not an easy problem: it always seems to end up in DoS vs Brute Force Cracking. > So the only good and simple solution i can think of: use the best possible > password encrytion (or sufficient, a statistically zero chance when trying as > much connections -to brute force crack the password- as possible for a > significant amount of time.) Maybe you can use client side certificates. Those will be from a large enough space that guessing shouldn't be a problem. You should be able to make that work with PAM.
Bruno Wolff III schreef: >On Tue, Apr 19, 2005 at 22:54:32 +0200, > Wim Bertels <wim.bertels@khleuven.be> wrote: > > >>not an easy problem: it always seems to end up in DoS vs Brute Force Cracking. >>So the only good and simple solution i can think of: use the best possible >>password encrytion (or sufficient, a statistically zero chance when trying as >>much connections -to brute force crack the password- as possible for a >>significant amount of time.) >> >> > >Maybe you can use client side certificates. Those will be from a large >enough space that guessing shouldn't be a problem. You should be able to >make that work with PAM. > > indeed. since brute force attacks are quit traceable (targetting one and the same user eg..), one could a script to check: - the percentage of failed logins/user, depending on the percentage (eg 75% or more failed, this should be configurable), these events should be reporteg in security.log file under the postgres log directory, or mailed to user (inetd...) - if there are more than eg 10 (this should be configurable) failed consecutive logins/user, this should again be reported. if i have time: maybe a quick perl script using the postgres.log file with sufficient logging to obtain these facts? so: possible implementation so far: 1. choose the possible crypting for the password 2. implement someway the above checking (% failed logins/user + < failed login/user) 3. using client side certificates with pam, pam_ldap (not sure how to set this up right know, a certificate/user (having many users, not all specialists,..., how to make this work a user-acceptible way..); or just a few (or 1) client side certificates that can be used by many users (sounds more easy, accessible to set up for the users)
* Bruno Wolff III <bruno@wolff.to> wrote: > Maybe you can use client side certificates. how can they be used w/ psql ? cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact@metux.de --------------------------------------------------------------------- Realtime Forex/Stock Exchange trading powered by postgresSQL :)) http://www.fxignal.net/ ---------------------------------------------------------------------
* Wim Bertels <wim.bertels@khleuven.be> wrote: <snip> > since brute force attacks are quit traceable (targetting one and the > same user eg..), > one could a script to check: > - the percentage of failed logins/user, depending on the percentage (eg > 75% or more failed, this should be configurable), these events should be > reporteg in security.log file under the postgres log directory, or > mailed to user (inetd...) > - if there are more than eg 10 (this should be configurable) failed > consecutive logins/user, this should again be reported. BTW: is it possible to do this directly in the database - by rules and triggers on the appropriate system tables ? cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact@metux.de --------------------------------------------------------------------- Realtime Forex/Stock Exchange trading powered by postgresSQL :)) http://www.fxignal.net/ ---------------------------------------------------------------------
On Thu, May 12, 2005 at 00:23:05 +0200, Enrico Weigelt <weigelt@metux.de> wrote: > * Bruno Wolff III <bruno@wolff.to> wrote: > > > Maybe you can use client side certificates. > > how can they be used w/ psql ? You should be able to get PAM to do this, but I haven't tried it to make sure.