bill’s blog

For many years I’ve been editing /etc/motd warning unwelcome visitors that they shouldn’t be on my systems. Unfortunately, by the time they see the motd they’re already on my system! SSH has an option to display a banner before a visitor is prompted for a password! Not only is this feature great for warning unwelcome visitors they should stay away… It can also be used as acknowledgment of an acceptable use policy! They have to read the banner before they login!

So what do I have to do to make this work? Read on!

First login into the server you wish to set up the banner for. The configuration files for sshd are all located in /etc! Next you’ll need to create the file that contains the disclaimer. In my case in named it ssh_banner.

Open you favorite text editor and create your login banner file:

sudo vi /etc/sshd_banner

Edit the file however you wish. I have the following:

Unauthorized Access Prohibited!
Authorized users are bound by randomdog.net’s acceptable use policy!

Next you’re going to have to edit the ssd_config file.

sudo vi /etc/sshd_config

The line you are looking for is:

# no default banner path
# Banner path/to/file

Edit it to read

# no default banner path
Banner /etc/sshd_banner

The last thing you need to do is restart the sshd process.
This can either be done by using ServerAdmin Select the server you were working on… then under the settings tab deselect Remote Login (SSH) save and then re-enable.
or on OS X client go to Sharing… then deselect Remote Login save and then re-enable.

You should now see something like this:

columbia:~ billheese$ ssh billheese@10.0.10.10
Unauthorized Access Prohibited!
Authorized users are bound by randomdog.net’s acceptable use policy!
Password:

Securing SSH

SSH or Secure Shell is one of the most useful applications for administering computers remotely. In reality it is a suite of applications that were created to replace a number of insecure equivalents. Telnet was replaced with SSH which allows for command line access to remote hosts. SCP replaces out RCP, which allows for copying of files or directories to a remote host. Lastly SFTP replaced out FTP and allows for the placing of files on a remote host for later retrieval from a third party. Why replace out the old standards? All data transmitted using these older standards are sent in the form of clear-text. This includes your user ID and password! Data sent via these newer standards are encoded using strong encryption algorithms (Triple DES, Blowfish, AES to name a few). SSH encrypts your data before it is put on the wire. The result is transparent encryption: users can work normally, unaware that their communications are safely encrypted on the network (Barrett, 2001). SHH has a number of benefits. You can get more information at the OpenSSH website.

Out of the box Apple does a great job of securing the OS but there are a number of ways to help SSH further. Apple by default allows root access via SSH. This is not a bad thing per say IF the passwords are strong. The reality is that passwords are never as strong as they should be. Often the passwords are based on normal everyday words and user accounts are normally easy to guess… How about Administrator for example? This can lead to a brute force dictionary attack that if the host is compromised root access is achieved…a bad thing to say the least.

Disabling root

Apple allows root access by default because it needs this to set up replica servers in Open Directory (OpenLDAP). Once the replicas are bound to the directory root access should be turned off. Unfortunately this is not something that can be accomplished easily from Server Admin. There are two ways to accomplish this:

1. Edit the /etc/sshd_config file using a text based editor and add the following line to the end of the file:
PermitRootLogin no
This is by far the most direct method to accomplish this.

2. The other is to allow other users to access the host via SACLs (or Service Access Control Lists).

Figure 1

The downside to option 2 is that you are forced to allow users you may not want having access to you server. As you can see from this above image we have disabled root by allowing the user Bill Heese to have SSH access to the server. This may not always be the desired outcome. The nice thing about disabling the root account this way is the ease of this can be configured. Apple provides a very nice GUI application to accomplish this, Server Admin. One thing to note is that if you are administrating a large number of desktop as well as server this needs to be done on the workstations too. And have SSH enabled you should be editing the sshd_config file on those machines as well.

SSH Keys

Let’s say that you have to log into 20 or 30 machines per day, at the end of that day that can lead to a lot of keystrokes. Even the most focused individual can get interrupted may times during the course of a day. Trying to remember exactly why you are access a host can be a challenge at times now add to that, the servers password. 
 

There are those that feel that using SSH keys is an unsafe practice (and it CAN be) if you don’t protect your host correctly. I have this implemented behind a gateway firewall and behind IPFW rules. This being the case a hacker would have to compromise the network and then the host itself. Is this a guarantee that a hacker can’t get to you? No, but it does make it somewhat more difficult to get at the machines. 
 


So the first thing that I need to do is generate the keys that I am going to use. 


ssh-keygen -t dsa 
 


