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...

> > 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?

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

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

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

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... :wink:

> 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... :wink:

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

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

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.

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.

> 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