I've been doing a security audit and found out you can easily identify host roles and running services just by their computer name (using nslookup).

I would like to report this so that they use less obvious computer names and it becomes harder for an attacker to identify machine roles on the network. I would like to give some weight to this proposal by linking to some security naming convention from a trusted organisation. After some search, I've been unable to find some. Is there any existing ?

The fact that there is no readily available information to support your conclusion, should give you some idea about its validity.

The point is, that if your attacker is already in, he will need to do some additional foot-printing anyway. Your host name may be database.xyz.intranet, but if the nmap gives you 1521 (oracle), 1433 (sql server) or 5432(Postgress), that gives some information about possible vulnerabilities.. Sure, it will save some time knowing that www.companyname.com is probably not the back end database server, but that is minimal.

On the other hand: are your developers really happy to do SQL-queries on linux20195681.intranet? What is they fire-up a second database in your on-premises cloud? Giving some meaningful names simplifies their life too. And of course it easier for the stand-by that is called at 2 a.m.

Also, your real servers may be hidden behind a load-balancer. The VIP would then typically get the functional name and the hosts behind it some sequence number.

If you are in a small organization, you could consider giving your hosts themed names (e.g. my Pi's at home are called pi, rho, sigma, phi, etc.), but even then, I struggle to remember that sigma is my home-automation, psi my DNS server etc. And yes, you might theme Zeus as the production database, Jupiter as test and Odin as develop, but at some point, any form of polytheism will put a limit on the number of servers.

So it really is better to give them functional names.

On the other hand: don't be to specific or alluring. Calling a host privatekeybackup.intranet will surely attract a bit more attention.

There have been some ideas of randomizing host names (rfc8117) but that seems more an issue for clients.

You have identified only one risk, that of an attacker identifying machine roles on the network by using predictable host names.

I think you missed the competing risk, that of increased operator error by not using predictable and descriptive host names.

This is how I would asses those conflicting measures:

Use unpredictable host names

Benefit(s)

An attacker will need to spend (significant) more effort in determining the layout of your network and to identify the most profitable targets for a penetration attempt.

Risks

Operator error. Users and administrators may have difficulty identifying systems and their correct roles e.g. confusing test and production systems.

• Probability: high
  


• Impact: high

Rationale: Most humans have terrible memories where "random" data is concerned --> high probability.

Also there are usually very few barriers that prevent trusted users and administrators from making high impact mistakes --> high impact.

Use predictable host names

Benefit(s)

Reduced operator error rates, ease of management and automation.

Risks

Attackers will also have an easier time determining the layout of your network and to identify the most profitable targets for a penetration attempt.

• Probability: medium
  


• Impact: low

Rationale: Not every naming convention is immediately intuitive to a black-hat attacker --> medium probability.

Also using hostnames to predict a network layout is only a shortcut, but doesn't provide information that an attacker wouldn't be able to learn through other means. And knowledge of the role of a server as disclosed by a hostname does not automatically make it more vulnerable (only more or less valuable). --> low impact.