host name support in pg_hba.conf

Peter Eisentraut <peter_e@gmx.net> wrote:

The client's IP address (known from the kernel)

Some machines have several IP addresses; how is that handled?

is reverse looked up, which results in a host name.

Some IP addresses have several host names, including in reverse
lookup; how is that handled?

-Kevin

On 9 August 2010 19:47, Peter Eisentraut <peter_e@gmx.net> wrote:

Here is a patch for host name support in pg_hba.conf.  I have reviewed
various past threads about this, and there appeared to have been a 50/50
split of for and against reverse lookup.  I went with the reverse
lookup, because

0) I like it.

1) It is more secure.

2) It allows extending it to wildcards in the future.

3) Apache (Allow from) does it that way.

To clarify how it works:  The client's IP address (known from the
kernel) is reverse looked up, which results in a host name.  That host
name is compared with the line in pg_hba.conf.  If it matches, a forward
lookup is performed on the host name to check if any of the resulting IP
addresses match the client's IP address.  If yes, the line is considered
to match and the authentication method is selected.

Anyway, assuming we will go with this, you will also notice that in the
patch I changed the default pg_hba.conf to match against "localhost"
instead of numeric addresses.  Initially thought of as a temporary
change for testing this patch, I think this might actually have some
permanent value because it saves you from having to change the IPv4 and
IPv6 lines in tandem most of the times, which is a moderately common
mistake.  We already rely on localhost being (forward) resolvable for
the stats collector.

Something to think about: Maybe we need a quoting mechanism in case
someone names their hosts "samenet".

--

A couple things:

+       matches.  This field can contain either a host name, an IP
+       address range, one of the special key words mentioned below.
+      </para>

s/, one/, or one/

+       If a host name is specified (anything that is not an IP address
+       or a special key word is processed as a potential host name), a
+       reverse DNS lookup is performed on the client's IP address,
+       then a forward DNS lookup on the resulting name to check if it
+       matches the original IP address (that is, at least one of the
+       potentially many IP addresses matches the original one), and
+       the name found in the reverse lookup is compared with the
+       specified host name.

That's one loooong sentence!

--
Thom Brown
Registered Linux user: #516935

On Mon, Aug 9, 2010 at 2:47 PM, Peter Eisentraut <peter_e@gmx.net> wrote:

Here is a patch for host name support in pg_hba.conf.  I have reviewed
various past threads about this, and there appeared to have been a 50/50
split of for and against reverse lookup.  I went with the reverse
lookup, because

0) I like it.

1) It is more secure.

2) It allows extending it to wildcards in the future.

3) Apache (Allow from) does it that way.

To clarify how it works:  The client's IP address (known from the
kernel) is reverse looked up, which results in a host name.  That host
name is compared with the line in pg_hba.conf.  If it matches, a forward
lookup is performed on the host name to check if any of the resulting IP
addresses match the client's IP address.  If yes, the line is considered
to match and the authentication method is selected.

Seems reasonable.

Anyway, assuming we will go with this, you will also notice that in the
patch I changed the default pg_hba.conf to match against "localhost"
instead of numeric addresses.  Initially thought of as a temporary
change for testing this patch, I think this might actually have some
permanent value because it saves you from having to change the IPv4 and
IPv6 lines in tandem most of the times, which is a moderately common
mistake.  We already rely on localhost being (forward) resolvable for
the stats collector.

-1 from me, on this part. I think we should be trying to eliminate
any dependencies we have on how localhost resolves, and we certainly
should not add more. I have spent way too much time fighting with
problems caused by localhost being present/absent in /etc/hosts; and
more caused by whether it maps to 127.0.0.1 or some IP assigned to one
of the boxes' Ethernet cards. What's really special is when you have
two parts of the system, one of which will only work with one version
of /etc/hosts and the other of which will only work with a different
version. I humbly, but fervently, suggest that we try to avoid being
polemical about this.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Peter Eisentraut <peter_e@gmx.net> writes:

Here is a patch for host name support in pg_hba.conf.

My recollection is that the previous discussions got stuck on the cost
of doing DNS lookups for every connect; and the obvious solution of
trying to cache the names was shot down on the basis of not knowing when
to flush the cache. Have you decided that people who want this feature
will just have to pay that cost? If so, I think the documentation needs
to be a bit more explicit about names being more expensive than IP
addresses in pg_hba.conf.

regards, tom lane

* Kevin Grittner (Kevin.Grittner@wicourts.gov) wrote:

The client's IP address (known from the kernel)

Some machines have several IP addresses; how is that handled?