You can use other algorithms based on your comfort levels. See the man pages on ssh-keygen to see which flags are built into your version of ssh. You should see something very much like this:

 

control:~ bheese$ ssh-keygen -t dsa 

Generating public/private dsa key pair. 
Enter file in which to save the key (/Users/bheese/.ssh/id_dsa): 

Enter passphrase (empty for no passphrase): 

Enter same passphrase again: 

Your identification has been saved in /Users/bheese/.ssh/id_dsa. 

Your public key has been saved in /Users/bheese/.ssh/id_dsa.pub. 

The key fingerprint is: 
52:d4: ee:d5: c9:b9: 2e:0a: 0a:ac: 6a: 8d:c9: ee: 9c:cc bheese@control.randomdog.net

 

I did not put a passphase in as I want to be able to access the server using only my SSH keys! ls produces the following out in the .ssh directory. 
 


control:~/.ssh bheese$ ls -al
total 48
drwx------ 7 bheese bheese 238 Mar 2 18:58 .
drwxr-xr-x 30 bheese bheese 1020 Feb 29 22:51 ..
-rw------- 1 bheese bheese 672 Mar 2 18:58 id_dsa
-rw-r--r-- 1 bheese bheese 626 Mar 2 18:58 id_dsa.pub
-rw-r--r-- 1 bheese bheese 5828 Dec 27 19:14 known_hosts

 

To be able to log in to remote systems using your pair of keys, you will first have to add your public key on the remote server to the authorized_keys2 file in the .ssh/ directory in your home directory on the remote machine. Once this is completed… Log into the machine with the account you created the authorized_keys2 for. You will not be prompted for a password. 

One reason for doing this is to allow for scripting across the network. Now you can create a script that can be run against a file that contains (or any input from STDOUT) a list of all machines you want the script to deploy on.

Resources:

Barrett, D. & Silverman, R., (2001, Feb), SSH – The Secure Shell: The Definitive Guide, Sebastopol, CA: O’Reilly Press

So last night I was trying to stand up a new replica against my OpenDirectory Master but it kept erroring out with a 1077 error. It was complaining about my credentials being incorrect. At first I though I must have fat fingered it… but after entering in the password one character at a time it still didn’t take. Looking through the slapconfig.log file (located in Library/Logs), I got the following error:


2009-02-09 22:08:02 +0800 - slapconfig -setmacosxodpolicy
2009-02-09 22:08:02 +0800 - slapconfig -createreplica
2009-02-09 22:08:02 +0800 - command: ssh root@192.168.171.10 /usr/sbin/slapconfig -checkmaster diradmin 0 4 4
2009-02-09 22:08:13 +0800 - ssh command failed with status 77
2009-02-09 22:08:13 +0800 - Error: Incorrect username or password. You must enter a directory domain administrator username and password.
(error = 77)


Everything was correct. I could ssh into the server using the root account. I could modify the directory (add/delete/modify accounts) using the diradmin account. But I still couldn’t bind the server. Turns out there is a bug that doesn’t allow you to bind the replica if the diradmin password contains anything but alpha-numerics. Change the password to something simple the replica binds without issue. So much for strong passwords!

One thing that every network administrator needs to keep in mind is without computers and end users there would be no need for your network. Why do I say this? Unfortunately over the years we’ve seen a proliferation of target attacks on companies that get perpetrated using the Internet. Money can be gotten by attacking corporate networks looking for credit card information and then selling the information for profit. In fact, the term Cyber-Warfare is no longer in the realm of science fiction. In May of 2007, Russia launched a DDOS attack against government and banking computers. The Estonian government says its state and commercial websites – including a number of banks – are being bombarded by mass requests for information – overwhelming their computer servers (bbc.uk.co, 2007).

So what are we to do? We do what man has done since the beginning of time. We build layer of defenses to thwart our attackers. We need to understand what (the data) we are trying to protect. We also need to understand what is considered normal so that when things become ‘odd’ we understand that something is not right. According to a 2005 survey conducted by the FBI, 87% of those polled have conducted security audits to serve as a baseline for a meaningful security program (fbi.gov, 2005). Baselines should be taken of end-users computers to make sure that virus and backdoors have not been infected. Servers for the same thing as well as which services are being run. Network traffic so that you have an understanding of how a healthy network should look like under normal conditions. Once baselines are completed, checks must be preformed at regular intervals to insure that no unauthorized changes have occurred. Unfortunately, in many organizations this is where things break down. In today’s economic climate, dollar and resources are scarce. Following up on procedures often take a back seat to more imminent problems of the daily break fix routine.

