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 ?

Luc
  • 31,973
  • 8
  • 71
  • 135
Xavier59
  • 2,874
  • 3
  • 17
  • 34
  • 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 https://security.stackexchange.com/q/178328/77995 and [RFC 1178](https://tools.ietf.org/html/rfc1178) – HBruijn Jul 04 '19 at 18:35
  • @HBruijn I agree that having random host names could mislead sysadmin but as a security consultant, I think it's our job to give my clients as much insight on security as possible while it's their job to decide wether or not they want to make the change based on the cost of being hacked vs the cost of the trouble caused to the sysadmins. – Xavier59 Jul 04 '19 at 18:56
  • @Xavier59 I'm also a security consultant. Yes, we should help clients understand the risks, but I'm undecided about this one (I was waiting for answers, I like the question). It definitely helps me to exploit their systems when I can see descriptive hostnames, or even just a predictable number (so I can increment it and see if that system exists), but it also helps the sysadmins. I'm not sure it helps me *so much* that I would recommend to disable it at all times. But then again, the sysadmins could also easily use tools/documentation to map a MAC/IP to a description. So I'm not sure. – Luc Jul 04 '19 at 19:16
  • 32
    So you want to use random names as a means of *obscurity* ? – Hagen von Eitzen Jul 05 '19 at 06: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 05 '19 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 05 '19 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 05 '19 at 13:03
  • @Xavier59 I would much rather my security group go beyond stating merely the level of threat and provide context and recommendations within that context. – John Spiegel Jul 05 '19 at 17:20
  • Where are you performing the audit? Internal to the network, or external? I could not find a Mitre CWE covering the information disclosure, but also see [Apache Tomcat Hostname Information Disclosure Vulnerability](https://tools.cisco.com/security/center/viewAlert.x?alertId=20381) and friends. –  Jul 06 '19 at 04:41
  • 1
    If you force machines to use random names, I'll bet the people in the organization will be poorly reinventing DNS because the system will be totally unusable without. – Lie Ryan Jul 06 '19 at 05:07
  • 3
    Not a security expert at all, but I would bet that having legitimate users get confused about the role of each server is a far greater *security* risk than having an attacker know the server roles before they begin their attack, never mind whether it's costly or inconvenient. It just sounds like it would be really easy to create security holes by mixing up servers (say accidentally installing a key on the wrong server, the forgetting to remove it when you realise). – Ben Jul 06 '19 at 08:42
  • 1
    Oh goodness, that explains a network I once saw which was an awful mess. I assume they also had a "security consultant" who came up with that idea. I assume the first bullet point on these kinds of lists is "Make sure servers are not plugged in" - sure it might make doing actual work a bit of a challenge, but just imagine the security benefits if no hardware is actually working! – Voo Jul 06 '19 at 18:49
  • @HBruijn I love how some of the suggestions in that RFC include using serial killer names. "Yes, here we have our noris host acting as failover for our bittaker host. Backups, of course, are kept on chikatilo." – forest Jul 07 '19 at 02:17
  • 2
    @TripeHound Not to mention that the most likely outcome of a random naming scheme is someone dropping the names and descriptions into a table on a Confluence page, thereby exposing this info to an authorized cloud service. – jpmc26 Jul 07 '19 at 08:11

3 Answers3

82

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.

reirab
  • 2,683
  • 1
  • 13
  • 21
HBruijn
  • 1,345
  • 10
  • 12
  • 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 05 '19 at 05: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 05 '19 at 06: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 05 '19 at 21:19
  • In support of this excellent answer, I would point out that [half of all breaches are due to negligence, not hackers](https://www.hcinnovationgroup.com/cybersecurity/news/13030905/study-internal-negligence-not-hackers-responsible-for-half-of-data-breaches). I doubt obscure server names would be an improvement. – John Wu Jul 06 '19 at 09:15
  • @Kevin names indicating physical location can turn into a chaos in an organization where work groups are regularly redeployed and people tend to take their personal tools with them. My employers overlooked that fact, and after a couple of years a desktop box with a name like th3b19 which originally identified a building, floor number, office, and cubicle number might be literally *anywhere* in half a dozen multi-storey office blocks. – alephzero Jul 06 '19 at 16:31
  • 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 06 '19 at 16:53
  • "You have identified only one risk, that of an attacker identifying machine roles on the network by using predictable host names." It's not clear to me why this is even really a risk. An attacker cannot do any damage with *only* this information. It requires the ability to *access* those machines somehow. Isn't it better then to identify the possible means by which an attack could *actually launch an attack* and focus on protecting against *those* rather than simply trying to obscure the machine's purpose? – jpmc26 Jul 07 '19 at 08:05
  • 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 07 '19 at 09: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.

Ljm Dullaart
  • 1,897
  • 4
  • 11
  • 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 05 '19 at 03: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. was the same box as www.. – reirab Jul 05 '19 at 06: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 05 '19 at 06:26
  • @reirab Such a scheme is fine - but no help in the threat model in question, I suppose. An attacker looking for a mail vulnerability could look for mail. and couldn't care less if the "real" name was ganymed or chtulhu – Hagen von Eitzen Jul 05 '19 at 06:30
  • @HagenvonEitzen Agreed. But I am of the same opinion as the two answers that the concern isn't really a valid one in the first place. :) What I described isn't really for security, but rather for making IT's life easier (I just mentioned it since the answer mentioned having difficulty remembering which Pi did what.) – reirab Jul 05 '19 at 06:35
  • 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 05 '19 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 05 '19 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.

Dmitry Grigoryev
  • 10,072
  • 1
  • 26
  • 56
  • 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 06 '19 at 14:56