Re: [HACKERS] contrib: auth_delay module
On Sat, Nov 27, 2010 at 2:44 PM, Jeff Janes jeff.ja...@gmail.com wrote: On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost sfr...@snowman.net wrote: * Jan Urbański (wulc...@wulczer.org) wrote: On 04/11/10 14:09, Robert Haas wrote: Hmm, I wonder how useful this is given that restriction. As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie consuming), right? Which it would still do, since the attacker would be bumping up against max_connections. max_connections would be a DOS point, but that's no different from today. I haven' t thought of a way to test this, so I guess I'll just ask. If the attacking client just waits a few milliseconds for a response and then drops the socket, opening a new one, will the server-side walking-dead process continue to be charged against max_connections until it's sleep expires? I'm not sure, either. I suspect the answer is yes. I guess you could test this by writing a loop like this: while true; do psql connection parameters that will fail authentication; done ...and then hitting ^C every few seconds during execution. After doing that for a bit, run select * from pg_stat_activity or ps auxww | grep postgres in another window. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Sun, Nov 28, 2010 at 5:38 AM, Robert Haas robertmh...@gmail.com wrote: On Sat, Nov 27, 2010 at 2:44 PM, Jeff Janes jeff.ja...@gmail.com wrote: I haven' t thought of a way to test this, so I guess I'll just ask. If the attacking client just waits a few milliseconds for a response and then drops the socket, opening a new one, will the server-side walking-dead process continue to be charged against max_connections until it's sleep expires? I'm not sure, either. I suspect the answer is yes. I guess you could test this by writing a loop like this: while true; do psql connection parameters that will fail authentication; done ...and then hitting ^C every few seconds during execution. After doing that for a bit, run select * from pg_stat_activity or ps auxww | grep postgres in another window. Right, I didn't think of using psql, I thought I'd have to wrangle my own socket code. I wrote up a perl script that spawns psql and immediately kills it. I quickly start getting psql: FATAL: sorry, too many clients already errors. And that condition doesn't clear until the sleep expires on the earliest ones spawned. So it looks like the max_connections is charged until the auth_delay expires. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Sun, Nov 28, 2010 at 5:41 PM, Jeff Janes jeff.ja...@gmail.com wrote: On Sun, Nov 28, 2010 at 5:38 AM, Robert Haas robertmh...@gmail.com wrote: On Sat, Nov 27, 2010 at 2:44 PM, Jeff Janes jeff.ja...@gmail.com wrote: I haven' t thought of a way to test this, so I guess I'll just ask. If the attacking client just waits a few milliseconds for a response and then drops the socket, opening a new one, will the server-side walking-dead process continue to be charged against max_connections until it's sleep expires? I'm not sure, either. I suspect the answer is yes. I guess you could test this by writing a loop like this: while true; do psql connection parameters that will fail authentication; done ...and then hitting ^C every few seconds during execution. After doing that for a bit, run select * from pg_stat_activity or ps auxww | grep postgres in another window. Right, I didn't think of using psql, I thought I'd have to wrangle my own socket code. I wrote up a perl script that spawns psql and immediately kills it. I quickly start getting psql: FATAL: sorry, too many clients already errors. And that condition doesn't clear until the sleep expires on the earliest ones spawned. So it looks like the max_connections is charged until the auth_delay expires. Yeah. Avoiding that would be hard, and it's not clear that there's any demand. The demand for doing this much seems a bit marginal too, but there were several people who seemed to think it worth committing, so I did. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Sun, Nov 28, 2010 at 3:57 PM, Robert Haas robertmh...@gmail.com wrote: On Sun, Nov 28, 2010 at 5:41 PM, Jeff Janes jeff.ja...@gmail.com wrote: On Sun, Nov 28, 2010 at 5:38 AM, Robert Haas robertmh...@gmail.com wrote: On Sat, Nov 27, 2010 at 2:44 PM, Jeff Janes jeff.ja...@gmail.com wrote: I haven' t thought of a way to test this, so I guess I'll just ask. If the attacking client just waits a few milliseconds for a response and then drops the socket, opening a new one, will the server-side walking-dead process continue to be charged against max_connections until it's sleep expires? I'm not sure, either. I suspect the answer is yes. I guess you could test this by writing a loop like this: while true; do psql connection parameters that will fail authentication; done ...and then hitting ^C every few seconds during execution. After doing that for a bit, run select * from pg_stat_activity or ps auxww | grep postgres in another window. Right, I didn't think of using psql, I thought I'd have to wrangle my own socket code. I wrote up a perl script that spawns psql and immediately kills it. I quickly start getting psql: FATAL: sorry, too many clients already errors. And that condition doesn't clear until the sleep expires on the earliest ones spawned. So it looks like the max_connections is charged until the auth_delay expires. Yeah. Avoiding that would be hard, and it's not clear that there's any demand. The demand for doing this much seems a bit marginal too, but there were several people who seemed to think it worth committing, so I did. Oh, I wasn't complaining. I think that having max_connections be charged for the duration even if the socket is dropped is the only reasonable thing to do, and wanted to verify that it did happen. Otherwise the module wouldn't do a very good job at its purpose, the attacker would simply wait a few milliseconds and then assume it got the wrong password and kill the connection and start new one. Preventing the brute force password attack by shunting it into a DOS attack instead seems reasonable. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Sun, Nov 28, 2010 at 7:10 PM, Jeff Janes jeff.ja...@gmail.com wrote: Oh, I wasn't complaining. I think that having max_connections be charged for the duration even if the socket is dropped is the only reasonable thing to do, and wanted to verify that it did happen. Otherwise the module wouldn't do a very good job at its purpose, the attacker would simply wait a few milliseconds and then assume it got the wrong password and kill the connection and start new one. Good point. Preventing the brute force password attack by shunting it into a DOS attack instead seems reasonable. OK. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Sat, Nov 27, 2010 at 9:25 PM, Robert Haas robertmh...@gmail.com wrote: On Thu, Nov 25, 2010 at 1:18 AM, KaiGai Kohei kai...@ak.jp.nec.com wrote: The attached patch is revised version. - Logging part within auth_delay was removed. This module now focuses on injection of a few seconds delay on authentication failed. - Documentation parts were added like any other contrib modules. Committed, with a few adjustments. Per Fujii Masao's suggestion, I changed sleep() to pg_usleep(); I also changed the GUC to be reckoned in milliseconds rather than seconds. Thanks. I found the typo: - diff --git a/contrib/README b/contrib/README index 9e223ef..8a12cc1 100644 --- a/contrib/README +++ b/contrib/README @@ -30,7 +30,7 @@ adminpack - auth_delay Add a short delay after a failed authentication attempt, to make -make brute-force attacks on database passwords a bit harder. + brute-force attacks on database passwords a bit harder. by KaiGai Kohei kai...@ak.jp.nec.com auto_explain - - Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Sun, Nov 28, 2010 at 7:45 PM, Fujii Masao masao.fu...@gmail.com wrote: Thanks. I found the typo: I only have one? :-) Thanks, fixed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Thu, Nov 25, 2010 at 1:18 AM, KaiGai Kohei kai...@ak.jp.nec.com wrote: The attached patch is revised version. - Logging part within auth_delay was removed. This module now focuses on injection of a few seconds delay on authentication failed. - Documentation parts were added like any other contrib modules. Committed, with a few adjustments. Per Fujii Masao's suggestion, I changed sleep() to pg_usleep(); I also changed the GUC to be reckoned in milliseconds rather than seconds. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost sfr...@snowman.net wrote: * Jan Urbański (wulc...@wulczer.org) wrote: On 04/11/10 14:09, Robert Haas wrote: Hmm, I wonder how useful this is given that restriction. As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie consuming), right? Which it would still do, since the attacker would be bumping up against max_connections. max_connections would be a DOS point, but that's no different from today. I haven' t thought of a way to test this, so I guess I'll just ask. If the attacking client just waits a few milliseconds for a response and then drops the socket, opening a new one, will the server-side walking-dead process continue to be charged against max_connections until it's sleep expires? Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Thu, Nov 25, 2010 at 9:54 PM, KaiGai Kohei kai...@ak.jp.nec.com wrote: I'll revise my patch. How about _PG_fini()? In modules like auto_explain and pg_stat_statements, we have some token code in there to handle unload, but I don't believe there's any way to invoke it, nor would it work if there were multiple users of the hook. passwordcheck, on the other hand, has no _PG_fini, which seems like the more sensible approach since it isn't going to work anyway. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Thu, Nov 25, 2010 at 3:18 PM, KaiGai Kohei kai...@ak.jp.nec.com wrote:
The attached patch is revised version.
- Logging part within auth_delay was removed. This module now focuses on
injection of a few seconds delay on authentication failed.
- Documentation parts were added like any other contrib modules.
Something like the following is not required? Though I'm not sure
if there is the case where auth_delay is unload.
void
_PG_fini(void)
{
/* Uninstall hooks. */
ClientAuthentication_hook = original_client_auth_hook;
}
+ if (status != STATUS_OK)
+ {
+ sleep(auth_delay_seconds);
+ }
We should use pg_usleep rather than sleep?
+ DefineCustomIntVariable(auth_delay.seconds,
+ Seconds to be delayed
on authentication failed,
+ NULL,
+ auth_delay_seconds,
+ 2,
+ 0, INT_MAX,
+ PGC_POSTMASTER,
+ GUC_UNIT_S,
+ NULL,
+ NULL);
Can we relax the context from PGC_POSTMASTER to PGC_SIGHUP?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
(2010/11/26 11:35), Fujii Masao wrote:
On Thu, Nov 25, 2010 at 3:18 PM, KaiGai Koheikai...@ak.jp.nec.com wrote:
The attached patch is revised version.
- Logging part within auth_delay was removed. This module now focuses on
injection of a few seconds delay on authentication failed.
- Documentation parts were added like any other contrib modules.
Something like the following is not required? Though I'm not sure
if there is the case where auth_delay is unload.
void
_PG_fini(void)
{
/* Uninstall hooks. */
ClientAuthentication_hook = original_client_auth_hook;
}
I'm not also sure whether we have situation libraries are unloaded.
Right now, internal_unload_library() is just a placeholder, so
it seems to me _PG_fini() is never invoked.
+ if (status != STATUS_OK)
+ {
+ sleep(auth_delay_seconds);
+ }
We should use pg_usleep rather than sleep?
Indeed, pg_usleep() is mainly used rather than sleep().
+ DefineCustomIntVariable(auth_delay.seconds,
+ Seconds to be delayed on
authentication failed,
+ NULL,
+ auth_delay_seconds,
+ 2,
+ 0, INT_MAX,
+ PGC_POSTMASTER,
+ GUC_UNIT_S,
+ NULL,
+ NULL);
Can we relax the context from PGC_POSTMASTER to PGC_SIGHUP?
It seems to me reasonable change.
I'll revise my patch. How about _PG_fini()?
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
(2010/11/19 16:57), KaiGai Kohei wrote:
(2010/11/18 2:17), Robert Haas wrote:
On Wed, Nov 17, 2010 at 10:32 AM, Ross J. Reedstromreeds...@rice.edu wrote:
On Tue, Nov 16, 2010 at 09:41:37PM -0500, Robert Haas wrote:
On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Koheikai...@ak.jp.nec.com wrote:
If we don't need a PoC module for each new hooks, I'm not strongly
motivated to push it into contrib tree.
How about your opinion?
I'd say let it go, unless someone else feels strongly about it.
I would use this module (rate limit new connection attempts) as soon as
I could. Putting a cap on potential CPU usage on a production DB by either
a blackhat or mistake by a developer caused by a mistake in
configuration (leaving the port accessible) is definitely useful, even
in the face of max_connections. My production apps already have
their connections and seldom need new ones. They all use CPU though.
If KaiGai updates the code per previous discussion, would you be
willing to take a crack at adding documentation?
P.S. Your email client seems to be setting the Reply-To address to a
ridiculous value.
OK, I'll revise my patch according to the previous discussion.
The attached patch is revised version.
- Logging part within auth_delay was removed. This module now focuses on
injection of a few seconds delay on authentication failed.
- Documentation parts were added like any other contrib modules.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
contrib/Makefile|1 +
contrib/README |5 +++
contrib/auth_delay/Makefile | 14 +++
contrib/auth_delay/auth_delay.c | 71
doc/src/sgml/auth-delay.sgml| 76 +++
doc/src/sgml/contrib.sgml |1 +
doc/src/sgml/filelist.sgml |1 +
7 files changed, 169 insertions(+), 0 deletions(-)
diff --git a/contrib/Makefile b/contrib/Makefile
index e1f2a84..5747bcc 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -6,6 +6,7 @@ include $(top_builddir)/src/Makefile.global
SUBDIRS = \
adminpack \
+ auth_delay \
auto_explain \
btree_gin \
btree_gist \
diff --git a/contrib/README b/contrib/README
index 6d29cfe..a6abd94 100644
--- a/contrib/README
+++ b/contrib/README
@@ -28,6 +28,11 @@ adminpack -
File and log manipulation routines, used by pgAdmin
by Dave Page dp...@vale-housing.co.uk
+auth_delay
+ Add a few second's delay on authentication failed. It enables to make
+ difficult brute-force attacks on database passwords.
+ by KaiGai Kohei kai...@ak.jp.nec.com
+
auto_explain -
Log EXPLAIN output for long-running queries
by Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp
diff --git a/contrib/auth_delay/Makefile b/contrib/auth_delay/Makefile
new file mode 100644
index 000..09d2d54
--- /dev/null
+++ b/contrib/auth_delay/Makefile
@@ -0,0 +1,14 @@
+# contrib/auth_delay/Makefile
+
+MODULES = auth_delay
+
+ifdef USE_PGXS
+PG_CONFIG = pg_config
+PGXS := $(shell $(PG_CONFIG) --pgxs)
+include $(PGXS)
+else
+subdir = contrib/auth_delay
+top_builddir = ../..
+include $(top_builddir)/src/Makefile.global
+include $(top_srcdir)/contrib/contrib-global.mk
+endif
diff --git a/contrib/auth_delay/auth_delay.c b/contrib/auth_delay/auth_delay.c
new file mode 100644
index 000..746ac4b
--- /dev/null
+++ b/contrib/auth_delay/auth_delay.c
@@ -0,0 +1,71 @@
+/* -
+ *
+ * auth_delay.c
+ *
+ * Copyright (C) 2010, PostgreSQL Global Development Group
+ *
+ * IDENTIFICATION
+ * contrib/auth_delay/auth_delay.c
+ *
+ * -
+ */
+#include postgres.h
+
+#include libpq/auth.h
+#include utils/guc.h
+#include utils/timestamp.h
+
+#include unistd.h
+
+PG_MODULE_MAGIC;
+
+void _PG_init(void);
+
+/* GUC Variables */
+static int auth_delay_seconds;
+
+/* Original Hook */
+static ClientAuthentication_hook_type original_client_auth_hook = NULL;
+
+/*
+ * Check authentication
+ */
+static void
+auth_delay_checks(Port *port, int status)
+{
+ /*
+ * Any other plugins which use the ClientAuthentication_hook.
+ */
+ if (original_client_auth_hook)
+ original_client_auth_hook(port, status);
+
+ /*
+ * Inject a few seconds delay on authentication failed.
+ */
+ if (status != STATUS_OK)
+ {
+ sleep(auth_delay_seconds);
+ }
+}
+
+/*
+ * Module Load Callback
+ */
+void
+_PG_init(void)
+{
+ /* Define custome GUC variables */
+ DefineCustomIntVariable(auth_delay.seconds,
+ Seconds to be delayed on authentication failed,
+ NULL,
+ auth_delay_seconds,
+ 2,
+ 0, INT_MAX,
+ PGC_POSTMASTER,
+ GUC_UNIT_S,
+ NULL,
+ NULL);
+ /* Install Hooks */
+ original_client_auth_hook = ClientAuthentication_hook;
+ ClientAuthentication_hook = auth_delay_checks;
+}
diff --git a/doc/src/sgml/auth-delay.sgml b/doc/src/sgml/auth-delay.sgml
new file mode 100644
index 000..372702d
---
Re: [HACKERS] contrib: auth_delay module
(2010/11/18 2:17), Robert Haas wrote: On Wed, Nov 17, 2010 at 10:32 AM, Ross J. Reedstromreeds...@rice.edu wrote: On Tue, Nov 16, 2010 at 09:41:37PM -0500, Robert Haas wrote: On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Koheikai...@ak.jp.nec.com wrote: If we don't need a PoC module for each new hooks, I'm not strongly motivated to push it into contrib tree. How about your opinion? I'd say let it go, unless someone else feels strongly about it. I would use this module (rate limit new connection attempts) as soon as I could. Putting a cap on potential CPU usage on a production DB by either a blackhat or mistake by a developer caused by a mistake in configuration (leaving the port accessible) is definitely useful, even in the face of max_connections. My production apps already have their connections and seldom need new ones. They all use CPU though. If KaiGai updates the code per previous discussion, would you be willing to take a crack at adding documentation? P.S. Your email client seems to be setting the Reply-To address to a ridiculous value. OK, I'll revise my patch according to the previous discussion. Please wait for about one week. I have a big event in this weekend. Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Fri, Nov 19, 2010 at 04:57:03PM +0900, KaiGai Kohei wrote: (2010/11/18 2:17), Robert Haas wrote: If KaiGai updates the code per previous discussion, would you be willing to take a crack at adding documentation? P.S. Your email client seems to be setting the Reply-To address to a ridiculous value. OK, I'll revise my patch according to the previous discussion. Please wait for about one week. I have a big event in this weekend. I'll take a crack at the docs, though I might need hand-holding for the new git stuff (I'll hit the wiki) Ross -- Ross Reedstrom, Ph.D. reeds...@rice.edu Systems Engineer Admin, Research Scientistphone: 713-348-6166 Connexions http://cnx.orgfax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Tue, Nov 16, 2010 at 09:41:37PM -0500, Robert Haas wrote: On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Kohei kai...@ak.jp.nec.com wrote: If we don't need a PoC module for each new hooks, I'm not strongly motivated to push it into contrib tree. How about your opinion? I'd say let it go, unless someone else feels strongly about it. I would use this module (rate limit new connection attempts) as soon as I could. Putting a cap on potential CPU usage on a production DB by either a blackhat or mistake by a developer caused by a mistake in configuration (leaving the port accessible) is definitely useful, even in the face of max_connections. My production apps already have their connections and seldom need new ones. They all use CPU though. Ross -- Ross Reedstrom, Ph.D. reeds...@rice.edu Systems Engineer Admin, Research Scientistphone: 713-348-6166 Connexions http://cnx.orgfax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Wed, Nov 17, 2010 at 10:32 AM, Ross J. Reedstrom reeds...@rice.edu wrote: On Tue, Nov 16, 2010 at 09:41:37PM -0500, Robert Haas wrote: On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Kohei kai...@ak.jp.nec.com wrote: If we don't need a PoC module for each new hooks, I'm not strongly motivated to push it into contrib tree. How about your opinion? I'd say let it go, unless someone else feels strongly about it. I would use this module (rate limit new connection attempts) as soon as I could. Putting a cap on potential CPU usage on a production DB by either a blackhat or mistake by a developer caused by a mistake in configuration (leaving the port accessible) is definitely useful, even in the face of max_connections. My production apps already have their connections and seldom need new ones. They all use CPU though. If KaiGai updates the code per previous discussion, would you be willing to take a crack at adding documentation? P.S. Your email client seems to be setting the Reply-To address to a ridiculous value. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
(2010/11/15 11:50), Robert Haas wrote: On Thu, Nov 4, 2010 at 10:04 AM, Robert Haasrobertmh...@gmail.com wrote: On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frostsfr...@snowman.net wrote: * Jan Urbański (wulc...@wulczer.org) wrote: On 04/11/10 14:09, Robert Haas wrote: Hmm, I wonder how useful this is given that restriction. As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie consuming), right? Which it would still do, since the attacker would be bumping up against max_connections. max_connections would be a DOS point, but that's no different from today. Other things could be put in place to address that (max # of connections from a given IP or range could be implemented using iptables, as an example). 5 second delay w/ max connections at 100 would mean max of 20 attempts per second, no? That's alot fewer than 100*(however many attempts can be done in a second). Doing a stupid while true; psql -d blah; done managed to get 50 successful ident auths+no-db-found errors done in a second on one box here. 5000 20, and I wasn't even trying. OK. I was just asking. I don't object to it if people think it's useful, especially if they are looking at it as I would actually use this on my system rather than I can imagine a hypothetical person using this. I haven't heard anyone say yes, I would actually use this on my system? Any takers? My original motivation is to provide a proof of concept module for the ClientAuthentication_hook, to show this hook is useful to other purposes not only getpeercon() in SE-PgSQL. If we don't need a PoC module for each new hooks, I'm not strongly motivated to push it into contrib tree. How about your opinion? If we're to commit this, then the patch needs to add a new file authdelay.smgl, fill it in with appropriate contents, and update contrib.sgml and filelist.sgml accordingly. Sorry, I missed the manner of contrib modules. It seems to me the dummy_seclabel module also lacks these documentation updates, although its purpose is regression testing. I also note that the patch offers the ability to log superuser logins. Since that seems a bit off-topic for a contrib module called auth_delay, and since we already have a GUC called log_connections, I'm inclined to propose removing that part. I agree with the suggestion. Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Kohei kai...@ak.jp.nec.com wrote: If we don't need a PoC module for each new hooks, I'm not strongly motivated to push it into contrib tree. How about your opinion? I'd say let it go, unless someone else feels strongly about it. Sorry, I missed the manner of contrib modules. It seems to me the dummy_seclabel module also lacks these documentation updates, although its purpose is regression testing. Ah, we should probably fix that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Thu, Nov 4, 2010 at 10:04 AM, Robert Haas robertmh...@gmail.com wrote: On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost sfr...@snowman.net wrote: * Jan Urbański (wulc...@wulczer.org) wrote: On 04/11/10 14:09, Robert Haas wrote: Hmm, I wonder how useful this is given that restriction. As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie consuming), right? Which it would still do, since the attacker would be bumping up against max_connections. max_connections would be a DOS point, but that's no different from today. Other things could be put in place to address that (max # of connections from a given IP or range could be implemented using iptables, as an example). 5 second delay w/ max connections at 100 would mean max of 20 attempts per second, no? That's alot fewer than 100*(however many attempts can be done in a second). Doing a stupid while true; psql -d blah; done managed to get 50 successful ident auths+no-db-found errors done in a second on one box here. 5000 20, and I wasn't even trying. OK. I was just asking. I don't object to it if people think it's useful, especially if they are looking at it as I would actually use this on my system rather than I can imagine a hypothetical person using this. I haven't heard anyone say yes, I would actually use this on my system? Any takers? If we're to commit this, then the patch needs to add a new file authdelay.smgl, fill it in with appropriate contents, and update contrib.sgml and filelist.sgml accordingly. I also note that the patch offers the ability to log superuser logins. Since that seems a bit off-topic for a contrib module called auth_delay, and since we already have a GUC called log_connections, I'm inclined to propose removing that part. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] contrib: auth_delay module
The attached patch is a contrib module to inject a few seconds delay on authentication failed. It is also a proof of the concept using the new ClientAuthentication_hook. This module provides a similar feature to pam_faildelay on operating systems. Injection of a few seconds delay on authentication fails prevents (or makes hard at least) brute-force attacks, because it limits number of candidates that attacker can verify within a unit of time. Thanks, -- KaiGai Kohei kai...@kaigai.gr.jp pgsql-v9.1-auth-delay.1.patch Description: application/octect-stream -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
2010/11/4 KaiGai Kohei kai...@kaigai.gr.jp: The attached patch is a contrib module to inject a few seconds delay on authentication failed. It is also a proof of the concept using the new ClientAuthentication_hook. This module provides a similar feature to pam_faildelay on operating systems. Injection of a few seconds delay on authentication fails prevents (or makes hard at least) brute-force attacks, because it limits number of candidates that attacker can verify within a unit of time. +1 for the feature. We have post_auth_delay parameter, but it has different purpose; it's as DEVELOPER_OPTIONS for delay to attach a debugger. BTW, the module could save CPU usage of the server on attacks, but do nothing about connection flood attacks, right? If an attacker attacks the server with multiple connections, the server still consumes max_connections even with the module. -- Itagaki Takahiro -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Thu, Nov 4, 2010 at 6:05 AM, Itagaki Takahiro itagaki.takah...@gmail.com wrote: 2010/11/4 KaiGai Kohei kai...@kaigai.gr.jp: The attached patch is a contrib module to inject a few seconds delay on authentication failed. It is also a proof of the concept using the new ClientAuthentication_hook. This module provides a similar feature to pam_faildelay on operating systems. Injection of a few seconds delay on authentication fails prevents (or makes hard at least) brute-force attacks, because it limits number of candidates that attacker can verify within a unit of time. +1 for the feature. We have post_auth_delay parameter, but it has different purpose; it's as DEVELOPER_OPTIONS for delay to attach a debugger. BTW, the module could save CPU usage of the server on attacks, but do nothing about connection flood attacks, right? If an attacker attacks the server with multiple connections, the server still consumes max_connections even with the module. Hmm, I wonder how useful this is given that restriction. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On 04/11/10 14:09, Robert Haas wrote: On Thu, Nov 4, 2010 at 6:05 AM, Itagaki Takahiro itagaki.takah...@gmail.com wrote: 2010/11/4 KaiGai Kohei kai...@kaigai.gr.jp: The attached patch is a contrib module to inject a few seconds delay on authentication failed. It is also a proof of the concept using the new ClientAuthentication_hook. This module provides a similar feature to pam_faildelay on operating systems. Injection of a few seconds delay on authentication fails prevents (or makes hard at least) brute-force attacks, because it limits number of candidates that attacker can verify within a unit of time. +1 for the feature. We have post_auth_delay parameter, but it has different purpose; it's as DEVELOPER_OPTIONS for delay to attach a debugger. BTW, the module could save CPU usage of the server on attacks, but do nothing about connection flood attacks, right? If an attacker attacks the server with multiple connections, the server still consumes max_connections even with the module. Hmm, I wonder how useful this is given that restriction. As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie consuming), right? Jan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
* Jan Urbański (wulc...@wulczer.org) wrote: On 04/11/10 14:09, Robert Haas wrote: Hmm, I wonder how useful this is given that restriction. As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie consuming), right? Which it would still do, since the attacker would be bumping up against max_connections. max_connections would be a DOS point, but that's no different from today. Other things could be put in place to address that (max # of connections from a given IP or range could be implemented using iptables, as an example). 5 second delay w/ max connections at 100 would mean max of 20 attempts per second, no? That's alot fewer than 100*(however many attempts can be done in a second). Doing a stupid while true; psql -d blah; done managed to get 50 successful ident auths+no-db-found errors done in a second on one box here. 5000 20, and I wasn't even trying. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] contrib: auth_delay module
(2010/11/04 22:05), Itagaki Takahiro wrote: 2010/11/4 KaiGai Koheikai...@kaigai.gr.jp: The attached patch is a contrib module to inject a few seconds delay on authentication failed. It is also a proof of the concept using the new ClientAuthentication_hook. This module provides a similar feature to pam_faildelay on operating systems. Injection of a few seconds delay on authentication fails prevents (or makes hard at least) brute-force attacks, because it limits number of candidates that attacker can verify within a unit of time. +1 for the feature. We have post_auth_delay parameter, but it has different purpose; it's as DEVELOPER_OPTIONS for delay to attach a debugger. BTW, the module could save CPU usage of the server on attacks, but do nothing about connection flood attacks, right? If an attacker attacks the server with multiple connections, the server still consumes max_connections even with the module. Good point. The pam_faildelay being the model of this feature also does nothing for flood of connections attack. However, if it closes the connection immediately, the attacker can try to verify next candidate very soon. Do you have any good idea? Thanks, -- KaiGai Kohei kai...@kaigai.gr.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib: auth_delay module
On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost sfr...@snowman.net wrote: * Jan Urbański (wulc...@wulczer.org) wrote: On 04/11/10 14:09, Robert Haas wrote: Hmm, I wonder how useful this is given that restriction. As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie consuming), right? Which it would still do, since the attacker would be bumping up against max_connections. max_connections would be a DOS point, but that's no different from today. Other things could be put in place to address that (max # of connections from a given IP or range could be implemented using iptables, as an example). 5 second delay w/ max connections at 100 would mean max of 20 attempts per second, no? That's alot fewer than 100*(however many attempts can be done in a second). Doing a stupid while true; psql -d blah; done managed to get 50 successful ident auths+no-db-found errors done in a second on one box here. 5000 20, and I wasn't even trying. OK. I was just asking. I don't object to it if people think it's useful, especially if they are looking at it as I would actually use this on my system rather than I can imagine a hypothetical person using this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
