North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Security practices

  • From: Roeland Meyer
  • Date: Tue May 15 12:46:17 2001

> From: Adam McKenna [mailto:[email protected]]
> Sent: Monday, May 14, 2001 11:18 PM
> 
> 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.

IOW, it lets lazy/incompetent ISPs and SysAdms get away with not being
thourough. Actually, basic security isn't that bad, if you tighten up the
ship such that, you are doing what you are supposed to be doing
...exactly... and no more. Cut out the slop and most things work better,
with fewer holes. This is on the principle that memcpy, strcmp, and strcpy
are the biggest (only?) security holes on the net (and why open-source is
the only acceptable source of security related code).

Reverse checks work if you run your own zone servers and control your own
in-addr.arpa entries and they are all on the same LAN/net-block. Clone a
[RFC 2870] root zone server into this and you are almost spoof proof. When
accessing your own hosts, you shouldn't be going outside your LAN for any
authentication or host reference data (the single reason spoofs work at all)
nor should your packets leave your LAN.