Computer Protection Program Berkeley Lab
Computer Protection Program at Berkeley Lab Security
Ernest Orlando Lawrence Berkeley National Laboratory
Emergencies | Site Index | Contact Us
CPP Home
Contacts
Policy Guidelines
Scan Information
System Procedures
Tools & Services
ALERTS
Recent CPP Actions
News & Articles
CPP Intranet
 
 
  PROCEDURES FOR SECURING SYSTEMS  
Voluntary OTP SSH Gateway  

Summary

The IT Division and Computer Protection Program (CPP) are providing a free OTP SSH gateway that uses Cryptocard technology. Those who recognize the risk of SSH credential theft can acquire an OTP token and SSH into the lab without fear of their credentials being stolen. The procedures below outline the process for acquiring an OTP token and using the OTP SSH gateway.

Quick Start

Acquire a token for the OTP SSH Gateway (insure.lbl.gov) by visiting the LBNL Accounts webpage and select "OTP SSH Gateway".

If you acquire a software token, you will also need the CRYPTOCard Authenticator software available for Windows, OSX, and Linux.

Background

By far, the most costly security incidents at Berkeley Lab are due to SSH credential theft. Berkeley Lab is not the only target. In the last few years there have been several high profile incidents involving hundreds of computers in the .gov, .edu, and .com space. Due to the relative ease of the attack and past success by attackers, CPP expects that credential theft attacks will continue in the future.

SSH credential theft occurs when an unauthorized person (attacker) obtains and uses valid SSH account credentials (username and password) for unauthorized access to a computer. The attacker typically obtains the valid credentials by keystroke logging a previously compromised computer. Once the attacker has gained access to the computer she may perform any number of malicious activities including hosting malicious files, attacking other computers, installing rootkits, or destroying data.

In the below example, a Berkeley Lab User visits Hacked State University. Unknown to Hacked State many of its computers have been compromised and keystroke loggers installed. When the Berkeley Lab User authenticates to her Berkeley Lab Computer, the attacker steals her credentials. The attacker then logs into the Berkeley Lab Computer at a later date, perhaps from Hacked State, and performs malicious activity.

The most common method to prevent credential theft is One Time Passwords (OTP). OTP technology allows the remote Berkeley Lab user to generate a new password for each connection. The password is generated either by a physical hardware device or software. After an OTP password is used once to authenticate, it is no longer valid. With OTP, even if an attacker has a keystroke logger installed at Hacked State, acquiring the password is no use to the attacker since the password is invalid immediately after being used.

Hardware vs. software

There are two types of tokens available, hardware and software .Hardware tokens are physical devices that generate passwords. Software tokens are electronic files that are imported into CRYPTOCard Authenticator to generate passwords. CRYPTOCard Authenticator is software you run on one of your computers. A single software token can only be used on one computer. A user can have multiple software or hardware tokens.

For both hardware and software, a PIN is required to unlock the device and generate a password. Below are pictures of a hardware token and the CRYPTOCard Authenticator software.

There are benefits and drawbacks to both hardware and software tokens. Software tokens are convenient because you don't have to carry around a physical device. On the other hand, software tokens require you to install the CRYPTOCard Authenticator software to generate a password. The hardware token can be used from any system without additional software.

Import a software token

The first step to use a software token is to install the CRYPTOCard Authenticator software (Windows, OSX, and Linux).

Once CRYPTOCard Authenticator is installed, you need to import the software token you were issued into CRYPTOCard Authenticator. Software tokens are binary .token files that are named a string of numbers, for example 620018519.token. Typically this token file will be sent to you via email with an initial PIN when you sign up for a Voluntary OTP account. The following describes the process for importing a software token into CRYPTOCard Authenticator.

  1. Double click on the software token file to begin the process. This will bring up the following dialogue box. Click 'Next' to proceed.



  2. This dialogue box allows you to configure your token. You can enter whatever you like as the friendly name, but typically your full name goes here. You should ensure the PIN you enter matches the PIN issued with your token and the "Login ID" matches the Login ID issued with your token. Designation can be left as "Default Location" then click 'Next'.



  3. The last dialogue box confirms the token was imported successfully, click 'Finish'.


Change your PIN

With either software or hardware a mandatory PIN change is required after issuance. Below is the prompt you will receive in the software version, the hardware screens are similar. Enter the PIN provided when you requested the token as 'Current PIN' and enter whatever PIN you like for the 'New PIN' and 'Confirm New PIN' fields. The minimum PIN length is 3 characters.

