25

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 ?

Improve this question
14
  • 50
    I'm of the camp that believes that completely random host names won't hinder an attacker much if at all and will cause more problems (for users and administrators alike) than a predictable host name convention. Also see security.stackexchange.com/q/178328/77995 and RFC 1178
    – HBruijn
    Jul 4, 2019 at 18:35
  • 32
    So you want to use random names as a means of obscurity ?
    – Hagen von Eitzen
    Jul 5, 2019 at 6:20
  • 24
    There's a whole class of bogus hardening recommendations like this, that make life harder for hackers, but make life harder for legitimate users by exactly the same amount. They don't make the system more secure, they just make it worse.
    – James_pic
    Jul 5, 2019 at 12:19
  • 8
    The cost of time wasted by legitimate users will immediately* outweight the security this idea provides... Security is a trade off. Random hostnames are an extremely bad tradeoff.
    – Giacomo Alzetta
    Jul 5, 2019 at 12:27
  • 17
    @James_pic Agree it's a bogus recommendation, but unfortunately, "make life harder" is not "by exactly the same amount"... A hacker will barely be inconvenienced (they'll just attack whatever is there, if/when they try to attack) whereas users will be daily having to remember whether the database was on \\NOTHING_TO_SEE_HERE_001 or \\NOTHING_TO_SEE_HERE_017
    – TripeHound
    Jul 5, 2019 at 13:03

3 Answers 3

Reset to default
81

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

Improve this answer
8
  • 25
    "An attacker will need to spend (significant) more effort" Are you sure about this? On most networks, I could probably figure out what most of the important servers do pretty quickly with wireshark or similar and I'm not a trained hacker (white hat or otherwise) at all. Domain controllers can always be found with nslookup. DHCP servers can be found by simply connecting to the network... and they'll happily give you a list of the DNS servers (along with other useful information) as a bonus. Agreed with the overall conclusion of your answer, though.
    – reirab
    Jul 5, 2019 at 5:55
  • 10
    @reirab - "An attacker will need to spend (significant) more effort" is the most common argument people seem to have against using logical, descriptive and predictable host names for servers and services. Effort is maybe not the best word, a portscan is not a lot of work, but is much more likely to trigger an alert than probing only the specific ports 1521 (Oracle listener) 3306 (MySQL) and 1433 (SQL server) on a host named db1.prod.int.example.com.(and thanks for the correction)
    – HBruijn
    Jul 5, 2019 at 6:56
  • 1
    You may also want to point out the pets-vs-cattle distinction (in short: When you have a large number of machines, administering each one individually becomes prohibitively time-consuming, so their names change from e.g. mail.example.com to abc123.example.com and then you schedule jobs onto them dynamically using something like Kubernetes. This has little to no security benefit, since abc124.example.com probably also exists, but it's a rather different way of doing things since the numbers and letters indicate physical location and not role.).
    – Kevin
    Jul 5, 2019 at 21:19
  • 1
    @alephzero: Cattle live in racks. If your "cattle" are under people's desks, and end users are individually configuring them, then they're not cattle, and you shouldn't manage them as such.
    – Kevin
    Jul 6, 2019 at 16:53
  • 1
    @jpmc26 : Hence the classification of a "low impact" risk with the rationale "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 [as a potential target] )." _-_Based on port scan you may find a database server, the hostname may instruct you it is a development instance (in theory without any real data, but frequently also with less security and the same data model) as opposed to a production database system (with more valuable data) where, when you are time constraint, you select to focus.
    – HBruijn
    Jul 7, 2019 at 9:17
19

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.

Improve this answer
7
  • 1
    a good example of a scheme that was obvious to those in the know yet hard to guess for the uninitiated I found at a former employer. All our servers were named after Nobel prize laureates, with different categories of servers taking names from different prizes (say (and this is just an example, don't remember what was actually in use) web servers got literature, database servers physics, application servers medicine). Much easier to remember to connect to Einstein than srv-12422A43D4327B
    – jwenting
    Jul 5, 2019 at 3:45
  • You can also do both - use some kind of themed name as the host name and then CNAME roles to it. Most of the servers to my university were set up that way when I was in undergrad. It was quite convenient in an environment where roles sometimes moved around between different servers. So, when a role changed, all we had to do was change the CNAME to point to the new server in charge of that role rather than needing to tell all of the clients to start connecting to a different hostname. Also, users neither had to know or care whether or not, say, mail.<domain> was the same box as www.<domain>.
    – reirab
    Jul 5, 2019 at 6:01
  • More often than I am happy with, I observe that www.companyname.com has a lot more ports open (and often interesting ones) than just 80 and 443. So if you conclude that it is "probably not the back end database" - this is actually a case of a slightly confusing-the-attacker hostname :)
    – Hagen von Eitzen
    Jul 5, 2019 at 6:26
  • 1
    My scheme is to use names of birds, like heron, egret, swan, magpie etc. The category of bird defines what type of device it is.
    – Tim
    Jul 5, 2019 at 10:17
  • 6
    "The fact that there is no readily available information to support your conclusion, should give you some idea about its validity." This. +1
    – dr_
    Jul 5, 2019 at 10:39
15

What you're advocating for is called "security though obscurity". While in theory obscurity does provide some extra protection while not making things worse, it usually does make things worse in practice. It (1) adds complexity to the system which leads to errors, (2) dilutes the understanding of what information is secret and what isn't, and (3) may have a non-trivial maintenance cost.

An example of (1) would be an admin applying low security settings to a highly sensitive server because the fact it was sensitive wasn't obvious from the name.

An example of (2) would be a user which is asked by IT to disclose the server name which they think is secret. Later, when they are asked by an attacker pretending to be IT to disclose their password, they will be less surprised and less suspicious.

An example of (3) would be the fact that in order to maintain obscure server names, IT will have to change them every time they suspect their network was compromised.

Improve this answer
1
  • 2
    "... security though obscurity ... (2) dilutes the understanding of what information is secret and what isn't ..." - That's a problem with security through obscurity that I've always felt in a way but never been able to articulate. Thanks!
    – marcelm
    Jul 6, 2019 at 14:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .