Two-factor SSH authentication via Google secures Linux logins

Takeaway: Vincent Danen details the steps of setting up Google two-factor authentication for SSH.

When Google introduced two-factor authentication for the Google and Google Apps accounts, they also created a pluggable authentication module (PAM) for Linux. This is great news for people running Linux servers who want to protect their remotely-accessible SSH accounts with two-factor authentication. For free.

Two-factor authentication is where you authenticate to a service with two pieces of information: one you know, and one you don’t. The information you know is your password (which can be stolen) while the information you don’t know is a randomly-generated PIN number that changes every 60 seconds. So even if your password is stolen or discovered, unless an attacker has the means to get the right PIN (tied to a hardware device), they cannot log into the protected service.

Google has created the Google Authenticator application for iPhone, Android, and Blackberry — effectively turning your phone into your hardware token device. Before you can make use of two-factor authentication to secure your Linux logins, you will need to enable it in your Google account (I also wrote a tip on setting up Google two-factor authentication for users of Mac/iPhone).

Once two-factor authentication is enabled and working with your Google or Google Apps account, you can begin setting up the same for your Linux server. To do so, you will need to download and compile the PAM module for your system. The examples here will be based on Fedora 14, but it should be easy enough to figure out the equivalents for whatever distribution you happen to be using. It also assumes you have sudo writes to run anything as root; if that is not the case, su to root to run those commands (as root) that are prefixed with sudo. You will need mercurial installed to initially check out the code.

$ sudo yum install pam-devel

$ hg clone https://google-authenticator.googlecode.com/hg/ google-authenticator/

$ cd google-authenticator/libpam/

$ make

$ sudo make install

$ sudo vim /etc/pam.d/sshd

Once the PAM module and the command-line google-authenticator application are installed, you need to edit the /etc/pam.d/sshd file to add the module, so it may end up looking like:

auth required pam_sepermit.so

auth required pam_google_authenticator.so

auth include password-auth

This sets up two-factor authentication for SSH. It is also possible to do the same for gdm, requiring the use of two-factor authentication to log in locally.

When that is done, as the user that you want to require two-factor authentication for, run the google-authenticator application, which will create a new secret key in your home directory:

% google-authenticator

https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/user@server%3Fsecret%3DSAEP64T5VZAVWAFB

Your new secret key is: SAEP64T5VZAVWAFB

Your verification code is 376046

Your emergency scratch codes are:

67868696

26247332

54815527

54336661

71083816

Do you want me to update your "~/.google_authenticator" file (y/n) y

Do you want to disallow multiple uses of the same authentication

token? This restricts you to one login about every 30s, but it increases

your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, tokens are good for 30 seconds and in order to compensate for

possible time-skew between the client and the server, we allow an extra

token before and after the current time. If you experience problems with poor

time synchronization, you can increase the window from its default

size of 1:30min to about 4min. Do you want to do so (y/n) n

If the computer that you are logging into isn't hardened against brute-force

login attempts, you can enable rate-limiting for the authentication module.

By default, this limits attackers to no more than 3 login attempts every 30s.

Do you want to enable rate-limiting (y/n) y

In your browser, load the URL noted above; it will show a QRCode that you can scan into your phone using the Google Authenticator application for iPhone, Android, or Blackberry. If you already have a Google Authenticator token being generated on your phone, you can add a new one and it will display them both (and distinguish them by name).

One quick tip: time is _very_ important, so the server you are logging into should have an NTP client installed in order to keep the time accurate. Keep an eye on this; if you are having trouble you may have to open the window size as noted by google-authenticator.

You will also need to edit /etc/ssh/sshd_config to enable “ChallengeResponseAuthentication” and “UsePAM” (set them both to “yes”).

Restart sshd after making any changes to the file.

When this is done, try logging into the system via SSH:

% ssh server

Verification code:

Password:

Last login: Tue May 10 11:54:21 2011 from client.example.com

You must provide the verification code as presented by your phone in order to log in. Even if the password is known, without the verification code, the login will fail. Also note that you will be unable to use this if you use ssh private/public keys as the two are mutually exclusive (key-based logins get a passphrase prompt client-side and never provide a password to the server).

Setting up two-factor authentication for SSH is surprisingly simple, thanks to Google. It only takes a few minutes to set up, the infrastructure and tools are free, and the security gains are great.

http://www.mnxsolutions.com/security/two-factor-ssh-with-google-authenticator.html

Change Your Thoughts And You Change Your World !

Configuring SSH login mail alert on checkpoint secureplatform..

http://firewalltips.blogspot.com/2010/05/configuring-ssh-login-mail-alert-on.html

How add / change interface IP on Nokia IP useing clish / CLI??

Below shows you the commands required to change the IP address of an interface within clish on a IPSO Nokia gateway,

1.add interface eth1c0 address IP [NEW IP]/[NETMASK]

2.delete interface eth1c0 address [OLD IP]

3.set interface eth1 speed 100M duplex full active on

4.set interface eth1c0 enable

Below gives you an example :

1.nokia-firewall[admin]# clish

2.NokiaIP390:102>add interface eth1c0 address IP 192.168.1.1/24

3.NokiaIP390:102>delete interface eth1c0 address 172.16.1.1

4.NokiaIP390:102>set interface eth1 speed 100M duplex full active on

5.NokiaIP390:102>set interface eth1c0 enable

F5 LTM VE – Node Monitors

A node is the actual physical server. So in this case, a node would be WebHost1, 2, or 3. Members are a specific service on a node. As we saw when we added pool resources we specified an IP address (the node) and the port (node + port = member (in most cases)). That being said, we never actually defined any nodes. Let’s take a look at what it did for us. Click on ‘Nodes’ under the ‘Local Traffic’ menu on the left. You should see something like…

So the LTM created nodes for us. These could be left as is, but I’m going to open each one and change the name so its more descriptive. You’ll notice that while you are in the node settings changing the name that there is an option for a health monitor. The default should be set to ‘Node Default’ as shown below…

Back on the main ‘Node’ screen you’ll see at the top an option for ‘Default Monitor’. You should have also noticed that the nodes are showing availability as ‘unknown’. This is because we are telling the node to check its availability using the ‘Node Default’ but we haven’t defined that yet. My host are available via ICMP, so I’ll configure that as my node default monitor.

Click ‘update’ and then click ‘Node List’ to go back to the main ‘Node’ window. It should now look like this…

Note the updated names as well as that they all show as green indicating that they are available. So now we have health checking enabled on both the member as well as the node itself. If a node goes offline, all of its members will fail the health check and be removed from the pool. We’ll wrap up this section with a quick test of that. I’m going to reboot WebHost1 and we are going to verify that traffic headed for the VIP doesn’t balance to the down server.

The instant the server stops responding to pings I can see that the pool member shows as down.

Additionally we can see that the node itself is marked as down…

A quick check of the VIP shows a pattern of…

This showing of course that WebHost1 is no longer in the pool. The instant it comes back online both monitors will show as green and it will be back as part of the pool.

In the next few posts I’m going to jump into some more of the more interesting pieces of the LTM config including load balancing methods, persistence, and hopefully I can get to iRules soon.

F5 LTM VE – Setting up basic load balancing

In this post we are going to go through setting up basic load balancing. On the LTMs this is a relatively easy task so I’m going to rip right through it. The nice thing about the configuration is that instead of starting from the bottom up, you can actually start from the top down. So rather than creating all of your nodes, then creating the members, and then the pool, we can just start with the virtual server and add the other objects. Best shown by example, so here we go..

Log in to your VE LTM and blow up ‘Local Traffic’ on the left menu bar. Select the ‘’Pool’ option and on the far right select the ‘Create’ button.

On the next screen, give the pool a name, select ‘http’ for the health monitor, and then move down to the resources area. Enter the information for each of your web hosts into the ‘New Members’ area. Enter 1’s info, then hit add, etc. until all of them are listed in the text box as shown below…

Then click ‘Finished’ to create the pool. You should now see your pool created and it should have a pretty green circle next to the name indicating that the monitors are succeeding in querying the device on port 80.

Now that the pool is created, we need to create a virtual server to associate it with. Select ‘Virtual Servers’ from the ‘Local Traffic’ menu on the left hand side of the screen. Then click the ‘Create’ button on the far right of the window.

There are lots of options on the next screen but just concern yourself with the ‘General Properties’ window. The ‘Destination’ field is the IP of the VIP that clients will connect to in order to be load balanced. Fill in your relevant information as shown below…

Then scroll to the bottom and click ‘Finished’ to create the virtual server. Once the server is created, it will take you back to the main virtual server window. Click the ‘Edit’ link on the far right of the virtual server description under resources…

Under ‘Default Pool’ select your newly created pool and then click ‘Update’