You can also change your PIN at any time by selecting "CHG PIN" on the hardware token or "Tools" and "Change PIN" from the CRYPTOCard Authenticator drop down menu.

Hardware password generation

Generating a password is simple using the following steps:

  1. Press the 'PASSWORD' button on the upper right corner to begin the process.
  2. Enter your PIN and the press 'ENT' in the lower right corner. Note the token will lock out after 7 failed PIN attempts. Visit the if things go wrong section if your token is locked out.
  3. Your password will then be displayed on the screen, for example 371-7371.
  4. You will enter this password into the SSH password prompt, the dash is optional.
  5. You can then press the 'PASSWORD' button again to turn off the device or just wait for it to turn off on it's own after a few seconds.

For additional detail about using hardware tokens, refer to the hardware token user guide in the reference section.

Software password generation

Generating a password with CRYPTOCard Authenticator is trivial. Below we walk through the process for generating a password the fictitious user called "test".

  1. If you haven't already, install CRYPTOCard Authenticator and import your token.
  2. Start the CRYPTOCard Authenticator software.
  3. Click the 'Generate Password' button and enter your PIN into the prompt and press 'OK'. Note the token will lock out after 7 failed PIN attempts. Visit the if things go wrong section if your token is locked out.



  4. Your password will them be displayed in the 'Secure Password box, in the example below it is 901-1479. The dash is optional when using the password.



  5. You will enter this password into the SSH password prompt, the the dash is optional. Also notice the copy button highlighted by the red circle above. By clicking this button you copy your password and can then easily paste it into the password prompt. This is very convenient in many users experience.

For additional detail about using software tokens, refer to the software token user guide in the reference section.

Connect to the gateway

The name of the OTP SSH gateway is insure.lbl.gov.

RSA key fingerprint of insure: 60:56:a9:58:5f:20:f6:2e:4a:dc:d2:8c:a3:80:96:e3 and the complete key is here.

You should connect to the OTP SSH gateway as you typically connect with SSH. The only difference is when you are prompted for your password you should enter the password generated by hardware token or CRYPTOCard Authenticator software. Once connected to the OTP SSH gateway, you should see a prompt such as this.

If you type 'help' you can see all the commands available on the OTP SSH gateway.

You will notice that very few commands are available in the OTP SSH gateway. This is to your advantage. Our intent is provide sufficient commands in the OTP SSH gateway to allow you to get your work done, but restrict all other functionality. By restricting functionality and and locking down the OTP SSH gateway, you can have greater confidence the OTP SSH gateway and your credential are secure.

We do realize there is such a thing as too much security! If you find that you need additional functionality not provided by the OTP SSH gateway, we want to here from you. What do you need? Why? How do you use it? We strive to be accommodating and will work quickly to make changes that make sense. Please send us feedback.

From the gateway - connect to LBNL computers

Once your connected to the OTP SSH gateway, you can connect to your Berkeley Lab computer. The preferred way to authenticate to your Berkeley Lab computer from the OTP SSH gateway is using SSH keys. Since an attacker could still be watching your keystrokes, authenticating from the OTP SSH gateway to your Berkeley Lab computer could allow your Berkeley Lab computer password to be compromised. We show an example below of authenticating with a password, but please consider setting up SSH key authentication, which is discussed next in the next section.

In the example below, the user 'test' connects the the host called hosed.lbl.gov using a password.

In the below example the users wishes to connect to hosed.lbl.gov as a different user, eolawrence. The -l switch allows one to switch the usernames in ssh.

In the above examples, we used a password to connect from the OTP SSH gateway to a Berkeley Lab computer. Since an attacker could still be monitoring keystrokes, the password again becomes a weak link. Next we show how to setup SSH key authentication between the OTP SSH gateway and a Berkeley Lab computer. This method is more secure since an attacker will not possess the SSH key needed to authenticate; they key only exists on the OTP SSH gateway.

Configure SSH key authentication

SSH keys allow you to SSH from one computer running SSH to another computer running SSH securely, without a password. Below we briefly outline the process to setup SSH key authentication. For a more detailed description please visit the references section.

