The following is not critical if your Luna systems reside inside secure locations, behind strong firewalls, and are managed only within/between such secured locations (via VPN for example).
However, if your application places the Luna appliance in the "DMZ", please consider the following:
Attackers are known to be making concerted efforts to compromise server administrator account passwords. Given research published over the past few years showing the capabilities of popular game console hardware, for example, to act as extremely fast brute force password generators, it is very likely that these recent attacks are making use of automated systems. For this reason, it is strongly recommended that particular attention be given to creating strong passwords for the appliance “admin” and “operator” accounts. If possible, passphrases of 15 characters or more should be considered. One established technique for generating passphrases is to select a phrase at random from a book, remove spaces and punctuation, and insert numeric and special characters to replace some of the letters. If you use this sort of technique, it is good to avoid some of the more common replacements such as capitalizing the first or last character in a word, replacing “e” with “3” or “s” with “$”, etc. since they would be the first ones tried by an attacker or password generator system.
Given the sheer numbers of computer-using people in the world, any 'rule of thumb' that you can devise for streamlining your password-making has undoubtedly been thought of by someone else. If it's a rule, it can be automated. so assume that it has been automated by password-cracking programs everywhere. For example, look to the emerging "language" of text-message abbreviations for examples of substitutions that are already widely practiced and would therefore be easily cracked.
Longer and more complicated passwords are progressively harder to crack, but they are also far more difficult to remember. Therefore long complicated passwords are more likely to need writing down, which drastically increases risk of exposure by means of 'social engineering' or simple detective work on the part of attackers.
Currently he most secure text password seems to be a string of several UNRELATED words in your language of choice, preferably with no double characters, and totaling more than twenty characters. So, don't choose a phrase from a book. Your password should be nonsense, but nonsense that you can remember.
For example battery_trick$rapid6pink - to get around the rule of "no doubles", you could insert a dash, or space or other character bat-tery_trick$rapid6pink but don't use that exact example - once this Help becomes public, that combination will be in a dictionary.
Change the SSH port number from the well-known number 22 to something in the range of 1025 to 65535. Use the lunash:>sysconf ssh port command to change the SSH port number.
You can choose to use certificate-based authentication for your "admin", "operator", and "monitor" users (or named users with those roles) to connect, instead of password authentication.
See the sysconf ssh publickey commands. When creating your certificate on a client/admin computer, select a key size of 1024 bits or greater to generate the certificate.
However, because the certificate resides on a computer, it is ultimately only as secure as access to that computer, which is likely protected by password (see above).
NIST announced that Draft Special Publication (SP) 800-118, Guide to Enterprise Password Management, has been released for public comment. SP 800-118 is intended to help organizations understand and mitigate common threats against their character-based passwords. The guide focuses on topics such as defining password policy requirements and selecting centralized and local password management solutions.
http://csrc.nist.gov/publications/PubsDrafts.html#800-118