At this point we are ready to test. Open up a web browser and point it to the VIP. http://10.20.20.21 and see what you get. Hopefully, you’ll get nothing. Why do you ask? Because the web servers are returning traffic to our default gateways, not the LTM. Open up the virtual server settings and change the ‘SNAT Pool’ setting from ‘None’ to ‘Automap’. Automap tells the LTM to change the source to one of its self IPs in that subnet. In this case, it would source the packets from the 192.168.1.40 address.

Once the SNAT pool is specified, try hitting the VIP again and see what happens. With any luck you should get one of the web servers. Three refreshes and you should see all of the web servers get hit as shown below…

So that is all it takes to setup a very simple load balancing configuration. Not hard right? In the next post, we’ll go back through and talk a little bit more about what we just set up as well as look at monitors.

F5 LTM VE – Configuring Persistence

One of the main problems with load balancing is persistence. Some web applications require that the external user return to the same web server each time, or at least each time within a given window of time. That being said, there needs to be a mechanism in which we can determine if the external user has connected before, and if so, to what server he was balanced to.

Persistence is a configuration option of the virtual server. There are two settings for persistence. The first being the default persistence profile. Default persistence is the main persistence mode used for the virtual server. The second option, fallback persistence, is used when the first method of persistence fails. For example, if the default persistence is set to ‘cookie’ but the client isn’t accepting cookies, you could fallback to source persistence. There are 8 different persistence profiles, let’s walk through them one at a time with some examples along the way.

Source Address Persistence
This is a pretty common type of persistence. The LTM tracks the source of the incoming packet and redirects any connections coming from that IP to the same pool member. When this is configured on our test virtual server we see a return like this…

Destination address Persistence
Persistence based on the destination address is much like source address persistence. Except that the F5 examines the destination of the packet rather than the source. Now, you might ask yourself, when would this actually be useful? Think of a setup where an LTM is load balancing a set of proxy servers that are doing caching. Clients would be forced through the proxies to the external site (read destination) and the proxy would cache that site. Going forward, it would make sense to balance clients going to the same destination to the same proxy since that particular proxy already has the website cached.

Cookie Persistence
Cookie persistence is another common load balancing type. Cookie persistence requires that a HTTP profile be associated with the virtual server. We’ll talk more about profiles in another blog entry. When using cookies the F5 will examine the incoming request and determine if the appropriate cookie is part of the request. If it is, the F5 will balance the client to the same member based on the cookie. There are 4 different methods of cookie persistence. These can be set under the cookie persistence profile…

The default method is ‘Cookie Insert’. In this mode the F5 writes a cookie called ‘BIGIPServer’ into the response from the web server as it passes through the F5 on its return path to the client. This method require no additional configuration on the web servers.

In ‘Cookie Passive’ mode the web servers must control the insert and updates of the BIGIPServer cookie. The F5 only looks at the Cookie to determine which server the request should go to.

In ‘Cookie Rewrite’ mode the web server must send a cookie formatted in a particular order to the F5. The F5 will then rewrites the cookie to the BIGIPServer cookie, updates it with the member information, and sends it back to the client.

In the last mode ‘Cookie Hash’ the LTM examines the cookie inserted by the web server on a previous connection and makes a load balancing decsion based on the hash in the cookie. While the LTM is still making the load balancing decision, its making it based off of the cookie set by the web server. This effectively moves the brains of the load balancing decision to the web server(s) that calculate the hash to insert into the original cookie.

To see the cookie on the client, you’ll need to change the cookie persistence profile from ‘Session Cookie’ to an set expiration cookie. Session cookies are only good for that particular session and are stored in memory so they are never written to disk. The expiration date of the cookie is updated each time the client hits the F5 so its sort of a rolling expiration. At any rate, set it for at least an hour, and then hit the VIP with your browser. I used a app called ‘IECookiesView’ to read the cookie…

Hard to see there, but the cookie is on the system at this point.

Hash Persistence
By now you should be seeing that things including the hash function on the F5 are the more advanced custom like features. I’ve never used this but I imagine you could use an iRule to examine the hash and make decision based on that.

Microsoft Remote Desktop (msrdp)
Tracks sessions between the RDP server and client

SIP (sip_info)
Persistence based on servers that receive and process SIP traffic

SSL
Keeps track of the sessions using the SSL Session ID

Universal
Allows for persistence based on custom expressions that you can write yourself.

Well that covers all of the different types. You can probably tell that I went into greater detail on some of the more common ones. The last few I at least haven’t dealt much with, so I don’t have a ton of info on yet. If and when I get more info, I’ll update the post.