RE: To CAIS Engineers - WAKE UP AND TAKE CARE OF YOUR CUSTOMERS
From: Adam McKenna [mailto:adam@flounder.net] Sent: Sunday, May 13, 2001 10:06 PM
Oracle (try and build a DB without reverse working right. Net8 stops you dead in your tracks).
Sorry, but this is just 100% wrong. I've set up Oracle on many boxes and you don't need any DNS at all to set up an oracle DB. In fact, I tell our DBA's to use IP addresses in their TNSNAMES.ORA files because I don't want the DB depending on DNS.
Let's see, I don't want to make my DBs dependent on DNS, so I use IP addrs. Yet, I can't depend on IP addrs because my upstream might have to be changed... damn, I shouldn't have depended on my scumbag DSL upstream, eh? Gee, maybe I should have had a names based system after all? Either way, I wind up having to rebuild Oracle boxen and application servers, every time somebody farts. Just what in blue hell are we supposed to do? BTW, the last I checked SSL certs are usually names based. Pretty slack security, eh? This is right on up there with: 1) You idiot DSL monkey, you deserve your Inet death because you didn't multi-home. 2) No, you can't advertise less than a /20. 3) No, you don't deserve larger than a /32. 4) Yes, we know that makes multi-homing impossible for those that need it the most. 5) No, we don't care, you idiot DSL monkeys deserve Inet death. Yeah, the message you send out is real clear. ... and one wonders why the Internet has an implosion problem... -- Internet implosion at 10:00 ... special web report, at 11:00.
On Mon, May 14, 2001 at 12:42:54AM -0700, Roeland Meyer wrote:
Oracle (try and build a DB without reverse working right. Net8 stops you dead in your tracks).
Sorry, but this is just 100% wrong. I've set up Oracle on many boxes and you don't need any DNS at all to set up an oracle DB. In fact, I tell our DBA's to use IP addresses in their TNSNAMES.ORA files because I don't want the DB depending on DNS.
Let's see, I don't want to make my DBs dependent on DNS, so I use IP addrs. Yet, I can't depend on IP addrs because my upstream might have to be changed... damn, I shouldn't have depended on my scumbag DSL upstream, eh?
I believe we've been through this discussion before.
Gee, maybe I should have had a names based system after all? Either way, I wind up having to rebuild Oracle boxen and application servers, every time somebody farts. Just what in blue hell are we supposed to do?
Maybe you should get a clue, or hire someone who has one.
BTW, the last I checked SSL certs are usually names based. Pretty slack security, eh?
Yes. See http://cr.yp.to/djbdns/bugtraq/19991114052453-12962-qmail@cr-yp-to and http://cr.yp.to/djbdns/forgery.html --Adam
On Mon, 14 May 2001, Roeland Meyer whimpered:
From: Adam McKenna [mailto:adam@flounder.net] Sent: Sunday, May 13, 2001 10:06 PM
Oracle (try and build a DB without reverse working right. Net8 stops you dead in your tracks).
Sorry, but this is just 100% wrong. I've set up Oracle on many boxes and you don't need any DNS at all to set up an oracle DB. In fact, I tell our DBA's to use IP addresses in their TNSNAMES.ORA files because I don't want the DB depending on DNS.
Let's see, I don't want to make my DBs dependent on DNS, so I use IP addrs. Yet, I can't depend on IP addrs because my upstream might have to be changed... damn, I shouldn't have depended on my scumbag DSL upstream, eh? Gee, maybe I should have had a names based system after all? Either way, I wind up having to rebuild Oracle boxen and application servers, every time somebody farts. Just what in blue hell are we supposed to do?
Um, lets see...how about this. You use NAT. That'll be $180.00 please. I'll send you an invoice.
BTW, the last I checked SSL certs are usually names based. Pretty slack security, eh?
Slack, no. You're comparing apples to oranges here and HOPEFULLY, you know it. Basing security on IN-ADDR is absolutely idiotic. It is VERY easy to spoof and there's not a damned thing you can do to stop the spoofing. Basing security on IP addresses on the other hand is while not a complete security solution, MUCH MORE SOUND than IN-ADDR. You can at least build ACLs in your router(s) that don't allow spoofed traffic to enter your network. Now, about the SSL security thing. SSL certification is designed to certify the identity of the server and that identity is based on the FQDN. SSL CERTs are around for the PRECISE reason that it is too easy to spoof IN-ADDR, etc.
This is right on up there with:
1) You idiot DSL monkey, you deserve your Inet death because you didn't multi-home. 2) No, you can't advertise less than a /20. 3) No, you don't deserve larger than a /32. 4) Yes, we know that makes multi-homing impossible for those that need it the most. 5) No, we don't care, you idiot DSL monkeys deserve Inet death.
Yeah, the message you send out is real clear. ... and one wonders why the Internet has an implosion problem...
And that's right up there with "<plonk!> me please! I'm an idiot DSL monkey! WAAAAAAAAAA! My DSL provider went tits-up and I hadn't built any contengency plan. I'm going to go bankrupt! WAAAAAAAAA!" You got caught with your pants down. It's that simple. You're not alone. A whole slew of folks went through (or are going through) the same thing. The difference is that the VAST MAJORITY of them are NOT bitching and moaning about it on NANOG about it. This is the NORTH AMERICAN NETWORK OPERATORS GROUP, *NOT* the "NORTH AMERICAN DISENFRANCHISED DSL CUSTOMERS GROUP." If your business depends (depended) on stable and reliable internet connectivity with your own (or at least non-changing) address space, might I suggest that you should have gone to ARIN for a microblock of address space and established a contengency plan with some other provider(s) in the event that the sky fell?
-- Internet implosion at 10:00 ... special web report, at 11:00.
--- John Fraizer EnterZone, Inc
Reverse DNS by itself is insufficient for authentication, but enforcing matching forward and reverse DNS entries is much more reliable (no substitute for secret-based or cert-based authentication, but a good "front door" for something like tcp wrappers). at last check, tcpd and sshd can both be configured to block connections without matching forward/reverse records. -C On Mon, May 14, 2001 at 12:42:54AM -0700, Roeland Meyer wrote:
From: Adam McKenna [mailto:adam@flounder.net] Sent: Sunday, May 13, 2001 10:06 PM
Oracle (try and build a DB without reverse working right. Net8 stops you dead in your tracks).
Sorry, but this is just 100% wrong. I've set up Oracle on many boxes and you don't need any DNS at all to set up an oracle DB. In fact, I tell our DBA's to use IP addresses in their TNSNAMES.ORA files because I don't want the DB depending on DNS.
Let's see, I don't want to make my DBs dependent on DNS, so I use IP addrs. Yet, I can't depend on IP addrs because my upstream might have to be changed... damn, I shouldn't have depended on my scumbag DSL upstream, eh? Gee, maybe I should have had a names based system after all? Either way, I wind up having to rebuild Oracle boxen and application servers, every time somebody farts. Just what in blue hell are we supposed to do?
BTW, the last I checked SSL certs are usually names based. Pretty slack security, eh?
This is right on up there with:
1) You idiot DSL monkey, you deserve your Inet death because you didn't multi-home. 2) No, you can't advertise less than a /20. 3) No, you don't deserve larger than a /32. 4) Yes, we know that makes multi-homing impossible for those that need it the most. 5) No, we don't care, you idiot DSL monkeys deserve Inet death.
Yeah, the message you send out is real clear. ... and one wonders why the Internet has an implosion problem...
-- Internet implosion at 10:00 ... special web report, at 11:00.
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
On Mon, May 14, 2001 at 11:46:05AM -0400, Christopher A. Woodfield wrote:
Reverse DNS by itself is insufficient for authentication, but enforcing matching forward and reverse DNS entries is much more reliable (no substitute for secret-based or cert-based authentication, but a good "front door" for something like tcp wrappers). at last check, tcpd and sshd can both be configured to block connections without matching forward/reverse records.
No. This is joke security, as is any security that relies on hostnames. TCP wrappers is basically worthless as a security measure unless you are using IP-based rules. And even then, it's deprecated in favor of kernel firewalling (In Linux) or ipfilter (on BSD's and other platforms that support it). --Adam
I didn't intend to imply that matching forward/reverse DNS was a security measure I'd trust by itself, but it certainly doesn't hurt to implement as a "outer perimeter" measure in conjunction with IP-based rules and secure authentication... -C On Mon, May 14, 2001 at 10:24:54AM -0700, Adam McKenna wrote:
On Mon, May 14, 2001 at 11:46:05AM -0400, Christopher A. Woodfield wrote:
Reverse DNS by itself is insufficient for authentication, but enforcing matching forward and reverse DNS entries is much more reliable (no substitute for secret-based or cert-based authentication, but a good "front door" for something like tcp wrappers). at last check, tcpd and sshd can both be configured to block connections without matching forward/reverse records.
No. This is joke security, as is any security that relies on hostnames. TCP wrappers is basically worthless as a security measure unless you are using IP-based rules. And even then, it's deprecated in favor of kernel firewalling (In Linux) or ipfilter (on BSD's and other platforms that support it).
--Adam
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
On Mon, May 14, 2001 at 05:27:09PM -0400, Christopher A. Woodfield wrote:
I didn't intend to imply that matching forward/reverse DNS was a security measure I'd trust by itself, but it certainly doesn't hurt to implement as a "outer perimeter" measure in conjunction with IP-based rules and secure authentication...
It does hurt. It causes non-obvious problems. Forcing hostnames and PTR's to match (commonly referred to as PARANOID checking) does not provide extra security, it just prevents people with badly configured DNS from accessing your servers. --Adam
On Mon, 14 May 2001 23:18:09 PDT, Adam McKenna <adam@flounder.net> said:
It does hurt. It causes non-obvious problems. Forcing hostnames and PTR's to match (commonly referred to as PARANOID checking) does not provide extra security, it just prevents people with badly configured DNS from accessing your servers.
I once did a similar check in a Sendmail configuration, and found it to be incredibly useful in reducing the spam load without significantly impacting actual traffic. There's a second-order effect here - the sort of clueless ISP that is unable to get a PTR entry correct is *ALSO* the sort of clueless ISP that is very likely unable to detect/eliminate hacker/spammer/etc nests in their address space. You of course need to be sure that your *own* DNS is rock-solid and up to date (although our departmental network liaisons that maintain their zones have learned that Things Will Not Work if they don't do it right ;). You also need to apply the usual skepticism for results - there *could* be a temporary outage, for instance. It's *NOT* a security measure to deploy by itself. It's however useful as Yet Another Part of a Complete and Balanced Security Breakfast... ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
--- Valdis.Kletnieks@vt.edu wrote:
On Mon, 14 May 2001 23:18:09 PDT, Adam McKenna <adam@flounder.net> said:
It does hurt. It causes non-obvious problems. Forcing hostnames and PTR's to match (commonly referred to as PARANOID checking) does not provide extra security, it just prevents people with badly configured DNS from accessing your servers.
I once did a similar check in a Sendmail configuration, and found it to be incredibly useful in reducing the spam load without significantly impacting actual traffic.
There's a second-order effect here - the sort of clueless ISP that is unable to get a PTR entry correct is *ALSO* the sort of clueless ISP that is very likely unable to detect/eliminate hacker/spammer/etc nests in their address space.
You of course need to be sure that your *own* DNS is rock-solid and up to date (although our departmental network liaisons that maintain their zones have learned that Things Will Not Work if they don't do it right ;). You also need to apply the usual skepticism for results - there *could* be a temporary outage, for instance.
Forcing hostnames and PTR's to match will also prevent people from NAT land accessing your servers. There are hardly any NAT implementations that do dynamic DNS updates.
It's *NOT* a security measure to deploy by itself. It's however useful as Yet Another Part of a Complete and Balanced Security Breakfast... ;)
Only if you consider keeping up-to-date PTR records and dynamic DNS updates a security measure.
-- Valdis Kletnieks Operating Systems Analyst Virginia Tech
cheers, suresh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Pyda Srisuresh Sent: May 15, 2001 12:03 PM To: Valdis.Kletnieks@vt.edu; Adam McKenna Cc: nanog@nanog.org Subject: Re: To CAIS Engineers - WAKE UP AND TAKE CARE OF YOUR CUSTOMERS
Forcing hostnames and PTR's to match will also prevent people from NAT land accessing your servers. There are hardly any NAT implementations that do dynamic DNS updates.
Your NAT implementation must not be the same as the ones I've worked with, because with the [simple] ones I've seen, you have something like 192.168.0.0/24 all coming out and talking to the world as 1.2.3.4 (the more elaborate implementations give each private IP a unique outside IP, in which case you just set up your DNS for each IP. A little more work, perhaps, but...). Now, if 1.2.3.4 has proper matching forward/reverse DNS lookups, I don't see how people behind someone else's NAT pose a problem. Vivien -- Vivien M. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
On Tue, May 15, 2001 at 12:52:00PM -0400, Vivien M. wrote:
but...). Now, if 1.2.3.4 has proper matching forward/reverse DNS lookups, I don't see how people behind someone else's NAT pose a problem.
Remember, we're talking about matching hostnames to reverse lookups. Assuming you're using NAPT (a specific subset of NAT that seems to be what we're talking about here), this won't match up unless all your boxes have the same hostname.
but...). Now, if 1.2.3.4 has proper matching forward/reverse DNS lookups,= I don't see how people behind someone else's NAT pose a problem.
Remember, we're talking about matching hostnames to reverse lookups.
My understanding is that we are talking about: (a) Doing a reverse lookup on the IP address, and getting a name. (b) Doing a forward lookup on that name, and making sure you get the right IP address back. That works fine with or without NAT. The hostname that is configured on the actual workstation is irrelevant. (And is also unknwon (to the target of the connection) for many protocols.) -- Brett
On Tue, May 15, 2001 at 02:09:30PM -0500, Brett Frankenberger wrote:
My understanding is that we are talking about:
(a) Doing a reverse lookup on the IP address, and getting a name. (b) Doing a forward lookup on that name, and making sure you get the right IP address back.
No, not the security part of the thread, the mail filter part of the thread. Sorry, should have specified.
Shawn McMahon wrote:
On Tue, May 15, 2001 at 02:09:30PM -0500, Brett Frankenberger wrote:
My understanding is that we are talking about:
(a) Doing a reverse lookup on the IP address, and getting a name. (b) Doing a forward lookup on that name, and making sure you get the right IP address back.
No, not the security part of the thread, the mail filter part of the thread. Sorry, should have specified.
... unless the person running the mail server configures it to use the publicly-visible hostname instead of deriving a hostname from OS information. That's how I have my sendmail.cf file configured at home. It doesn't seem to have any problems. Of course, mail server distributions don't come preconfigured this way, so it will still cause problems for those who are unable/unwilling to hack their sendmail.cf file. -- David
--- "Vivien M." <vivienm@dyndns.org> wrote:
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Pyda Srisuresh Sent: May 15, 2001 12:03 PM To: Valdis.Kletnieks@vt.edu; Adam McKenna Cc: nanog@nanog.org Subject: Re: To CAIS Engineers - WAKE UP AND TAKE CARE OF YOUR CUSTOMERS
Forcing hostnames and PTR's to match will also prevent people from NAT land accessing your servers. There are hardly any NAT implementations that do dynamic DNS updates.
Your NAT implementation must not be the same as the ones I've worked with, because with the [simple] ones I've seen, you have something like 192.168.0.0/24 all coming out and talking to the world as 1.2.3.4 (the more elaborate implementations give each private IP a unique outside IP, in which case you just set up your DNS for each IP. A little more work, perhaps, but...). Now, if 1.2.3.4 has proper matching forward/reverse DNS lookups, I don't see how people behind someone else's NAT pose a problem.
Sure, not in the case of NAPT (assuming you have a PTR record set for 1.2.3.4). My point is merely that there may be many cases it is not so straight forward to do the DNS updates for PTR records.
Vivien -- Vivien M. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
cheers, suresh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Valdis.Kletnieks@vt.edu wrote:
I once did a similar check in a Sendmail configuration, and found it to be incredibly useful in reducing the spam load without significantly impacting actual traffic.
There's a second-order effect here - the sort of clueless ISP that is unable to get a PTR entry correct is *ALSO* the sort of clueless ISP that is very likely unable to detect/eliminate hacker/spammer/etc nests in their address space.
The problem with this approach is that it assumes a bunch of other stuff. In particular, it assumes that the ISP even delegates control over the IN-ADDR space to the end-user (while many here have stated they do not). It also assumes that the ISP will make/maintain the pointers locally if they do not delegate. It also assumes that the root servers are working. A couple of weeks ago, a.root-servers.net was periodically returning SERVFAIL on lookups for my ISP's address block, rather than returning referrals, so no reverse lookups ever got to their servers, and so never got to mine either. While this isn't a failure mode that is common, that's exactly the problem, somebody else' unexpected failure prevents it from being an accurate measure of a particular admin's clueness. Finally, it also assumes that the destination mail server and/or its resolver is capable of dealing with CNAME (when CIDR delegation is in use) or multiple PTR records (when a box belongs to multiple domains) associated with an IN-ADDR entry. This is by no means guaranteed. In short, filtering mail based on PTR matches is unpredictable and unenforceable. You might as well use a random number generator. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
participants (11)
-
Adam McKenna -
Brett Frankenberger -
Christopher A. Woodfield -
David Charlap -
Eric A. Hall -
John Fraizer -
Pyda Srisuresh -
Roeland Meyer -
Shawn McMahon -
Valdis.Kletnieks＠vt.edu -
Vivien M.