> (i.e., if somebody who looks like a repair tech shows up at your
> receptionist's desk and says "I'm here to work on <some internal
> machine name> and it's an emergency; they're waiting for me in the
> machine room", what's your receptionist going to do?
[your examples of why to protect hostnames are very good. I guess I
would just want to point out that even with no hostnames, you are
still at risk from similar attacks]
Well, I realize that the "right" answer is not always the "practical"
or "realistic" answer but IMHO the receptionist better call in first...
or else.
First, because the repair tech will not be able to get through the
security stops within the building without an escort and secondly
because they will not be able to get into the machine room without
the presence of a staff member.
If physical security is any more lax then hostnames are not going to
save you once the intruder gets physical access to one machine. At
one company where I consult, you do not get in without an employee
accompanying you. Period. Unless you are the fire department and
in that case security is already on the scene.
Furthermore, how many receptionists really know the names and locations
of all computers in the company? If they really do know the names
and locations, does the gateway hostname change internally? If not,
then the intruder can just use the gateway hostname to get in.
> # It helps to prevent spoofing of the nameserver by people forging PTR records
> # in their nameservers. Thus I think that a "double reverse" name lookup is
> # under normal usage [with or without firewall] going to help cut down on
> # "forgeries" more than hiding only the names is going to help.
>
> I don't think knowing the name that goes with an IP address really
> tells you any more than the IP address itself, which you've got regardless.
Well, when tracking things down _after_ the fact, you are correct.
But for screening I disagree. Many sites are now using FQDN's for
configuration purposes to help prevent problems when machines are
changed [e.g. contact SMTP.do.main or NNTP.do.main]. Without verifying
the PTR lookup with a further A lookup, the PTR lookup can take place
on a remote [cracked] system and return a valid FQDN, that will not
be detected until much later.
Aydin Edguer
|
|
