Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Fonality does not track your root password.

Fonality product ships or installs with a root password pre-configured and does not recommend setting a root password. Setting a weak root password could make your system less secure and should only be completed by an experienced Linux System Administrator at your own risk.

The following is not Fonality endorsed or recommended - accessing the server as root is at your own risk. Any damage or changes caused while logged in as root are not covered by the Support contract, and may cost money to fix (e.g. provision and send replacement hard drives):

  1. You must set the root password via the local system console.

  2. Attach a monitor and keyboard to your PBXtra

  3. Login using 'ip' as the username and 'ip' as the password

  4. Choose the appropriate option, labeled "Set root password".

  5. Type in a secure password*

  6. Type in your password again to verify

  7. The system indicates that all 'tokens' have updated successfully

  8. Press Enter to return to the main menu

  9. Press Q to logout

  10. You can now login as username: root and password: the password you just set

*-See "picking a password" below

 

Security considerations

As with any server, we recommend you do *not* expose port 22 (ssh) to the Internet, whether or not you've set a root password.  Port 22 is one of the most popular approaches for server cracking.

If one must allow outside connections to port 22, whitelist it.  For example:
'allow specific IP addresses'
'deny all'

This recommendation can be extended to other port numbers as well. Ports 21 (FTP), 22 (SSH), 69 (TFTP), and 80 (HTTP) shouldn't be exposed to the Internet.  Ask yourself what ports you forward/allow to your server, and do you really need to be forwarding them?

For what ports to allow and which to block, please read: Port forwarding diagnostics and security considerations

 

Picking a password

Bad passwords

root123 is a bad password.

r00t!@# is also a bad password.  Password crackers know letter/number substitution better than any human.

hunter2 is a bad password.  hUnt3r2 is also a bad password (it may take longer to crack, but not long enough to be significant).

Pet, place, person, thing names and foreign words are also bad passwords. 
Something doesn't have to be in the english dictionary to be in a password cracker dictionary.

Strong passwords

These are only guidelines and suggestions.

At least 10 characters long, consisting of letters, numbers, mixed case, and punctuation.
Caveat: the root password is flexible, but some webpage passwords don't like punctuation.

wOVW9zH43453 might have been a strong password, but now that it's been posted online, it's no longer secure.  Don't use this one - it's just an example.

A strong password is not necessarily a good password, especially if you have to write it down to remember it.  Which brings us to passphrases.

Picking an unpredictable passphrase and using the last (or first) letter(s) of each word.  E.g. "Can't I just set a password and get on with it ?" CIjsapagowi?
(This is actually a fairly predictable passphrase, but it's just an example)

The amount of time it takes to crack a password goes up with the number of letters.  If you string less-common words together, a dictionary attack is going to be hard-pressed to find the right phrase.

There are some caveats to this approach - such as password fields that only accept a limited number of characters. 

For more information

Passphrase FAQ - taken from alt.security.pgp
http://www.unix-ag.uni-kl.de/~conrad...hrase-faq.html

xkcd: Password Strength
http://xkcd.com/936/

Password Recovery Speeds - strengths of various lengths/types of passwords.
http://www.lockdown.co.uk/?pg=combi#classB

Unofficial Q&A - aka 'Why shouldn't I expose port 22 to the Internet?'

But don't you blacklist an IP address after a certain number of incorrect tries?

One way we've seen this defeated is via distributed botnets - each IP address tries a single connection attempt per 30 or 60 seconds, so no one IP address trips the limiter.  But there are tens or even hundreds of thousands of IP addresses, and each one of them is trying, so it adds up to the same thing - thousands of attempts per second.

This can also be and is used in denial of service attacks, if the attackers determine that keeping track of the blacklisting for all the different IP addresses is increasing system load.

What if you limit the total connection attempts per second on SSH?

You'll rarely if ever be able to get in, because of the thousands of attempts hitting it every second as a matter of course for any system with port 22 exposed.

 

References / pertinent information

Port forwarding diagnostics and security considerations

  • No labels