Sounds like he already described it, or I read it wrong. The fact that
some machines have several IP addresses hardly matters- whatever IP is
used to connect to PG is what gets the reverse DNS lookup. That then
returns a host. That host is then looked up, and as long as *one* of
the IPs associated with that host matches the IP of the connector, it's
good to go.

is reverse looked up, which results in a host name.

Some IP addresses have several host names, including in reverse
lookup; how is that handled?

Yeahhhh... That's just busted, imnsho. But then, that's probably
because it breaks Kerberos too. :)

Thanks,

Stephen

On Mon, Aug 09, 2010 at 03:25:23PM -0400, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Here is a patch for host name support in pg_hba.conf.

My recollection is that the previous discussions got stuck on the cost
of doing DNS lookups for every connect; and the obvious solution of
trying to cache the names was shot down on the basis of not knowing when
to flush the cache. Have you decided that people who want this feature
will just have to pay that cost? If so, I think the documentation needs
to be a bit more explicit about names being more expensive than IP
addresses in pg_hba.conf.

I am also a bit scared of the startup cost for each connection.

In which order are things evaluated? What if I only include IP
addresses in my pg_hba, will it still cost me a DNS lookup or
two?

Kind regards,
Kristian.

-- 
Kristian Larsson                                        KLL-RIPE
+46 704 264511			              kll@spritelink.net

On mån, 2010-08-09 at 15:05 -0400, Robert Haas wrote:

-1 from me, on this part. I think we should be trying to eliminate
any dependencies we have on how localhost resolves, and we certainly
should not add more.

Maybe this is something that distributors could add if they have more
knowledge about the "localhost" policies on their hosts.

On mån, 2010-08-09 at 13:56 -0500, Kevin Grittner wrote:

Peter Eisentraut <peter_e@gmx.net> wrote:

The client's IP address (known from the kernel)

Some machines have several IP addresses; how is that handled?

A connection comes in over exactly one address.

is reverse looked up, which results in a host name.

Some IP addresses have several host names, including in reverse
lookup; how is that handled?

This is not possible, or at least the C library APIs don't expose it.
Compare the getnameinfo() and getaddrinfo() man pages, for example.

On mån, 2010-08-09 at 23:01 +0200, Kristian Larsson wrote:

In which order are things evaluated? What if I only include IP
addresses in my pg_hba, will it still cost me a DNS lookup or
two?

No, if you don't use this feature, it won't cost you anything.

On mån, 2010-08-09 at 15:25 -0400, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Here is a patch for host name support in pg_hba.conf.

My recollection is that the previous discussions got stuck on the cost
of doing DNS lookups for every connect; and the obvious solution of
trying to cache the names was shot down on the basis of not knowing when
to flush the cache. Have you decided that people who want this feature
will just have to pay that cost?

Either that or install nscd.

While the speed of establishing a connection is critical to some setups,
there are also plenty of setups where the connection setup speed is
pretty much unimportant because of connection pooling.

If so, I think the documentation needs
to be a bit more explicit about names being more expensive than IP
addresses in pg_hba.conf.

Fair enough.

Peter Eisentraut wrote:

On mån, 2010-08-09 at 13:56 -0500, Kevin Grittner wrote:

Peter Eisentraut wrote:

is reverse looked up, which results in a host name.

Some IP addresses have several host names, including in reverse
lookup; how is that handled?

This is not possible,

http://en.wikipedia.org/wiki/Reverse_DNS_lookup#Multiple_pointer_records

or at least the C library APIs don't expose it.

That may explain the prevalence of bugs in code dealing with it.

-Kevin

On tis, 2010-08-10 at 07:32 -0500, Kevin Grittner wrote:

http://en.wikipedia.org/wiki/Reverse_DNS_lookup#Multiple_pointer_records

Yeah, you can configure all kinds of nonsense and sometimes even get
away with it, but the basic assumption throughout is that a system has
one host name and between 1 and many IP addresses. We must make our
implementation robust again other setups, but we don't have to (or
rather cannot) support them.

On Tue, Aug 10, 2010 at 10:05 AM, Peter Eisentraut <peter_e@gmx.net> wrote:

On tis, 2010-08-10 at 07:32 -0500, Kevin Grittner wrote:

http://en.wikipedia.org/wiki/Reverse_DNS_lookup#Multiple_pointer_records

Yeah, you can configure all kinds of nonsense and sometimes even get
away with it, but the basic assumption throughout is that a system has
one host name and between 1 and many IP addresses.

These days, I think it's more common the other way around: one IP
address, and many host names.

We must make our
implementation robust again other setups, but we don't have to (or
rather cannot) support them.

"Cannot" is a good argument for not supporting just about anything.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Peter Eisentraut <peter_e@gmx.net> wrote:

