My project leader sent this to me this morning, good for a Monday morning haha.
QuoteHere are computer naming schemes that we've seen in real life, or maybe that we think would be good ideas. Most are people, places or things, but there are others. See also TipsForNamingComputers (http://c2.com/cgi/wiki?TipsForNamingComputers).
Names Given To Computers
http://c2.com/cgi/wiki?NamesGivenToComputers
Man, if I had a nickel for every org. I've worked for that had "GANDALF (http://c2.com/cgi/wiki?NamesGivenToComputers)" as a server name...
I see a lot of WUMPUS, which I think was from Xork?
Quote from: Mr. Analog on September 24, 2007, 10:19:30 AM
I see a lot of WUMPUS, which I think was from Xork?
You are thinking of a "Grue" (as in "Turn on a light or you will be eaten by a...")
http://en.wikipedia.org/wiki/Hunt_the_Wumpus <-- I remember programming this game once!, after reading a description and sample source code in "MORE BASIC Computer Games", yes I actually had that book! (Their code for "The Game of Life" was pretty neat, I learned a lot from it IIRC)
see also more "early I.F. history" here (http://www.thedoteaters.com/p4_stage1.php) and here (http://wurb.com/if/game/442) , and playable version here (http://www.ifiction.org/games/play.phpz?cat=&game=249&mode=html) :)
I lol'ed at this:
QuoteMoomin characters [...] snufkin
Heck yeah! Snufkin! :D
I like how nicknames for PCs give a bit of personality to the history of computer ownershp. Instead of going on about specs I can say "After the GorgonBox died I created Oberon from spare parts. Later I upgraded and moved the kept components into New Oberon. When New Oberon started to blink in and out of existence I knew it was time to move on. Later I purchased and built Puck from the base up. I was unlucky and Puck acted up with a bad motherboard."
Makes for a better story than going from PII to Core2 with the tech specs.
You are correct sir!
Quote from: Mr. Analog on September 24, 2007, 01:29:16 PM
You are correct sir!
lol: "It is pitch black. You are likely to be eaten by a grue." (http://en.wikipedia.org/wiki/Grue_%28monster%29) vs. "Grue (Pitch Black), predatory creatures featured in the movie Pitch Black" (http://en.wikipedia.org/wiki/Grue) geez Vin and Co. you were WARNED by Jack Vance DECADES ago! ;)
I like my naming scheme:
* Natasha
* Boris
* Sherman
* Edgar
* Chauncey
If I had an IT shop, prolly would be MAL, ZOE, WASH, JAYNE, BOOK, KAYLEE, etc. -- once FF characters are done with, prolly would be BUFFY, XANDER, SPIKE, ... just kidding! I'm not *that* geeky! :o
after working in a larger wan environment I am staring to appriciate boring functional naming standards. A name like svedm001 tells me a box is a server and in edmonton, rtedm001 is a router in edmonton... etc Where as the dev servers stan, cartman and kyle don't stand out.
Yeah, I'd only use funky names at home or in a small environment.
Ok, thats not quite true, I don't use funky names on any of my VMs at home, one is "svn", another is "awiki" (allegro wiki), another is "asterisk", you get the picture :)
Quote from: Lazybones on September 24, 2007, 11:36:19 PM
after working in a larger wan environment I am staring to appriciate boring functional naming standards. A name like svedm001 tells me a box is a server and in edmonton, rtedm001 is a router in edmonton... etc Where as the dev servers stan, cartman and kyle don't stand out.
As long as the names are meaningful... my UAT server pool is prefixed with EBD1- but my development environment is prefixed as EBA1- now tell me what you think that means! I won't even talk about database naming!
So with all this "good" naming conventions (as Lazy described), you loose the concept of "security through obscurity". This may not be an issue to you, but just thought I would point that out.
At NAIT, we still follow this style of security obscurity naming for the most part. Some departments have similar naming systems as you guys described here, but for the most part the department I work for, we utilize naming that has nothing to do with the system, location, or function. We have documentation to support the name to function, so that we can easily determine what a server is for, but based on the fact that our client base is so large and diverse, we thought this would be a prudent way to name our systems.
Just think of over 40,000 people attached to your network behind your firewall, consuming your server resources, that aren't employees of your company, nor do they have any real ties to your systems health other than their tuition. Now throw in the fact that they may decide to perform malicious things on that network, or just want to see how secure you really are (CST, SSA, CSE students). When considering this, every security measure we can employ (within reason) we utilize as best we can. Not to say just the naming convention is our only security measure, but is one of many to help ensure we are safe under these conditions.
Quote from: Melbosa on September 25, 2007, 10:59:49 AM
So with all this "good" naming conventions (as Lazy described), you loose the concept of "security through obscurity". This may not be an issue to you, but just thought I would point that out.
Security through obscurity
can't be trusted.
I can't put it any better than the summary provided here (http://en.wikipedia.org/wiki/Security_through_obscurity#Arguments_against) but really, any security focused component that relies on secrecy will be revealed it's just a matter of time.
I've seen a lot of counter arguments from security experts and industry pundits who say it "just works" but the trouble is that sometimes people can connect the dots, use educated guesswork or rely on information leaks and good old fashioned human error.
No matter how obscure your database server name is it only takes one CC'd e-mail outside an organization to a trusted vendor to expose it and one disgruntled vendor employee to exploit it.
True, and that is why it isn't the only security measure we utilize, just one of many.
Quote from: Melbosa on September 25, 2007, 11:35:42 AM
True, and that is why it isn't the only security measure we utilize, just one of many.
Well if you can't trust a security measure it's not important, you could name your servers anything you want if you rely on something stronger.
Security didn't factor into our name choices at NAIT at all - nor would I ever recommend using "security through obscurity" for anything - even if only an additional layer.
We use random fictional names because it puts some enjoyment into what can be a boring/repetitive job. Also - just because names are taken from say TV shows, doesn't mean the names don't carry any meaning. For example, most of the servers involved in our Student-Admin system are named Todd, Rod, Jimbo, Nelson, etc. - the Student Admin system servers are students from the Simpsons. The ESX farm is all Futurama names - when you see Leela on the network you have a pretty good idea what it's doing. When I see a star-wars name, I know it's something Russ created.
Also - even in a large environment, "name" names have some advantages. Though us sys-admins end up having a LOT of names to try and remember (good admin tools make that easy), the users/developers still typically only deal with a few machines (we often also let the developers pick names for the dev DB servers and stuff) and it makes it easier for them to not have to remember/type obscure abbreviations.
So you make it harder for yourself to determine whether a compromised server is important or not, by naming it obscurely? Really, as much as it makes it a
smidgen harder for a hacker to figure out what the server does (although they typically compromise a server
and then determine what they can do with it), it also makes your job harder.
Obscurity does not provide security. "Security through Obscurity" is a misnomer and people relying even
partially on that misnomer need to give their head a shake. All obscurity does is make a security analyst's job harder, thereby making the whole of the security set-up more
fragile. After all, it's the security analyst who has to understand the entire system so that they can envision all possible attack vectors and remove or reduce them as much as possible.
If anything, I would define the "Security through Obscurity" that so many people refer to as Fuzzy Security (//http://):
Quote
Fuzzy security. Fuzzy security is actually the notion used by cryptographers throughout history until the last few decades. By fuzzy security I mean the following process: some guy comes up with some sort of cryptographic algorithm (let's think about an encryption scheme, but one can also think of other examples, such as hash functions or obfuscators). He then makes some vague claims about the security of this algorithm, and people start using it for applications of national or personal security of the utmost importance. Then, someone else (a hacker) manages to break this algorithm, usually with disastrous results to its users, and then the inventor or users either "tweak" the algorithm, hoping that the new tweak is secure, or one invent a new algorithm. The distinguishing mark of fuzzy security is not that it is often broken with disastrous outcomes. This is a side effect. The distinguishing mark is that there is never a rigorous definition of security, and so there is never a clearly stated conjecture of the security properties of this algorithm. Another common mark of fuzzy security is keeping the algorithm a secret. This is indeed unsurprising - if you don't know exactly what is the security of your algorithm, and you don't really understand what makes it secure, then keeping it secret seems like a good way to at least prolong the time it takes until a hacker finds a bug in it.
I want to stress that I do not intend to discredit the cryptographers throughout history that constructed "fuzzily secure" algorithms. Many of these people were geniuses with amazing intuitions, that paved the way for modern cryptography. However, this does not mean that we need to use their algorithms today. Today for most cryptographic tasks we do not need to use fuzzy security, since we have very good security definitions, and constructions that are reasonably conjectured to satisfy these definitions. One exception is indeed obfuscators, where so far no one has come up with a good definition for the security properties of obfuscators. Also (and this is not a coincidence) progress in obfuscator research seems to be of the sort mentioned above. One guy builds an obfusactor, an industry uses it, it gets broken, and then they build a new obfuscator (and/or try to pass laws making breaking obfuscators illegal..)
But hey, I know enough to know that none of us on this forum are security experts. There are ninety-nine ways to do security wrong and only one way to do it right. I know enough that I don't know for sure what that one way is.
Quote from: Cova on September 25, 2007, 11:50:39 AM
Security didn't factor into our name choices at NAIT at all - nor would I ever recommend using "security through obscurity" for anything - even if only an additional layer.
We use random fictional names because it puts some enjoyment into what can be a boring/repetitive job. Also - just because names are taken from say TV shows, doesn't mean the names don't carry any meaning. For example, most of the servers involved in our Student-Admin system are named Todd, Rod, Jimbo, Nelson, etc. - the Student Admin system servers are students from the Simpsons. The ESX farm is all Futurama names - when you see Leela on the network you have a pretty good idea what it's doing. When I see a star-wars name, I know it's something Russ created.
Also - even in a large environment, "name" names have some advantages. Though us sys-admins end up having a LOT of names to try and remember (good admin tools make that easy), the users/developers still typically only deal with a few machines (we often also let the developers pick names for the dev DB servers and stuff) and it makes it easier for them to not have to remember/type obscure abbreviations.
I stand corrected. I was miss-informed.