- Introduction
With the increasing risks to business on the Internet growing each day, a
corporate Information Technology department must be aggressive. An All Hands
approach to security as well as the use of cryptography and another standards
are necessary to stay one step ahead of todays threats. Conservatism and apathy
towards security tools and protocols are flirting with danger. These attitudes
are the key ingredients that, when combined with vulnerabilities and business
create an explosive mixture that can result in downtime, wasted labor, and lost
revenue. While risk management and threat assessment are continuous attempts at
saving corporate dollars and spent labor on recovery from disaster, the ideals
of business continuity plans and security policies remain the same.
Enter into the picture the archaic method of plain text communication. In
comparison to such risks as social engineering, plain text communication is
often regarded as a much lighter threat and risk. Plain text communication and
authentication remains an easily solved problem. While cryptographic
connections can't completely solve the problem of compromised hosts due to
remote exploits and system misconfiguration, the implementation creates an
environment where it is more difficult to compromise systems by "man in the
middle" attacks and sniffed passwords.
In this document, we'll discuss several aspects of implementing a secure shell
system with OpenSSH. First, we'll look at why this transition is beneficial.
Next, we'll discuss the aspects of making the transition to a more secure
protocol from the corporate perspective. Another topic, and quite possibly the
most difficult to tackle, will be the transition to this infrastructure with the
user base. And finally, we'll look at the technical aspects of implementing
OpenSSH. With this criteria, we'll begin the journey down the road of slaying
the plain text beast.
The Benefits
Moving to a cryptographic protocol is beneficial to network security in a number
of ways. When a user remotely communicates with a system using a plain text
communication protocol such as telnet or http, the information is sent from the
client to the server in clear text, encapsulated in TCP/IP. The TCP/IP packets
are routed from the client to the server across the local network, or internet,
depending on the respective locations of both parties. In the process of
getting from the client to the server, the packets must traverse network where a
system could potentially intercept the traffic. Local networks are not immune
to traffic snooping.
After intercepting the traffic between the client and the server, decoding the
captured information is trivial. This allows a third party to discover more
about both the client, and the server. The crux is that this information could
yield anything. Web traffic, email, and remote logins can all fall prey to this
type of attack. From this traffic, user names, passwords, and other sensitive
information could be gathered.
Moving to cryptographic communication makes retrieving the content harder.
While cryptographic communication isn't immune to snooping, resources must be
invested in deciphering the content of the communication. With current
cryptographic algorithms available, this investment could be in the form of
years of decoding. Implementing this infrastructure makes it possible to
keep secret that information which could yield a user name or a password, thus
giving an intruder access to local resources,
The Corporate Transition
Implementing something new is never easy. There are multiple aspects of a
transition that have to be addressed. As with any corporate environment, big or
small, the first and most important part of the transition is acceptance by
management. Without consent, the effort is surely doomed.
Approaching management with an organized plan makes acceptance easier. A
document in the form of a draft outlining the reason for the transition, a plan
for the transition, a realistic estimate of the cost involved, the downtime
involved, support, maintenance, and a backup plan in the event of failure is
something to show management that there is both a need, and that solving the
need is attainable. Additionally, it gives management the comfort of knowing
that such a plan has been thought through and evaluated on the basis of its
merits and business needs.
Another consideration in the corporate environment is motivating the staff to
accept "the new way." Members of the staff may be conservative, apathetic
towards security, or reluctant to give up "the way it's always been." While it
is not simple to get everybody to accept a new idea, positively reinforcing the
reason for the transition and offering friendly support are two skills that will
likely make it a lot smoother. Bear in mind that even though you personally may
not be tasked with supporting the project, it is highly likely that if it's a
rocky one, it'll be a topic of discussion in the next management meeting.
Offering or scheduling training, holding a meeting, or sending out something as
simple as a company wide email with details and instructions are likely to break
the communication barrier and pave the road to smoother and faster acceptance.
The User Transition
A corporate transition can be difficult to say the least. Yet for each degree
of difficulty in corporate transition, an exponential degree of difficulty is to
be encountered with the user base. Change can create such consequences as
hostility, anger, and lost business if not approached delicately. It is for
this reason that we must pay special attention to the users, and make their
transition as easy and comfortable as possible.
One approach to making this transition easier is putting oneself in the shoes of
the user. Realizing what the benefits for your users makes it possible to speak
to the users about the positive aspects of changing their environment. Letting
a user know that this transition is being done for their security shows a
concern to them. Conveying concerns such as a protecting privacy, keeping
others from using their private account, and making it harder for others to
watch them while they carry out their business can offer a person not optimistic
about the transition a different perspective.
Making the transition simple is another means of ratifying approval amongst the
user base. Having free software readily available for the user base to download
and install fosters quicker adaptation. Additionally, having readily available
clear, concise, easy to read instructions for the download, installation,
configuration, and use of software packages can save users and support staff
alike volumes of time. Packages offered such as Teraterm Pro with SSH
capabilities (TTSSH), or PuTTY should be in a conspicuous, easily accessed place
such as a main page.
Using these simple ideas can make the transition both easy and acceptable.
While it's inevitable that at least one person will not be happy, an
understanding of the user and a gratification of the users needs will make the
transition bearable for all parties. With the necessary soft skills discussed,
let's look at the technical aspects necessary for this evolution.
Getting the sources
The first step in implementing OpenSSH is securing the necessary sources. To
build OpenSSH, there are three software packages that should be used. These
packages are used in this implementation, and are OpenSSL version 0.9.6,
OpenSSH version 2.2.1p4, and rsaref 2.0.
Building rsaref
Prior to installing rsaref, it's worth mentioning there was a vulnerability
found in the library last year. However, the rsaref library when used with
OpenSSL is not vulnerable, as can be seen in the securityfocus vulnerability
database here. In light of
this, we first begin with building rsaref from source. To do so, we execute the
following commands:
> mkdir rsaref
> tar xvzf rsaref.tar.Z -C rsaref
> cd rsaref/install
> cp unix/makefile makefile
From here, we have a makefile for rsaref that we can configure to optimize
compilation if we desire. We'll instead rely on the defaults, and continue.
> make
From here, we have a variety of files.
> ls
desc.o dos/ md5c.o r_dh.o r_random.o rsa.o
dhdemo* mac/ nn.o r_encode.o r_stdlib.o rsaref.a
dhdemo.o makefile output.ls r_enhanc.o rdemo* unix/
digit.o md2c.o prime.o r_keygen.o rdemo.o
Now, to position them in the appropriate places, and prepare the system for the installation of OpenSSL. We'll need superuser access to place them in the privileged directories.
> cp rsaref.a librsaref.a
> mv *.o *.a /usr/local/lib
> mv *demo /usr/local/bin
From here, we check /etc/ld.so.conf to ensure that /usr/local/lib is in the
library path. If not, we make an entry. We finish this section by running
ldconfig.
Now, we move on to OpenSSL.
Building OpenSSL
To install OpenSSL, it's necessary that we have Perl version 5 also. If this
isn't part of your distribution, or wasn't installed, installation of this
package should be done before proceeding. To begin the install, we decompress
and unarchive the source for OpenSSL, then begin the build process.
> tar xvzf openssl-0.9.6.tar.gz
> cd openssl-0.9.6
The build for OpenSSL is centered around the same pattern as all GNU packages.
We execute the config script, and pass the necessary options to the script to
compile the desired options. The INSTALL is worth reading for configuration
options. Of the options currently supported, for our implementation we want to
pass the rsaref option. This will compile support for the rsaref libraries
into OpenSSL.
> ./config rsaref
The next few steps are fairly straightforward, and standard.
> make
> make test
And as superuser:
> make install
Following the execution of make install, OpenSSL will install itself into
/usr/local/ssl. At this point, we'll need to add /usr/local/ssl/bin to the
default path, and enter /usr/local/ssl/lib into the /etc/ld.so.conf. The
completion of this evolution is running ldconfig to update the library cache,
and ensuring /usr/local/ssl/bin is in our path. Next, we build OpenSSH.
Building OpenSSH
Finally, we reach the last step in this process; the building of OpenSSH. From
this portion, we get the binaries necessary to make the secure shell
infrastructure work. Within the OpenSSH package, there is support for multiple
types of authentication and security protocols. pam is supported as is md5
passwords without pam. The INSTALL document details the various protocols
offered, and should be read for further information.
It's important to make use of the proper password authentication mechanisms.
The two commonly supported password authentication protocols used with the Linux
Operating System are pam and md5 hashes. Making sure to include support for the
authentication scheme used on your system will significantly increase your
chances of a working ssh daemon. Without support, logging into the system via
ssh is impossible.
We extract the OpenSSH source package, and cd into the tree. To begin the
compilation, we start off with the standard config.
> ./config --sysconfdir=/etc/ssh --with-md5-passwords
We specify the sysconfdir option to make the configuration files install into
the /etc/ssh directory. Doing this conforms to the example set by other
implementations, namely the commercial version of SSH. The with-md5-passwords
option supports the authentication scheme as implemented with Slackware. This
is not necessary with implementations such as Redhat that support pam.
Next, we start the build of the binaries.
> make
Once this completes, we need superuser access to install the binaries.
> make install
The installation will place the components of the OpenSSH package in the
/usr/local tree, with the exception of the configuration files, which will go to
/etc/ssh.
Configuring OpenSSH
The configuration files, as previously mentioned, are contained in the /etc/ssh
directory. From here, the attributes of ssh and sshd can be manipulated.
Within these configuration files things such as preferred encryption algorithm,
listening port and listening address, and version compatibility can be specified.
Looking in the /etc/ssh directory, we find the following files:
# ls -l
-rw-r--r-- 1 root root 974 Oct 2 03:46 ssh_config
-rw------- 1 root root 668 Oct 2 03:46 ssh_host_dsa_key
-rw-r--r-- 1 root root 603 Oct 2 03:46 ssh_host_dsa_key.pub
-rw------- 1 root root 528 Oct 2 03:46 ssh_host_key
-rw-r--r-- 1 root root 332 Oct 2 03:46 ssh_host_key.pub
-rw-r--r-- 1 root root 1171 Oct 2 03:46 sshd_config
The ssh_config is the client configuration file. The sshd_config is the daemon
configuration file. ssh_host_key and ssh_host_dsa_key are private keys.
ssh_host_key.pub and ssh_host_dsa_key.pub are public keys.
While sshd works out of the box, it may be desirable to configure some things. Recommended configuration changes are:
1. Increasing the ServerKeyBits to a minimum of 1024 bits. This provides
stronger cryptography.
2. In the event the machine has more than one interface, or restricted
interfaces, changing the ListenAddress variable to bind to one address.
3. Setting the LoginGraceTime variable to a much, much lower number. 60 seconds
should be perfectly fine on even the slowest networks. A maximum of 90 would be
the highest. While there is no substitute for access control infrastructure
such as firewalls and tcp wrapping, setting this configuration lower will shorten
the lifespan of processes in the event of a syn flood.
Key Management
As with any Public Key Infrastructure, there's the issue of key management and
creating a trust model. The IETF has discussed this in a draft document, and
can be referenced from the OpenSSH homepage. We'll not discuss this, as this is
outside of the scope of this document.
Conclusion
In this document, we talked about the aspects of eliminating clear text
authentication and communication. We explored the corporate side and user side
of implementation, and discussed likely aspects to be encountered, as well as
some tactics to handle them. We also discussed the technical side of
implementation, and walked through a build of OpenSSH.
In our next article, we'll go further in eliminating clear text communication by
looking at an implementation of secure mail.