Once the baselines are established, rules can be entered into security device with a clear understanding of the trade-offs that will be required to secure your environment. Firewall rules can get very complicated. Many appliance-based devices try to make understanding your rules easier but others miss hitting the mark terribly. Simply put, firewall rules are a series of allow or deny statements. These statements contain criteria through which the firewall knows which to let the packet pass or stop it in its tracks. One important thing to keep in mind is whether the allow statement takes precedence over the deny statement or vice-versa. Different firewalls handle this very differently. Be sure you know how your firewall handles this otherwise you’ll find no packets getting through.

SO what do these rule look like?

So what does this all mean? This firewall is a deny/allow-based system. Let’s take a look at the rules one at a time:

Rule 1: Denies all access from everywhere to anywhere on the LAN. This is a pretty generic rule. It covers the network administrators it case they miss setting up an explicit rule for a service.

Rule 2: ALLOWS all users on the LAN to access any thing on the outside world. In other words LAN users can go anywhere.

Rule 3: Is an explicit rule. It stipulates that any one from the 129.33.82.0/24 network is DENIED access to ANY service even those allowed on this network.

Rule 4: Is an explicit rule that DENIES the computer using 192.168.1.55 from accessing FTP servers outside of the LAN. This rule is in effect during business hours, Monday thru Friday. (Seems this user might be abusing something).

Rule 5: Is an explicit rule that ALLOWS access to the SSH server outside of business hours. This is one way to help protect and minimize your exposure. Additionally, they cold have access an IP address to ALLOW access from thereby minimizing their exposure even more.

These rules are fairly simple and easy to follow. However in a true environment, they can get quite complex. In many corporations, firewalls are used as a means of restricting access for troublesome or abusive individuals. Unfortunately, this puts the network administrator in the role of having to deal with HR issues, rather than Human Resources dealing with the issue more directly.

Resources:

Unknown, (2005, July 25), Headline Archives, Retrieved Feb. 27, 2007 from

http://www.fbi.gov/page2/july05/cyber072505.htm

Unknown, (2007, May 17), Estonia hit by ‘Moscow cyber war’ Retrieved on January, 17, 2009 from http://news.bbc.co.uk/2/hi/europe/6665145.stm

Let’s say that you have to log into 20 or 30 machines per day. At the end of that day that can lead to a lot of keystrokes. I believe that I’m a focused individual but during the course of that day I can get interrupt may times over. Trying to remember exactly what I am access this host to do can be a challenge at times.

There are those that feel that using ssh keys is an unsafe practice (and it CAN be) if you don’t protect your host correctly. I have this implemented behind a gateway firewall and behind IPFW rules. This being the case a hacker would have to compromise the network and then the host itself. Is this a guarantee that a hacker can’t get to you? No, but it does make it somewhat more difficult to get at the machines.

So the first thing that I need to do is generate the keys that I am going to use.

ssh-keygen -t dsa

You can use other algorithms based on your comfort levels. See the man pages on ssh-keygen to see which flags are built into your version of ssh. You should see something very much like this:

mission-control:~ bheese$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/Users/bheese/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/bheese/.ssh/id_dsa.
Your public key has been saved in /Users/bheese/.ssh/id_dsa.pub.
The key fingerprint is:
52:d4:23:d5:91:b9:2e:0a:41:ac:6a:8d:c9:ee:9c:cc bheese@mission-control.randomdog.net

I did not put a passphase in as I want to be able to access the server using only my ssh keys! ls produces the following out in the .ssh directory.

mission-control:~/.ssh bheese$ ls -al
total 48
drwx------    7 bheese  bheese   238 Mar  2 18:58 .
drwxr-xr-x   30 bheese  bheese  1020 Feb 29 22:51 ..
-rw-------    1 bheese  bheese   672 Mar  2 18:58 id_dsa
-rw-r--r--    1 bheese  bheese   626 Mar  2 18:58 id_dsa.pub
-rw-r--r--    1 bheese  bheese  5828 Dec 27 19:14 known_hosts

To be able to log in to remote systems using your pair of keys, you will first have to add your public key on the remote server to the authorized_keys2 file in the .ssh/ directory in your home directory on the remote machine. Once this is completed… Log into the machine with the account you created the authorized_keys2 for. You will not be prompted for a password.

One of the reasons for doing this is to allow for scripting across the network. Now you can create a script that can be run against a file that contains (or any input from STDOUT) a list of all machines you want the script to deploy on.