Yeah, you can configure all kinds of nonsense and sometimes even
get away with it, but the basic assumption throughout is that a
system has one host name and between 1 and many IP addresses.

It's hardly nonsense to have multiple names on a machine. While we
usually avoid having multiple reverse lookup names, we have many
in-house web applications and we neither want users to access them
by IP address or have to worry about which web server is hosting
which applications at the moment. So it's not unusual for one of
our web servers to have 10 or 15 DNS names for forward lookup. If
one machine becomes overloaded, we can move an application, change
the DNS, and everyone's bookmark still works. This is precisely the
sort of situation where using a hostname in pg_hba.conf would be
most useful.

We must make our implementation robust again other setups, but we
don't have to (or rather cannot) support them.

Without the logic to ensure that the hostname matches the reverse
lookup, this might be useful for us. With that logic it is useless
for us. I'm wondering how much you gain by having it in there. Why
can't a forward lookup which matches the requesting IP be considered
sufficient?

-Kevin

On tis, 2010-08-10 at 10:11 -0400, Robert Haas wrote:

These days, I think it's more common the other way around: one IP
address, and many host names.

Yes, that setup is very common, but it's actually only an illusion that
DNS creates. The actual machine still has only one host name and some
IP addresses, as far as the kernel is concerned. As you are surely
aware, this situation creates all kinds of problems in practice.

On tis, 2010-08-10 at 09:18 -0500, Kevin Grittner wrote:

Without the logic to ensure that the hostname matches the reverse
lookup, this might be useful for us. With that logic it is useless
for us. I'm wondering how much you gain by having it in there. Why
can't a forward lookup which matches the requesting IP be considered
sufficient?

For one thing, because people might like to add wildcard support. So I
might be able to say

host all all appserver*.example.com md5

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:

Without the logic to ensure that the hostname matches the reverse
lookup, this might be useful for us. With that logic it is useless
for us. I'm wondering how much you gain by having it in there. Why
can't a forward lookup which matches the requesting IP be considered
sufficient?

I was about to complain about that same thing. ISTM the logic ought
to be that you do a forward DNS lookup on the name presented in
pg_hba.conf, and if any of the returned IP addresses match the
connection's remote IP address, then you have a match. This business
with doing a reverse lookup is at least twice as expensive, far more
fragile, and it seems completely bogus from a security viewpoint.
Why should I trust the RDNS server for an attacker's IP address?

regards, tom lane

* Tom Lane <tgl@sss.pgh.pa.us> [100810 10:39]:

I was about to complain about that same thing. ISTM the logic ought
to be that you do a forward DNS lookup on the name presented in
pg_hba.conf, and if any of the returned IP addresses match the
connection's remote IP address, then you have a match. This business
with doing a reverse lookup is at least twice as expensive, far more
fragile, and it seems completely bogus from a security viewpoint.
Why should I trust the RDNS server for an attacker's IP address?

Well, you don't trust the RDNS of the IP, you trust the normal lookup of
the hostname returned by the RDNS. So if some other ip network is
trying to give hostnames that should be authorized, you see that
immediately when you resolve the "authorized" hostname and it doesn't
give you that IP.

The PTR query is a means to get the "hostname" to check against, so you
d'nt have to pre-cache all thos possible results of all the hostnames.
Pre-caching all the hostnames in pg_hba.conf is madness. How long do
you cache them for? or do send out 1000 queries every connection? You
can't support wildcards, or anythign usefull...

AFAIK, every software I've used which allows hostnames as some
connection control all do PTR->A/AAAA lookups as Peter proposed.

a.

--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.

On tis, 2010-08-10 at 10:39 -0400, Tom Lane wrote:

I was about to complain about that same thing. ISTM the logic ought
to be that you do a forward DNS lookup on the name presented in
pg_hba.conf, and if any of the returned IP addresses match the
connection's remote IP address, then you have a match. This business
with doing a reverse lookup is at least twice as expensive, far more
fragile, and it seems completely bogus from a security viewpoint.

If you have hundreds on lines in pg_hba.conf, then you need to do
hundreds of DNS lookups per connection attempt (*), and each of those
lookups could result in even more IP addresses, or could time out. So
if some unrelated part of the system breaks (DNS down), it could take
you hours to establish a connection. On the other hand, with the
reverse DNS lookup, you would normally do about two DNS queries per
successful connection attempt, and those would only be in relation to
the machines actually involved in the connection. Also, if you are in a
names-only environment, you might also like to turn on log_hostnames, in
which case the reverse lookup is free (well, shared).

(*) That could of course be addressed by your earlier idea of caching
the resolved names when pg_hba.conf is read, but I don't think many
people were on board with that idea.