If you already have an SSH key and are familiar with key setup, you can just skip this section and move your private key to the gateway.

  1. The first step with SSH key authentication is to generate an SSH keypair by running 'ssh-keygen'.



    ssh-keygen prompts for a passphrase to protect the keypair. CPP strongly advises you use a passphrase on your SSH key. This passphrase is needed each time you use your SSH key. Enter your desired passphrase and confirm the passphrase.

    Note ssh-keygen creates two files, id_rsa and id_rsa.pub, in the .ssh subdirectory of your home directory. The first file is your private key (id_rsa), the last your public key (id_rsa.pub). Your private key (id_rsa) is a sensitive file and needs to be protected, don't share it with anyone; it's like a password.
  2. The next step is to move the contents of your public (id_rsa.pub) to the Berkeley Lab computer to which you'd like to authenticate. The contents of the public key file must be placed in the .ssh/authorized_keys file of your home directory . We walk through the steps to complete these items next.
  3. On the Berkeley Lab computer, create a .ssh directory and a file called authorized_keys in the .ssh directory. An example is below.


  4. Next put the contents of the id_rsa.pub file into the authorized_keys file. This is easiest for most by just using copy and paste. Once this is completed, you can SSH into the Berkeley Lab computer using your SSH keys. An example is show below, notice the computer prompts for your SSH passphrase, not your password.

That's all there is to setting up SSH key authentication. Even if the attacker acquires your SSH passphrase, the passphrase is of no use without the SSH key. And since the SSH key is kept on the OTP gateway, your Berkeley Lab computer is safe.

SSH Forwarding with X

In this section we put all of the above together and add on the ability to forward X from a system behind the OTP gateway. By using a command like the below, it is possible to connect to your Berkeley Lab computer through the OTP gateway, without directly interacting with the gateway.

ssh -Y -t user@insure.lbl.gov ssh -Y user@your-computer.lbl.gov

The above command first connects you to insure.lbl.gov, then without further action from you, continues to connect you to the Berkeley Lab computer. You will first be prompted for your OTP password for insure authentication, then you will be prompted for authentication to your Berkeley Lab computer. Notice the -X options. This allows an X session to forward through the OTP gateway. The above is the preferred way to authentication and use the gateway.

Configure host firewall

An alternative to using SSH key authentication is to use password authentication and firewall your host to only accept SSH from the OTP SSH gateway. In this setup, even if the attacker acquirers the password to your Berkeley Lab computer, the password cannot be used except from the OTP SSH gateway.

Firewall configuration instructions for iptables and ipfw are coming soon...

If things go wrong

In this section we discuss things that can go wrong while using the OTP SSH gateway and the resolution for these items.

  • Your token displays "Locked"

In this case there is not much you can do. Tokens lock out after 7 failed PIN attempts to prevent tampering. Please contact the token issuer to have your token reinitialized.

  • You cannot authenticate with OTP password

If you cannot login to the OTP SSH gateway and you've checked the obvious stuff (right host, right username, typing the right password) then it could be the case that your token is out of sync. Please contact the token issuer to have your token resynchronized.

Policy

As a user of the OTP SSH Gateway there are a few policies to be aware of, they are listed below.

  • Not a high availability service
  • The availability of the OTP SSH gateway is best effort. This service does not have 24/7 availability nor a defined timeframe in which it will return in the event of failure. We will try our hardest to keep it up, but we don't recommend you make the gateway a critical component in getting work done.

  • All keystrokes on the gateway are monitored

    To protect the users of the OTP SSH gateway all keystrokes are logged to a secure location. In the event of a compromise, this data will be used to ensure we can track down the full extent of the damage.

  • Can only connect to Berkeley Lab computers

    The gateway restricts outbound SSH to only Berkeley Lab computers.

  • User files are deleted regularly (except SSH configuration files)

    Data files should not be stored on the OTP SSH gateway. All files, except SSH configuration files, are deleted after 30 days.

  • Tokens not used in 6 months must be returned

    Tokens cost money, even software tokens. We will monitor usage and ask that tokens not used for 6 months be returned so they can be reissued.

References

The CRYPTOCard software token guide can be found here.
The CRYPTOCard hardware token guide can be found here.
Fermi National Laboratory has excellent documentation on using your CRYPTOCard.
IBM has a good article on OpenSSH key management.

Feedback

Comments and feedback of any sort is welcome. Please send email here.

 

 

 

 

Home | Contacts | Policy Guidelines | System Procedures | Tools & Services | ALERTS | News & Articles