Обсуждение: Why don't we allow DNS names in pg_hba.conf?
I was reminded of $subject by http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php While I haven't tried it, I suspect that allowing a DNS host name would take little work (basically removing the AI_NUMERICHOST flag passed to getaddrinfo in hba.c). There was once a good reason not to allow it: slow DNS lookups would lock up the postmaster. But now that we do this work in an already-forked backend, with an overall timeout that would catch any indefinite blockage, I don't see a good reason why we shouldn't let people use DNS names. Thoughts? regards, tom lane
On Sun, 1 Jan 2006, Tom Lane wrote: > I was reminded of $subject by > http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php > > While I haven't tried it, I suspect that allowing a DNS host name > would take little work (basically removing the AI_NUMERICHOST flag > passed to getaddrinfo in hba.c). There was once a good reason not > to allow it: slow DNS lookups would lock up the postmaster. But > now that we do this work in an already-forked backend, with an overall > timeout that would catch any indefinite blockage, I don't see a good > reason why we shouldn't let people use DNS names. > > Thoughts? Security? Employee adds his DNS to pg_hba.conf, becomes disgruntled employee, moves to different IP and same name, and can still access your database? What about "DNS hijacking/forging"? I don't know how hard it is to do, but if one of the upstream network provides puts in a 'filter' for port 53 (DNS) and starts feeding you incorrect data, so that they can access your databases? Both are relatively extreme, and in both bases, the 'attacker' would have to have previous knowledge (ie. disgruntled ex employee) but DNS != trusted IP ... then again, it may be possible to hijack/forge the IP itself, in which case, there is no difference ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Sun, Jan 01, 2006 at 02:50:37PM -0400, Marc G. Fournier wrote: > Employee adds his DNS to pg_hba.conf, becomes disgruntled employee, moves > to different IP and same name, and can still access your database? I think it depends how you do the check. You can either do a forward lookup from the name and match that to the IP. Or you can do a reverse lookup on the IP to match the name. Or both. To work around either requires hijacking DNS but which servers varies. If you've got the entries in /etc/hosts that makes hijacking harder. I'm thinking something like tcpwrappers would be an example here. They have a paranoid mode where your reverse and forward have to match. Something to consider. For the user in referred to thread: SSH tunnelling. I wonder if there's a way we can make that easier to setup... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Marc G. Fournier wrote: > On Sun, 1 Jan 2006, Tom Lane wrote: > >> I was reminded of $subject by >> http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php >> >> While I haven't tried it, I suspect that allowing a DNS host name >> would take little work (basically removing the AI_NUMERICHOST flag >> passed to getaddrinfo in hba.c). There was once a good reason not >> to allow it: slow DNS lookups would lock up the postmaster. But >> now that we do this work in an already-forked backend, with an overall >> timeout that would catch any indefinite blockage, I don't see a good >> reason why we shouldn't let people use DNS names. >> >> Thoughts? > > > Security? I'd bet most pg_hba.conf entries will be (private) networks, not hosts. Since private networks defined in DNS are probably quite rare, only few people could benefit. Those who *do* define specific host entries, are probably quite security aware. They might find DNS safe for their purposes, but they'd probably like a function that shows the resulting hba entries after DNS resolution. Routers/firewalls that allow DNS names will usually resolve them immediately, and store the IP addresses. Regards, Andreas
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Sun, 1 Jan 2006, Tom Lane wrote:
>> ... I don't see a good
>> reason why we shouldn't let people use DNS names.
> Security?
Possibly, but if you're worried about that sort of attack you just don't
use DNS names in pg_hba.conf. Certainly it'd be worth putting a warning
in the manual about the risks of referring to DNS servers that aren't
directly under your control. But that doesn't seem like a reason not to
provide the feature for those who want it.
regards, tom lane
On Jan 1, 2006, at 2:02 PM, Martijn van Oosterhout wrote: > For the user in referred to thread: SSH tunnelling. I wonder if > there's > a way we can make that easier to setup... Making this easier and transparent would be nice, but I would still vote to allow DNS names in pg_hba.conf. SSH tunneling implies another level of software, user accounts, and permissions. It would be nice to handle the entire sphere of users and permissions from within PostgreSQL. For database access requirements, I would much rather allow DNS names in pg_hba.conf than provide SSH access. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL
Am Sonntag, 1. Januar 2006 19:30 schrieb Tom Lane: > I don't see a good > reason why we shouldn't let people use DNS names. I generally support this, but I wonder if this could have strange effects if a name resolves to more than one IP address or even an IPv4 and an IPv6 address.
Peter Eisentraut <peter_e@gmx.net> writes:
> Am Sonntag, 1. Januar 2006 19:30 schrieb Tom Lane:
>> I don't see a good
>> reason why we shouldn't let people use DNS names.
> I generally support this, but I wonder if this could have strange
> effects if a name resolves to more than one IP address or even an IPv4
> and an IPv6 address.
That's a good point: we'd have to be prepared to match the actual remote
IP address to more than one return value from getaddrinfo, so the change
wouldn't be a one-liner after all. It still seems like a pretty
localized change though.
regards, tom lane
Tom Lane wrote: >I was reminded of $subject by >http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php > >While I haven't tried it, I suspect that allowing a DNS host name >would take little work (basically removing the AI_NUMERICHOST flag >passed to getaddrinfo in hba.c). There was once a good reason not >to allow it: slow DNS lookups would lock up the postmaster. But >now that we do this work in an already-forked backend, with an overall >timeout that would catch any indefinite blockage, I don't see a good >reason why we shouldn't let people use DNS names. > >Thoughts? > > > > We debated this back in May 2003 - I was going to do it but it got lost among other stuff. Still worth doing, I think. cheers andrew
I also support this change. My clients have tended to move machines and networks around a lot as well as move databases from machine to machine. It would be nice to let the network gurus concentrate on getting the dns servers up and correct and leverage that work instead of having to change pg_hba.conf when these changes occur. elein elein@varlena.com On Sun, Jan 01, 2006 at 01:30:46PM -0500, Tom Lane wrote: > I was reminded of $subject by > http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php > > While I haven't tried it, I suspect that allowing a DNS host name > would take little work (basically removing the AI_NUMERICHOST flag > passed to getaddrinfo in hba.c). There was once a good reason not > to allow it: slow DNS lookups would lock up the postmaster. But > now that we do this work in an already-forked backend, with an overall > timeout that would catch any indefinite blockage, I don't see a good > reason why we shouldn't let people use DNS names. > > Thoughts? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match >
Yes, it would be good to implement this. A warning about security and (possible) slow connections due to name resolution issues should be placed in the docs. Regards paolo elein <elein@varlena.com> ha scritto > I also support this change. My clients have tended to move > machines and networks around a lot as well as move databases from machine > to machine. It would be nice to let the network gurus concentrate > on getting the dns servers up and correct and leverage that > work instead of having to change pg_hba.conf when these changes > occur. > > elein > elein@varlena.com > > On Sun, Jan 01, 2006 at 01:30:46PM -0500, Tom Lane wrote: > > I was reminded of $subject by > > http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php > > > > While I haven't tried it, I suspect that allowing a DNS host name > > would take little work (basically removing the AI_NUMERICHOST flag > > passed to getaddrinfo in hba.c). There was once a good reason not > > to allow it: slow DNS lookups would lock up the postmaster. But > > now that we do this work in an already-forked backend, with an overall > > timeout that would catch any indefinite blockage, I don't see a good > > reason why we shouldn't let people use DNS names. > > > > Thoughts? > > > > regards, tom lane > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 9: In versions below 8.0, the planner will ignore your desire to > > choose an index scan if your joining column's datatypes do not > > match > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq >
On Sun, 1 Jan 2006, Andreas Pflug wrote: >>> While I haven't tried it, I suspect that allowing a DNS host name >>> would take little work (basically removing the AI_NUMERICHOST flag >>> passed to getaddrinfo in hba.c). There was once a good reason not >>> to allow it: slow DNS lookups would lock up the postmaster. But >>> now that we do this work in an already-forked backend, with an overall >>> timeout that would catch any indefinite blockage, I don't see a good >>> reason why we shouldn't let people use DNS names. [snip] > > Routers/firewalls that allow DNS names will usually resolve them immediately, > and store the IP addresses. I think it's a great idea to make DNS names an option in pg_hba.conf. However, I think we're talking about two fairly different features here. (1) What Tom proposed is that we store the hostname and do a new DNS lookup for every connection. That could be useful in certain situations, but I wouldn't use it for a busy production server. The additional time for DNS lookups (even with a fast local caching nameserver) would not be a price I'd want to pay for the convenience. In a development environment, it could be just the ticket, though. (2) As Andreas mentioned, firewalls commonly do the DNS lookups when they read their configuration, and store the IP addresses. If we did this, you'd presumably only have to reload the postmaster configuration to cause the DNS lookups to be done again, but until then they'd be static and as fast as using actual IP addresses. If both were implemented, I'm not sure how you'd indicate which method you want on any given pg_hba.conf line. If we were only to have one of these, I'd prefer (2). You could always set up a cron job to reload the postmaster config hourly or daily, to keep the DNS lookups from getting too stale. Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/ Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ...
On 1/2/06, Jon Jensen <jon@endpoint.com> wrote: > On Sun, 1 Jan 2006, Andreas Pflug wrote: > > >>> While I haven't tried it, I suspect that allowing a DNS host name > >>> would take little work (basically removing the AI_NUMERICHOST flag > >>> passed to getaddrinfo in hba.c). There was once a good reason not > >>> to allow it: slow DNS lookups would lock up the postmaster. But > >>> now that we do this work in an already-forked backend, with an overall > >>> timeout that would catch any indefinite blockage, I don't see a good > >>> reason why we shouldn't let people use DNS names. > [snip] > > > > Routers/firewalls that allow DNS names will usually resolve them immediately, > > and store the IP addresses. > > I think it's a great idea to make DNS names an option in pg_hba.conf. > However, I think we're talking about two fairly different features here. > > (1) What Tom proposed is that we store the hostname and do a new DNS > lookup for every connection. That could be useful in certain situations, > but I wouldn't use it for a busy production server. The additional time > for DNS lookups (even with a fast local caching nameserver) would not be a > price I'd want to pay for the convenience. In a development environment, > it could be just the ticket, though. IMHO, this is the price you pay for using DNS. > > (2) As Andreas mentioned, firewalls commonly do the DNS lookups when they > read their configuration, and store the IP addresses. If we did this, > you'd presumably only have to reload the postmaster configuration to cause > the DNS lookups to be done again, but until then they'd be static and as > fast as using actual IP addresses. > > If both were implemented, I'm not sure how you'd indicate which method you > want on any given pg_hba.conf line. > > If we were only to have one of these, I'd prefer (2). You could always set > up a cron job to reload the postmaster config hourly or daily, to keep the > DNS lookups from getting too stale. If we're going to use an external facility, I'd vote for using it as a black box via the API it was designed with and not doing any caching tricks, especially if those tricks involve reloading the config file to make changes visible that would be seen if the facility were used "correctly". I guess I just see it as a "correct vs. fast" decision. If caching were to be used, expiry should be based on the TTL for the DNS record, and not a reload of our config. .... just my $0.02. > > Jon > > -- > Jon Jensen > End Point Corporation > http://www.endpoint.com/ > Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ... > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org
Jon Jensen <jon@endpoint.com> writes:
> (1) What Tom proposed is that we store the hostname and do a new DNS
> lookup for every connection. That could be useful in certain situations,
> but I wouldn't use it for a busy production server. The additional time
> for DNS lookups (even with a fast local caching nameserver) would not be a
> price I'd want to pay for the convenience.
Can you demonstrate that this is actually a serious concern next to the
total time spent launching a backend? I can't measure any real change
in total time for "psql -l" when log_hostname is enabled, which should
be a comparable hit.
I started out proposing a one-line change. The odds of this ever
getting done drop by an order of magnitude every time someone proposes
another order-of-magnitude increase in the work required...
regards, tom lane
On Mon, 2 Jan 2006, Tom Lane wrote: >> (1) What Tom proposed is that we store the hostname and do a new DNS >> lookup for every connection. That could be useful in certain situations, >> but I wouldn't use it for a busy production server. The additional time >> for DNS lookups (even with a fast local caching nameserver) would not be a >> price I'd want to pay for the convenience. > > Can you demonstrate that this is actually a serious concern next to the > total time spent launching a backend? I can't measure any real change > in total time for "psql -l" when log_hostname is enabled, which should > be a comparable hit. The difference is negligible when using a UNIX socket (of course) or names listed in /etc/hosts. But it's certainly slower in my tests if you really use DNS. On a run of 1000 connections doing "psql -l", it takes 18.89s without the DNS lookup for log_hostname, and 31.5s with. Or run as a one-off, it's 0.032 to 0.041s. Enough to make a difference on a busy server taking connections only over a local network. However, if I consider the likely use cases, this feature probably isn't important to such highly speed-sensitive servers anyway. And for those who want every last bit of speed possible, /etc/hosts still allows them to use this feature without a noticeable speed penalty. If the documentation mentions that DNS lookups are done for every request if you choose to use hostnames in pg_hba.conf, I think that's fair enough. > I started out proposing a one-line change. The odds of this ever > getting done drop by an order of magnitude every time someone proposes > another order-of-magnitude increase in the work required... It sounds like it's beyond a one-line change anyway, due to the possibility of multiple IP addresses coming back. But I agree that complicating this simple feature is overkill. The database is not a firewall, and doesn't have a firewall's speed due to connection overhead anyway. Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/ Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ...
Jon Jensen <jon@endpoint.com> writes:
> On Mon, 2 Jan 2006, Tom Lane wrote:
>> Can you demonstrate that this is actually a serious concern next to the
>> total time spent launching a backend? I can't measure any real change
>> in total time for "psql -l" when log_hostname is enabled, which should
>> be a comparable hit.
> The difference is negligible when using a UNIX socket (of course) or names
> listed in /etc/hosts. But it's certainly slower in my tests if you really
> use DNS. On a run of 1000 connections doing "psql -l", it takes 18.89s
> without the DNS lookup for log_hostname, and 31.5s with. Or run as a
> one-off, it's 0.032 to 0.041s.
Um --- I was testing a local-loopback connection, but now that I look at
the nsswitch.conf setup, it was going to /etc/hosts for that case.
Coming across the network so that a real DNS lookup is forced, there
seems to be a difference of about 4ms (note this is with a local DNS
daemon). I don't think that's significant. If it is, you've got other
performance problems anyway, and should switch to pooled connections to
reduce the number of backend launches.
regards, tom lane
On Sun, Jan 01, 2006 at 09:03:00PM +0100, Andreas Pflug wrote: > Marc G. Fournier wrote: > > >On Sun, 1 Jan 2006, Tom Lane wrote: > > > >>I was reminded of $subject by > >>http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php > >> > >>While I haven't tried it, I suspect that allowing a DNS host name > >>would take little work (basically removing the AI_NUMERICHOST flag > >>passed to getaddrinfo in hba.c). There was once a good reason not > >>to allow it: slow DNS lookups would lock up the postmaster. But > >>now that we do this work in an already-forked backend, with an overall > >>timeout that would catch any indefinite blockage, I don't see a good > >>reason why we shouldn't let people use DNS names. > >> > >>Thoughts? > > > > > >Security? > > > I'd bet most pg_hba.conf entries will be (private) networks, not hosts. > Since private networks defined in DNS are probably quite rare, only few > people could benefit. > > Those who *do* define specific host entries, are probably quite security > aware. They might find DNS safe for their purposes, but they'd probably > like a function that shows the resulting hba entries after DNS resolution. I don't know if the normal DNS libraries allow this, but it would be cool if you could specify that an entry in pg_hba.conf could be looked up from /etc/hosts, but not from generic DNS. AFAIK that would eliminate the possibility of spoofing. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
--- "Jim C. Nasby" <jnasby@pervasive.com> escreveu:
> I don't know if the normal DNS libraries allow this, but it would be
> cool if you could specify that an entry in pg_hba.conf could be
> looked
> up from /etc/hosts, but not from generic DNS. AFAIK that would
> eliminate
> the possibility of spoofing.
>
Take a look at 'man /etc/host.conf'.
Euler Taveira de Oliveira
euler[at]yahoo_com_br
_______________________________________________________
Yahoo! doce lar. Faça do Yahoo! sua homepage.
http://br.yahoo.com/homepageset.html
Euler Taveira de Oliveira wrote: >--- "Jim C. Nasby" <jnasby@pervasive.com> escreveu: > > > >>I don't know if the normal DNS libraries allow this, but it would be >>cool if you could specify that an entry in pg_hba.conf could be >>looked >>up from /etc/hosts, but not from generic DNS. AFAIK that would >>eliminate >>the possibility of spoofing. >> >> >> >Take a look at 'man /etc/host.conf'. > > > > That won't work for per application settings. I think this is a non starter. I have been thinking more about possible real world use cases for this facility. I suspect they will be comparatively rare. In cases where you don't trust DNS you shouldn't use it, and in cases where you do you probably know the address(es) anyway. If the change is simple it's worth doing, but it's not a huge leap. The biggest wrinkle will probably be handling names that map to multiple addresses. One thing that bothers me slightly is that we would need to look up each name (at least until we found a match) for each connection. If you had lots of names in your pg_hba.conf that could be quite a hit. We need to test this not with one but with a couple of hundred names, maybe, to see what the hit is like. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> One thing that bothers me slightly is that we would need to look up each
> name (at least until we found a match) for each connection. If you had
> lots of names in your pg_hba.conf that could be quite a hit.
A possible answer to that is to *not* look up the names from
pg_hba.conf, but instead restrict the feature to matching the
reverse-DNS name of the client. This limits the cost to one lookup per
connection instead of N (and it'd be essentially free if you have
log_hostnames turned on, since we already do that lookup in that case).
I'm not sure about the relative usefulness of this compared to the
forward-lookup case, nor whether it's riskier or less risky from a
spoofing point of view. But something to consider.
regards, tom lane
On Tue, Jan 03, 2006 at 12:43:03PM -0500, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > One thing that bothers me slightly is that we would need to look up each
> > name (at least until we found a match) for each connection. If you had
> > lots of names in your pg_hba.conf that could be quite a hit.
> A possible answer to that is to *not* look up the names from
> pg_hba.conf, but instead restrict the feature to matching the
> reverse-DNS name of the client. This limits the cost to one lookup per
> connection instead of N (and it'd be essentially free if you have
> log_hostnames turned on, since we already do that lookup in that case).
> I'm not sure about the relative usefulness of this compared to the
> forward-lookup case, nor whether it's riskier or less risky from a
> spoofing point of view. But something to consider.
I think it's riskier. I have my own PTR records, that I can make be
whatever I wish without any authority verifying that my actions are
proper. Although, most people don't, this is because most people don't
ask for them, or don't know how or where to ask for them. The security
benefit is in the address, not in the name. The convenience is in the
name, and not the address.
I'm not seeing why forward lookups are bad. There are several options
available to controlling this, including configuring /etc/hosts to be
searched first, before DNS, using nsswitch.conf. Another option, is
to use your own DNS server, with its own zone records, such that
/etc/resolv.conf uses 127.1, which will serve my own records, before
doing a recursive lookup over the network.
It's not a big deal. I'd recommend keeping documentation, and inlined
comment warnings all over the place - but if people want to use names,
I'm not seeing the problem. They can already hang themselves, by granting
full access to the Internet, by network mask? :-)
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness
bindthem...
http://mark.mielke.cc/
Tom Lane schrieb: > Andrew Dunstan <andrew@dunslane.net> writes: > >>One thing that bothers me slightly is that we would need to look up each >>name (at least until we found a match) for each connection. If you had >>lots of names in your pg_hba.conf that could be quite a hit. > > > A possible answer to that is to *not* look up the names from > pg_hba.conf, but instead restrict the feature to matching the > reverse-DNS name of the client. This limits the cost to one lookup per > connection instead of N (and it'd be essentially free if you have > log_hostnames turned on, since we already do that lookup in that case). Or alternatively (documented) scan and translate the names only on restart or sighup. This would limit the overhead and changes to the confile-scanner only and would at least enable symbolic names in the config files. (Of course w/o any wildcards - that would be the drawback)
mark@mark.mielke.cc writes:
> On Tue, Jan 03, 2006 at 12:43:03PM -0500, Tom Lane wrote:
>> I'm not sure about the relative usefulness of this compared to the
>> forward-lookup case, nor whether it's riskier or less risky from a
>> spoofing point of view. But something to consider.
> I think it's riskier. I have my own PTR records, that I can make be
> whatever I wish without any authority verifying that my actions are
> proper.
Yeah, that occurred to me after a few moments' thought. We could do one
extra forward lookup to confirm that the reverse-lookup name maps back
to the IP address.
> It's not a big deal.
Depends on how many names you want to put into pg_hba.conf. I don't
offhand see a use-case for very many, but maybe there is one. Even
if there are a lot, they'd not be expensive to look up if there is
a local nameserver that is authoritative for those names ... which
I'd think would be the normal case. The more "outside" names you've
got in pg_hba.conf, the more open you are to spoofing.
regards, tom lane
The issue is folks that DON'T set reverse DNS, I.E. have generic rDNS
set on their IP's.
I've seen (in my ISP days, and on my mailserver) LOTS of folks that
can't/won't update
Their rDNS, even though it's a STATICLY assigned address.
And, as an example, my house IP changes when the PPPoE moves, and I have
a DynDns.org
Hostname that changes to support that, as well as a CNAME out of my
domain to
Point to it.
Just more things to think about.
--
Larry Rosenman
Database Support Engineer
PERVASIVE SOFTWARE. INC.
12365B RIATA TRACE PKWY
3015
AUSTIN TX 78727-6531
Tel: 512.231.6173
Fax: 512.459.1309
Email: Larry.Rosenman@pervasive.com
Web: www.pervasive.com
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Tuesday, January 03, 2006 11:43 AM
To: Andrew Dunstan
Cc: Euler Taveira de Oliveira; Jim C. Nasby; Andreas Pflug; Marc G.
Fournier; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
Andrew Dunstan <andrew@dunslane.net> writes:
> One thing that bothers me slightly is that we would need to look up
each
> name (at least until we found a match) for each connection. If you had
> lots of names in your pg_hba.conf that could be quite a hit.
A possible answer to that is to *not* look up the names from
pg_hba.conf, but instead restrict the feature to matching the
reverse-DNS name of the client. This limits the cost to one lookup per
connection instead of N (and it'd be essentially free if you have
log_hostnames turned on, since we already do that lookup in that case).
I'm not sure about the relative usefulness of this compared to the
forward-lookup case, nor whether it's riskier or less risky from a
spoofing point of view. But something to consider.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's
datatypesdo not match
On Tue, 3 Jan 2006, Tino Wildenhain wrote: >>> One thing that bothers me slightly is that we would need to look up each >>> name (at least until we found a match) for each connection. If you had >>> lots of names in your pg_hba.conf that could be quite a hit. >> >> A possible answer to that is to *not* look up the names from >> pg_hba.conf, but instead restrict the feature to matching the >> reverse-DNS name of the client. This limits the cost to one lookup per >> connection instead of N (and it'd be essentially free if you have >> log_hostnames turned on, since we already do that lookup in that case). > > Or alternatively (documented) scan and translate the names > only on restart or sighup. This would limit the overhead > and changes to the confile-scanner only and would > at least enable symbolic names in the config files. > (Of course w/o any wildcards - that would be the drawback) That's what I suggested yesterday, but others didn't like it and the possibility of using /etc/hosts or a name server on the local network to mitigate speed concerns makes me think they're right. Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/
On Tue, Jan 03, 2006 at 12:08:46 -0600, Larry Rosenman <lrosenman@pervasive.com> wrote: > The issue is folks that DON'T set reverse DNS, I.E. have generic rDNS > set on their IP's. > > I've seen (in my ISP days, and on my mailserver) LOTS of folks that > can't/won't update > Their rDNS, even though it's a STATICLY assigned address. > > And, as an example, my house IP changes when the PPPoE moves, and I have > a DynDns.org > Hostname that changes to support that, as well as a CNAME out of my > domain to > Point to it. Business class (or Speakeasy) broadband connections will generally allow you to have custom PTR records for static IP addresses. When using broadband for sheep, the ssh tunnel idea is probably a better solution.
Bruno Wolff III wrote: > On Tue, Jan 03, 2006 at 12:08:46 -0600, > Larry Rosenman <lrosenman@pervasive.com> wrote: >> The issue is folks that DON'T set reverse DNS, I.E. have generic >> rDNS set on their IP's. >> >> I've seen (in my ISP days, and on my mailserver) LOTS of folks that >> can't/won't update Their rDNS, even though it's a STATICLY assigned >> address. >> >> And, as an example, my house IP changes when the PPPoE moves, and I >> have a DynDns.org Hostname that changes to support that, as well as >> a CNAME out of my domain to Point to it. > > Business class (or Speakeasy) broadband connections will generally > allow you to have custom PTR records for static IP addresses. When > using broadband for sheep, the ssh tunnel idea is probably a better > solution. > Understood. I was just pointing out the issue. I have had to whitelist some of my mortgage brokers e-mail servers because they hadn't gotten rid of the generic rDNS for their mailserver. I just wanted the issue to be in the archives when/if people don't like whatever gets committed/ -- Larry Rosenman Database Support Engineer PERVASIVE SOFTWARE. INC. 12365B RIATA TRACE PKWY 3015 AUSTIN TX 78727-6531 Tel: 512.231.6173 Fax: 512.459.1309 Email: Larry.Rosenman@pervasive.com Web: www.pervasive.com
Added to TODO:
o Allow pg_hba.conf to specify host names along with IP addresses
Host name lookup could occur when the postmaster reads the pg_hba.conf file, or when the backend
starts. Another solution would be to reverse lookup the connection IP and check that hostname against
thehost names in pg_hba.conf. We could also then check that the host name maps to the IP address.
---------------------------------------------------------------------------
Tom Lane wrote:
> mark@mark.mielke.cc writes:
> > On Tue, Jan 03, 2006 at 12:43:03PM -0500, Tom Lane wrote:
> >> I'm not sure about the relative usefulness of this compared to the
> >> forward-lookup case, nor whether it's riskier or less risky from a
> >> spoofing point of view. But something to consider.
>
> > I think it's riskier. I have my own PTR records, that I can make be
> > whatever I wish without any authority verifying that my actions are
> > proper.
>
> Yeah, that occurred to me after a few moments' thought. We could do one
> extra forward lookup to confirm that the reverse-lookup name maps back
> to the IP address.
>
> > It's not a big deal.
>
> Depends on how many names you want to put into pg_hba.conf. I don't
> offhand see a use-case for very many, but maybe there is one. Even
> if there are a lot, they'd not be expensive to look up if there is
> a local nameserver that is authoritative for those names ... which
> I'd think would be the normal case. The more "outside" names you've
> got in pg_hba.conf, the more open you are to spoofing.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
-- 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,
Pennsylvania19073
> > Added to TODO: > > o Allow pg_hba.conf to specify host names along with IP addresses > > Host name lookup could occur when the postmaster reads the > pg_hba.conf file, or when the backend starts. Another > solution would be to reverse lookup the connection IP and > check that hostname against the host names in pg_hba.conf. > We could also then check that the host name maps to the IP > address. I'm not so sure you need to be paranoid about it. The scenario is, at startup or HUP, names are looked up and stored as IP addresses. Then hba works as it is supposed too. "spoofing" is not really a problem, IMHO, because there should be a fire wall between PostgreSQL (most services really) and the raw internet, *and* the admin MUST have control over the authenticity of the name resolver. If someone is in the position to spoof name resolution, they are probably also in a position to spoof IP addresses. While I do see a need for this, but not in a sense that any old name would be used. I see it more like a data center wide "hosts" file use to dedicate various IP addresses to various services, i.e. freedb, streetmap, session, web0, web1, .., webn etc. What also may be handy in this scenario is that the names must fall within a range of acceptable addresses. Range: 192.168.245.1 ... 192.168.254.254 joey (192.168.254.55) -- OK joey (10.1.1.0) -- Not OK. This would be useful to declare a range of addresses as having some level of trust, and specific names within that range as having more (or less). In this scenario, think of a VPN, "joey" may be a laptop, and while he is on the VPN he is trusted, and when he is not on the vpn he is not trusted. This is especially important with regards to cyber security.
Mark Woodward wrote: >>Added to TODO: >> >> o Allow pg_hba.conf to specify host names along with IP addresses >> >> Host name lookup could occur when the postmaster reads the >> pg_hba.conf file, or when the backend starts. Another >> solution would be to reverse lookup the connection IP and >> check that hostname against the host names in pg_hba.conf. >> We could also then check that the host name maps to the IP >> address. >> >> > >I'm not so sure you need to be paranoid about it. The scenario is, at >startup or HUP, names are looked up and stored as IP addresses. Then hba >works as it is supposed too. > > If you do it like that you destroy the only real use case I can see for this that has much value, namely to handle cases where the address can change dynamically. >"spoofing" is not really a problem, IMHO, because there should be a fire >wall between PostgreSQL (most services really) and the raw internet, *and* >the admin MUST have control over the authenticity of the name resolver. If >someone is in the position to spoof name resolution, they are probably >also in a position to spoof IP addresses. > >While I do see a need for this, but not in a sense that any old name would >be used. I see it more like a data center wide "hosts" file use to >dedicate various IP addresses to various services, i.e. freedb, streetmap, >session, web0, web1, .., webn etc. > >What also may be handy in this scenario is that the names must fall within >a range of acceptable addresses. > >Range: 192.168.245.1 ... 192.168.254.254 > >joey (192.168.254.55) -- OK > >joey (10.1.1.0) -- Not OK. > >This would be useful to declare a range of addresses as having some level >of trust, and specific names within that range as having more (or less). > >In this scenario, think of a VPN, "joey" may be a laptop, and while he is >on the VPN he is trusted, and when he is not on the vpn he is not trusted. >This is especially important with regards to cyber security. > > > We have address ranges now; are you proposing to have those IN ADDITION to hostname parameters (as opposed to being an alternative)? We can over-egg this pudding massively. I suggest we start with a simple implementation and see what needs it leaves unfilled. I would vote for allowing a hostname (or list of hostnames?) to replace the address/mask params, and that at connect time we do a forward lookup trying for a match with the connecting address. If we get a match then that's the hba line that applies. Frankly, any auth mechanism based on the name or address of the client is insecure. If you have people connecting across possibly insecure networks you should use SSL with client certificates signed by your own CA, or a similar approach. cheers andrew
> Mark Woodward wrote: > >>>Added to TODO: >>> >>> o Allow pg_hba.conf to specify host names along with IP >>> addresses >>> >>> Host name lookup could occur when the postmaster reads the >>> pg_hba.conf file, or when the backend starts. Another >>> solution would be to reverse lookup the connection IP and >>> check that hostname against the host names in pg_hba.conf. >>> We could also then check that the host name maps to the IP >>> address. >>> >>> >> >>I'm not so sure you need to be paranoid about it. The scenario is, at >>startup or HUP, names are looked up and stored as IP addresses. Then hba >>works as it is supposed too. >> >> > > If you do it like that you destroy the only real use case I can see for > this that has much value, namely to handle cases where the address can > change dynamically. How "dynamically" are you talking about? If you are using a DNS server, what is your TTL on the records? A simple -HUP once every half hour is more than sufficient. If you are using ssh to update the hosts file, adding a simple -HUP tp the script is not a big deal. > >>"spoofing" is not really a problem, IMHO, because there should be a fire >>wall between PostgreSQL (most services really) and the raw internet, >> *and* >>the admin MUST have control over the authenticity of the name resolver. >> If >>someone is in the position to spoof name resolution, they are probably >>also in a position to spoof IP addresses. >> >>While I do see a need for this, but not in a sense that any old name >> would >>be used. I see it more like a data center wide "hosts" file use to >>dedicate various IP addresses to various services, i.e. freedb, >> streetmap, >>session, web0, web1, .., webn etc. >> >>What also may be handy in this scenario is that the names must fall >> within >>a range of acceptable addresses. >> >>Range: 192.168.245.1 ... 192.168.254.254 >> >>joey (192.168.254.55) -- OK >> >>joey (10.1.1.0) -- Not OK. >> >>This would be useful to declare a range of addresses as having some level >>of trust, and specific names within that range as having more (or less). >> >>In this scenario, think of a VPN, "joey" may be a laptop, and while he is >>on the VPN he is trusted, and when he is not on the vpn he is not >> trusted. >>This is especially important with regards to cyber security. >> >> >> > > We have address ranges now; are you proposing to have those IN ADDITION > to hostname parameters (as opposed to being an alternative)? > > We can over-egg this pudding massively. I suggest we start with a simple > implementation and see what needs it leaves unfilled. I would vote for > allowing a hostname (or list of hostnames?) to replace the address/mask > params, and that at connect time we do a forward lookup trying for a > match with the connecting address. If we get a match then that's the hba > line that applies. > > Frankly, any auth mechanism based on the name or address of the client > is insecure. If you have people connecting across possibly insecure > networks you should use SSL with client certificates signed by your own > CA, or a similar approach. It isn't so much an auth issue because I'm not assuming a "hacker" so much as the stream of data that across the network. Within the firewall == safe, outside of the firewall can be snooped.
Mark Woodward wrote: >>Mark Woodward wrote: >> >> >> >>>>Added to TODO: >>>> >>>> o Allow pg_hba.conf to specify host names along with IP >>>>addresses >>>> >>>> Host name lookup could occur when the postmaster reads the >>>> pg_hba.conf file, or when the backend starts. Another >>>> solution would be to reverse lookup the connection IP and >>>> check that hostname against the host names in pg_hba.conf. >>>> We could also then check that the host name maps to the IP >>>> address. >>>> >>>> >>>> >>>> >>>I'm not so sure you need to be paranoid about it. The scenario is, at >>>startup or HUP, names are looked up and stored as IP addresses. Then hba >>>works as it is supposed too. >>> >>> >>> >>> >>If you do it like that you destroy the only real use case I can see for >>this that has much value, namely to handle cases where the address can >>change dynamically. >> >> > >How "dynamically" are you talking about? > >If you are using a DNS server, what is your TTL on the records? A simple >-HUP once every half hour is more than sufficient. If you are using ssh to >update the hosts file, adding a simple -HUP tp the script is not a big >deal. > > > If I am a road warrior I want to be able to connect, run my dynamic dns client, and go. HUPing the postmaster every 30 minutes sounds horrible, and won't work for what strikes me as the scenario that needs this most. And we surely aren't going to build TTL logic into postgres. I repeat - let's do this the simple way. cheers andrew
On Mon, Feb 13, 2006 at 10:00:34AM -0500, Andrew Dunstan wrote:
> Mark Woodward wrote:
> >I'm not so sure you need to be paranoid about it. The scenario is, at
> >startup or HUP, names are looked up and stored as IP addresses. Then hba
> >works as it is supposed too.
> If you do it like that you destroy the only real use case I can see for
> this that has much value, namely to handle cases where the address can
> change dynamically.
*nod*
Addresses change, and for a stable PostgreSQL server, this would hopefully
mean that PostgreSQL has uptime across these changes. :-)
> We have address ranges now; are you proposing to have those IN ADDITION
> to hostname parameters (as opposed to being an alternative)?
I like in addition. For example, at work, saying "a.blah.com" and "47.*"
would give me an inch more of comfort, as the organization is large, and
there are numerous channels to having the name changed - but at least if
I know that the name is within 47.*, I know that it isn't somebody in
another partner company connecting directly from their network.
Not bullet proof, but slightly more difficult to manipulate.
> We can over-egg this pudding massively. I suggest we start with a simple
> implementation and see what needs it leaves unfilled. I would vote for
> allowing a hostname (or list of hostnames?) to replace the address/mask
> params, and that at connect time we do a forward lookup trying for a
> match with the connecting address. If we get a match then that's the hba
> line that applies.
Yes.
> Frankly, any auth mechanism based on the name or address of the client
> is insecure. If you have people connecting across possibly insecure
> networks you should use SSL with client certificates signed by your own
> CA, or a similar approach.
Yes.
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness
bindthem...
http://mark.mielke.cc/
mark@mark.mielke.cc writes:
> On Mon, Feb 13, 2006 at 10:00:34AM -0500, Andrew Dunstan wrote:
>> We can over-egg this pudding massively. I suggest we start with a simple
>> implementation and see what needs it leaves unfilled. I would vote for
>> allowing a hostname (or list of hostnames?) to replace the address/mask
>> params, and that at connect time we do a forward lookup trying for a
>> match with the connecting address. If we get a match then that's the hba
>> line that applies.
> Yes.
The original proposal to change this required little more than removing
the AI_NUMERICHOST flag restricting pg_getaddrinfo_all's lookup. I
thought all along that anything more than that was massive overdesign...
regards, tom lane
> > If I am a road warrior I want to be able to connect, run my dynamic dns > client, and go. > > HUPing the postmaster every 30 minutes sounds horrible, and won't work > for what strikes me as the scenario that needs this most. And we surely > aren't going to build TTL logic into postgres. > > I repeat - let's do this the simple way. While I would certainly agree with you on this one in most cases, DNS is a sticky and anoying system. Simple solutions typically fail to accomplish anything. Ask anyone who has implemented DNS based load balancing. And then, don't trust Windows to act accordingly to TTL values in host records. Maybe I'm not sure what you envision, but there are two options, a host file on the postgresql server, or a DNS server the that postgresql server interacts with. Your "dynamic dns" system may push a DNS entry up to some shared DNS server, but you still need to mind the whole TTL issue. I think what bothers me is that DNS is intended to be a directory for clients to implement an outward connection by finding an IP address that is routable. In your scenario of working as a road warrior, you are almost certainly not going to be able to have a workable DNS host name unless you have a raw internet IP address. More than likely you will have an IP address (known to your laptop) as a 192 or 10 address. If you set your address in some dynamic DNS system, your reported originating IP address (to PostgreSQL) will most likely be wrong. It will be the public IP address of your router that PostgreSQL will see. The more I think about it the uglier it is, I would say an SSH tunnel would be more secure and less problematic.
Mark Woodward wrote: >>If I am a road warrior I want to be able to connect, run my dynamic dns >>client, and go. >> >> >> >In your scenario of working as a road warrior, you are almost >certainly not going to be able to have a workable DNS host name unless you >have a raw internet IP address. More than likely you will have an IP >address (known to your laptop) as a 192 or 10 address. > Nonsense. There is a dynamic DNS client that is quite smart enough to find out and use the gateway address. See: http://ddclient.sourceforge.net/ I'm sure there are others, including some for Windows. cheers andrew
> Mark Woodward wrote: > >>>If I am a road warrior I want to be able to connect, run my dynamic dns >>>client, and go. >>> >>> >>> >>In your scenario of working as a road warrior, you are almost >>certainly not going to be able to have a workable DNS host name unless >> you >>have a raw internet IP address. More than likely you will have an IP >>address (known to your laptop) as a 192 or 10 address. >> > > > Nonsense. There is a dynamic DNS client that is quite smart enough to > find out and use the gateway address. See: > http://ddclient.sourceforge.net/ > > I'm sure there are others, including some for Windows. > But then, there is another problem, if you don't have a real and true IP address, if you are on anonymous 192 or 10 net (most likely the case), then your dynamic DNS entry allows EVERYONE on your network the same access. I still say an SSH tunnel with port forwarding is more secure, besides you can even compress the data stream.
Mark Woodward wrote: >>Mark Woodward wrote: >> >> >> >>>>If I am a road warrior I want to be able to connect, run my dynamic dns >>>>client, and go. >>>> >>>> >>>> >>>> >>>> >>>In your scenario of working as a road warrior, you are almost >>>certainly not going to be able to have a workable DNS host name unless >>>you >>>have a raw internet IP address. More than likely you will have an IP >>>address (known to your laptop) as a 192 or 10 address. >>> >>> >>> >>Nonsense. There is a dynamic DNS client that is quite smart enough to >>find out and use the gateway address. See: >>http://ddclient.sourceforge.net/ >> >>I'm sure there are others, including some for Windows. >> >> >> > >But then, there is another problem, if you don't have a real and true IP >address, if you are on anonymous 192 or 10 net (most likely the case), >then your dynamic DNS entry allows EVERYONE on your network the same >access. > >I still say an SSH tunnel with port forwarding is more secure, besides you >can even compress the data stream. > > > > And then you have to allow shell access. What's wrong with SSL with client certificates? Personally, I doubt there's any great use case for DNS names. Like Tom says, if it involves much more that removing the AI_NUMERICHOST hint then let's forget it. (I also agree with a point Jan sometimes makes - that end client s/w generally should not be talking to the db at all - that's what middleware is for. Then this whole discussion becomes moot.) cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Personally, I doubt there's any great use case for DNS names. Like Tom
> says, if it involves much more that removing the AI_NUMERICHOST hint
> then let's forget it.
Perhaps more to the point: let's do that and wait to see if the field
demand justifies expending lots of sweat on anything smarter. Given
that we've gone this long with only allowing numeric IPs in pg_hba.conf,
I suspect we'll find that few people really care.
regards, tom lane
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> Personally, I doubt there's any great use case for DNS names. Like Tom >> says, if it involves much more that removing the AI_NUMERICHOST hint >> then let's forget it. > > Perhaps more to the point: let's do that and wait to see if the field > demand justifies expending lots of sweat on anything smarter. Given > that we've gone this long with only allowing numeric IPs in pg_hba.conf, > I suspect we'll find that few people really care. Well as one of the people that deploys and managees many, many postgresql installations I can say I have never run into the need to have dns names and the thought of dns names honestly seems silly. It will increase overhead and dependencies that I just wouldn't want in my installations. Joshua D. Drake > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On 2/13/06, Joshua D. Drake <jd@commandprompt.com> wrote: > Well as one of the people that deploys and managees many, many > postgresql installations I can say I have never run into the need to > have dns names and the thought of dns names honestly seems silly. It > will increase overhead and dependencies that I just wouldn't want in my > installations. It is not uncommon for an environment that has already suffered through one forced renumbering to forbid the use of hard set IPs in application software. With IPv6 we will just see more and more of that.
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Tom Lane wrote:
>> Perhaps more to the point: let's do that and wait to see if the field
>> demand justifies expending lots of sweat on anything smarter. Given
>> that we've gone this long with only allowing numeric IPs in pg_hba.conf,
>> I suspect we'll find that few people really care.
> Well as one of the people that deploys and managees many, many
> postgresql installations I can say I have never run into the need to
> have dns names and the thought of dns names honestly seems silly. It
> will increase overhead and dependencies that I just wouldn't want in my
> installations.
If you don't want DNS names, you don't have to use 'em, so arguments of
this sort seem rather irrelevant to me. They would be relevant if we
were talking about expending any great amount of development manpower
... which is why I'd rather see us do something minimal first, and see
if it gets used much.
regards, tom lane