North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
> From: Adam McKenna [mailto:email@example.com] > 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.