Global Information Assurance Certification Paper - GIAC Certifications
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Global Information Assurance Certification Paper
Copyright SANS Institute
Author Retains Full Rights
This paper is taken from the GIAC directory of certified professionals. Reposting is not permited without express written permission.
Interested in learning more?
Check out the list of upcoming events offering
"Security Essentials Bootcamp Style (Security 401)"
at http://www.giac.org/registration/gsecAn Introduction to SSH Secure Shell
Damian Zwamborn
GSEC Assignment v1.2d
Purpose
s.
ht
This paper is meant as an introduction to SSH Secure Shell with emphasis on the
latest version SSH2. When I was researching this paper, a lot of questions came to
rig
mind. I h ave tried to answer all those questions:
ull
• Background and licensing.
• The SSH1 and SSH2 protocol.
f
• How does SSH work?
ns
Key •fingerprint
Why SSH?= AF19
What FA27 2F94
are some 998D
typical FDB5threats
security DE3Dthat
F8B5SSH06E4 A169 4E46
deters?
tai
• Extended descriptions of SSH features.
re
• SSH Implementations.
• A few links to p opular clients.
or
• More helpful links.
th
Overview Au
SSH Secure Shell is a replacement for the Berkeley 'r' commands, telnet and ftp
2,
functionalities. Introduced in the BSD (Berkeley) version of UNIX, the 'r' commands
00
(rsh, rlogin, rcp) allow you to communicate w ith remote systems. Although they're
-2
not as extensive as ftp and telnet, the 'r' commands are useful tools for extending the
reach of your network.
00
SSH functions as a type of tunnel for encoding login procedures. All connections
20
between the local and the remote hosts are encrypted, protecting the dat a sent between
these machines. Secure shell provides s everal security improvements over the telnet,
te
ftp and rlogin protocols. In particular, passwords are never sent over the network in a
tu
clear text format as t hey are when using telnet, ftp or rlogin. This encryption makes it
sti
difficult for someone to breach the confidentiality of your data and/or compromise
passwords. SSH Secure Shell is based on the SSH2 protocol that is standardized by
In
IEFT in a draft form at ( www.ietf.org/ids.by.wg/secsh.html ).
NS
Secure Shell does not close all network security holes, but it is one step toward a more
SA
secure network.
SSH Secure Shell Background
©
SSH Secure Shell has been around since 1995 and is widely used in many Unix
systems all over the world. SSH was originally an academic project authored and
distributed by Tatu Ylonen of the University of Finland. SSH Secure Shell was
Key commercialized in 1998
fingerprint = AF19 by 2F94
FA27 SSH Communications
998D FDB5 DE3D Se curity
F8B5(www.ssh.com/
06E4 A169 4E46 ), which
sells implementations for both Windows and UNIX systems.
The SSH1 and SSH2 protocol
© SANS Institute 2000 - 2002 As part of GIAC practical repository. Author retains full rights.As of 1 May 2001, SSH Secure Shell 1.x is no longer available from the SSH
Communications Security site. SSH1 has many security flaws and the SSH2 protocol
adds additional security, If fact, SSH2 is a complete rewrite of the SSH protocol. SSH
Communications Security has stated: “SSH1 (Secure Shell 1) was designed in 1995 ...
it [has] became apparent that the re were inherent security flaws in SSH1. These flaws
s.
include a weak hash and sus ceptible encryption algorithms. These flaws fall in the
ht
following categories: access control and authentication, data integrity, confidentiality,
and connection redirection” (R ef 1).
rig
A summary of vulnerabilities in the SSH1 protocol can be found at the CERT
ull
Coordination Center: www.kb.cert.org/vuls .
f
ns
For the sake of clarity, this paper refers to the SSH2 protocol unless explicitly st ated
Key otherwise.
fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
tai
re
Licensing
or
The SSH Communications Security FTP site offers downloadable source code and
binaries (UNIX platforms and Windows) for both SSH1 and SSH2. However, the
th
licensing terms allow only SSH1 to be used without restriction. Commercial
Au
enterprises must license SSH2 products on a per -seat basis.
2,
Open Source implementation of SSH
00
There is also an Open Source implementation of SSH, available from OpenSSH
-2
(www.openssh.com/ ). This implementation suppo rts both the ssh1 and ssh2 protocols
and has no restrictions on its use. The Open Source implementation is largely
00
compatible with the commercial version, differing mainly in not providing support for
20
IDEA encryption because of patent restrictions.
te
The FreeSSH (www.freessh.org/ ) site maintains up -to-date links on various free and
tu
Open Source SSH implementations as well as commercial enterprise
implementations.
sti
In
How does SSH work?
NS
The SSH2 login procedure can be ill ustrated in the following client/server model.
SA
Note: SSH1 uses server and host keys to authenticate systems where SSH2 only uses
host keys. A server key (768 bit) is generated every hour by default and is not saved
©
in a file. The server key ensures the en coded data can no longer be decoded once the
server key, after an hour, has been regenerated (in the case that the private host key is
ever compromised).
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
© SANS Institute 2000 - 2002 As part of GIAC practical repository. Author retains full rights.s.
ht
rig
f ull
ns
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
tai
re
or
th
Au
1. The client makes a connection to a server.
2,
2. The server identifies itself with it's public host key . The key length is 1024 bit
00
RSA or DSA. The client looks in its local database to verify the public host
key is authentic/known. An unknown key is added to the database or the
-2
session can be broken. If the client determines the host key does not belong to
the server the client is alerted (SSH generates a warning).
00
20
3. The client then generates a random 256 -bit number and chooses an encryption
algorithm (eg. 3DES). The random number is then encoded with RSA or DSA.
te
Pure RSA/DSA authentication never trusts anyt hing but the private key. The
tu
encoded key is then sent to the server. The host key ensures the authentication
sti
of the particular server.
In
4. The server decodes the RSA/DSA encryption and reconstructs the session key.
Furthermore, the server sends the client, v ia the encoded s ession key, a
NS
confirmation. The rest of the session is encrypted using a symmetric cipher.
SA
5. The client then sends a username authentication request. The server replies
with a success or failure.
©
Security Threats
TCP/IP was not designed wi th security in mind. That is why it is important to
implement security techniques such as SSH Secure Shell.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
A quick review of some valuable terms:
• Packet sniffing: A packet sniffer is a utility that sniffs raw packet data without
manipulating the data. P acket sniffers observe, display, and log traffic. A powerful
© SANS Institute 2000 - 2002 As part of GIAC practical repository. Author retains full rights.aspect of packet sniffers is their ability to place the network adapter machine
hosting the sniffing software into promiscuous mode. Network adapters running in
promiscuous mode receive not only the data directed to the host's machine but also
all of the traffic on the physically connected local network. Malicious hackers use
packet sniffers gathering information.
• Spoofing: Spoofing is the creation of TCP/IP packets using somebody else's IP
s.
ht
address. Routers use the destination IP address in order to forward packets through
the Internet, but ignore the source IP address. The destination machine only uses
rig
that address when it responds back to the source.
ull
SSH connections are encrypted, protecting the data sent between machines. This
f
encryption makes it difficult for someone to breach the confidentiality of your data
ns
and/or compromise your passwords. Typical attacks that SSH protects against are:
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
tai
• Trojan horses: Trojans are programs that masquerade as normal programs on an
re
unsuspecting host but instead contain code designed to break into a system. SSH
authentication happens on both ends of a connection and therefore, for practical
or
purposes, eliminating unauthorized connections.
• DNS spoofing. “DNS spoofi ng is a term used when a DNS server accepts and
th
uses incorrect information from a host that has no authority giving that
Au
information. DNS spoofing is in fact malicious cache poisoning where forged data
is placed in the cache of the name servers. Spoofing a ttacks can caus e serious
2,
security problems for DNS servers vulnerable to such attacks, for example causing
00
users to be directed to wrong Internet sites or e -m ail being routed to non -
authorized mail servers” (Ref 2). Follow reference link for detailed expla nation.
-2
DNS is vulnerable to spoofing because of the absence of authentication.
• Man-in-the-middle attack. A man -in-the-m iddle attack “is one in which the
00
attacker intercepts messages in a public key exchange and then retransmits them,
20
substituting their ow n public key for the requested one, so that the two original
parties still appear to be communicating with each other directly. The attacker uses
te
a program that appears to be the server to the client and appears to be the client to
tu
the server” ( www.whatis.com/ ). A well-known tool for this is dsniff
sti
(www.monkey.org/~dugsong/dsniff ). Since most authentications only occur at the
start of a TCP session, this allows th e hacker to gain access to a machine.
In
SSH offers the following solution to prevent public key substitution: “SSH2
NS
automatically maintains and checks a database containing public keys of hosts.
When logging on to a host for the first time, the host's publi c key is stored to a file
SA
in the us er's personal directory. If a host's identification changes, SSH2 issues a
warning and disables password”(Ref 3).
©
A note regarding SSH1 and man -in-the-middle attacks:
The protocol [SSH1] provides the option that the ser ver name - host key
association is not checked when connecting the host for the first time. This
Key fingerprintallows
= AF19 FA27 2F94 998D
communication FDB5
without prior DE3D F8B5 06E4
communication A169
of host keys4E46
or
certification. The connection still provides protection against passive
listening; however, it becomes vulnerable to active m an -in-the-m iddle
attacks. Implementations SHOULD NOT normally allow such connections
by default, as they pose a potential security problem. However, as there is
© SANS Institute 2000 - 2002 As part of GIAC practical repository. Author retains full rights.no widely deployed key infrastructure available on the Internet yet, this
option makes the protocol much more usable during the trans ition time
until such an infrastructure emerges, while still providing a much higher
level of security than that offered by older solutions (e.g. telnet and rlogin)
(Ref 4).
s.
ht
Features and Specifications
rig
Authentication methods.
• Host-based authentication: password protection with 1024 bit RSA -key (public-
ull
key cryptographic algorithm).
• Ability to add certificate and public key authentication.
f
• Password authentication.
ns
Key •fingerprint = AF19
Public key FA27
algorithm 2F94
supp ort:998D FDB5
DSA and DE3D
Diffie F8B5key
-Hellman 06E4 A169 4E46
exchange.
tai
• PGP key support.
re
Data encryption for confidentiality and integr ity.
or
• Encryption algorithms: DES, 3DES Blowfish, Twofish, Arcfour, CAST128 -CBC,
th
128 bit AES, or 256 bit AES.
• Hash Algorithms: MD5 and SHA1. Au
Additional functionality.
2,
• File transfer. Files can be copied remotely using a utility called scp (secure copy).
00
• SFTP (secure file transfer protocol) was introduced with SSH2. It is independent
-2
to the rest of the SSH2 protocol suite (see www.ietf.org/ids.by.wg/secsh.html ).
SFTP-server is not called directly but through the SSH2 daemon – the ssh2
00
protocol therefore secures the connection.
• TCP/IP port forwarding: SSH supports port forwarding over a secure tunnel. You
20
configure your SSH client to accept connections on the local machine for certain
ports. Any data that is sent to these ports is then forwarded and returned across the
te
tunnel. On the other side of the tunnel, the SSH server passes the data back and
tu
forth to a server you wish to access. Typical implementations of port forwarding
sti
are services that have no encryption of their own built -in such as FTP, IMAP,
SMTP and POP3. Note: only root can redirect privileged ports.
In
• X11 connections for secure X Window Sy stem sessions are a popular
NS
implementation. SSH Communications Security offers special support for this
feature because it so popular. SSH creates a fake X server (Fake Xauthority
SA
information) on the same machine that the SSH client is run. SSH then functi ons
as a go-between between the connection and forwards it to a real X server over a
©
secure connection.
• TCP Wrapper support. The TCP Wrappers is a public -domain tool/package you
can monitor and filter incoming requests for the SYSTAT, FINGER, FTP,
TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other s ervices. It is us ed to
restrict inbound network access to the s ervices defined in the /etc/inetd/inetd.conf
Key fingerprint
file. TCP=Wrappers
AF19 FA27 2F94 998D
is controlled FDB5
by two DE3D F8B5
configuration files:06E4 A169 4E46and
/etc/hosts.allow
/etc/hosts.deny. If they do not exist or are empty, TCP Wrappers will allow all
hosts to access all services.
• Built-in SOCKS 4 and 5 support for traversing firewalls.
© SANS Institute 2000 - 2002 As part of GIAC practical repository. Author retains full rights.• Support for SSH1 fallback functionality. The SSH1 and SSH2 protocols are not
compatible. SSH1 clients cannot conn ect to a SSH2 daemon. The SSH2 daemon
can be configured to start up a SSH1 daemon for a SSH1 client. (Must be installed
with compatible option). The SSH1 and SSH2 daemon can be running on two
separate machines or on the same machine.
• Multiple channel suppo rt. “All terminal sessions, forwarded connections, etc. are
s.
ht
channels. Either side may open a channel. Multiple channels are multiplexed into
a single connection” (Ref 5).
rig
• Distributed key management. The advantage of distributed key management is
that there is no hierarchy. This avoids having a single target for attacks as every
ull
machine can hold it’s own keys. It is also possible to configure these machines to
f
change session keys every hour.
ns
Key SSH
fingerprint = AF19 FA27
Implementations . 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
tai
re
The SSH2 protocol can be implem ented in vari ous ways. In addition to encrypted
terminal connections the SSH protocol can be implemented, for example, as a
or
complete VPN solution. At the risk of going beyond the scope of this paper, I
th
recommend going to www.ssh.com/products , and www.f-secure.com/products , to get
an idea of popular implementations/solutions.
Au
Popular Clients
2,
00
SSH Communications Security. URL: www.ssh.com .
F-Secure. URL: www.f-secure.com . In the past, SSH Communications Security did
-2
not sell Secure Shell but were licensing it through F -Secure. F-Secure still licenses the
UNIX server but both companies now develop their own clients.
00
Van Dyke Technologies. URL: www.vandyke.com .
20
Open SSH. URL: www.openssh.com .
For a complete list of free and licensed clients, visit the www.freessh.org website.
te
tu
References (Ref):
sti
1. SSH Communications Security. “ SSH1 vulnerabilities ”.
In
http://www.ssh.com/products/ssh/cert/vulnerability .html (12 May, 2001).
2. M EN&MICE. “What is DNS Spoofing?” IWS - The Information Warfare Site.
NS
URL: http://www.iwar.org.uk/comsec/resources/dns/DNS_spoofing.htm (12 May
2001).
SA
3. SSH Communications Security. “SSH2 Functionality”. SSH Secure Shell for
Workstations Windows Client: User M anual. URL:
©
http://www.ssh.com/products/ssh/winhelp21/8_1_SSH 2_Functionality.html (12 May
2001).
4. Network Working Group. “SSH Protocol Architecture”. Internet -Drafts IETF.
URL: http://www.ssh.com/tech/archive/secsh/architecture.t xt (12 May, 2 001).
5. Network Working Group. “SSH Connection Protocol”. Internet-Drafts IETF. URL:
Key http://www.ssh.com/tech/archive/secsh/connect.txt
fingerprint = AF19 FA27 2F94 998D FDB5 DE3D (12F8B5
M ay, 06E4
2001).A169 4E46
Extra references:
• RSA Security. URL : www.rsa.com .
© SANS Institute 2000 - 2002 As part of GIAC practical repository. Author retains full rights.• The Official Secure Shell FAQ. URL: www.employees.org/~satch/ssh/faq .
• Indiana University security resource page.
URL: www.uwsg.iu.edu/security/ssh.html .
• Colorado School of Mines Secure Shell resource page.
URL: www.mines.edu/Academic/computer/security/tools/ssh/#ab out.
s.
• Crawford, Chuck. “ SSH, Secure Shell ”. Nov 3 2000.
ht
URL: www.sans.org/infosecFAQ/authentic/SSH.htm .
rig
Additional Security Alerts of Interest
ull
• Openwall advisories. “Passive Analysis of SSH (Secure Shell) Traffic.
f
Determining possible password lengths”. Mar 19, 2001.
ns
URL: www.openwall.com/advisor ies/OW -003-ssh-traffic-analysis.t xt.
Key •fingerprint = AF19 FA27 2F94 998D Testing
FDB5 DE3D F8B5.06E4 A169
2001.4E46
tai
Russel, Christopher R. “Penetration with dsniff” Feb 18, URL:
www.sans.org/infosecFAQ/threats/dsniff.htm .
re
• CORE SDI S.A. Security Advisor y. “SSH protocol 1.5 session key recovery
vulnerability”. Feb 7th, 2001.
or
URL: www.core-sdi.com/advisories/ssh1_sessionkey_recovery.htm .
th
• Arce, Iván. “ SSH1 CRC-32 compensation attack detector vulnerability”. Feb 08
Au
2001. URL: www.securityfocus.com/archive/1/161448 .
2,
00
-2
00
20
te
tu
sti
In
NS
SA
©
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
© SANS Institute 2000 - 2002 As part of GIAC practical repository. Author retains full rights.Last Updated: May 28th, 2019
Upcoming Training
Mentor Session @work - SEC401 Birmingham, AL Jun 03, 2019 - Jul 08, 2019 Mentor
SANS Kansas City 2019 Kansas City, MO Jun 10, 2019 - Jun 15, 2019 Live Event
SANSFIRE 2019 Washington, DC Jun 15, 2019 - Jun 22, 2019 Live Event
SANSFIRE 2019 - SEC401: Security Essentials Bootcamp Style Washington, DC Jun 17, 2019 - Jun 22, 2019 vLive
SANS Cyber Defence Canberra 2019 Canberra, Australia Jun 24, 2019 - Jul 13, 2019 Live Event
SANS Cyber Defence Japan 2019 Tokyo, Japan Jul 01, 2019 - Jul 13, 2019 Live Event
Community SANS Ottawa SEC401 Ottawa, ON Jul 08, 2019 - Jul 13, 2019 Community SANS
Community SANS Philadelphia SEC401 Philadelphia, PA Jul 08, 2019 - Jul 13, 2019 Community SANS
SANS London July 2019 London, United Jul 08, 2019 - Jul 13, 2019 Live Event
Kingdom
Pittsburgh 2019 - SEC401: Security Essentials Bootcamp Style Pittsburgh, PA Jul 08, 2019 - Jul 13, 2019 vLive
SANS Pittsburgh 2019 Pittsburgh, PA Jul 08, 2019 - Jul 13, 2019 Live Event
SANS Cyber Defence Singapore 2019 Singapore, Singapore Jul 08, 2019 - Jul 20, 2019 Live Event
SANS Charlotte 2019 Charlotte, NC Jul 08, 2019 - Jul 13, 2019 Live Event
SANS Columbia 2019 Columbia, MD Jul 15, 2019 - Jul 20, 2019 Live Event
SANS Rocky Mountain 2019 Denver, CO Jul 15, 2019 - Jul 20, 2019 Live Event
SANS San Francisco Summer 2019 San Francisco, CA Jul 22, 2019 - Jul 27, 2019 Live Event
Mentor Session - SEC401 Seattle, WA Jul 25, 2019 - Aug 29, 2019 Mentor
SANS Boston Summer 2019 Boston, MA Jul 29, 2019 - Aug 03, 2019 Live Event
SANS London August 2019 London, United Aug 05, 2019 - Aug 10, 2019 Live Event
Kingdom
SANS Crystal City 2019 Arlington, VA Aug 05, 2019 - Aug 10, 2019 Live Event
SANS Melbourne 2019 Melbourne, Australia Aug 05, 2019 - Aug 10, 2019 Live Event
Community SANS Raleigh SEC401 Raleigh, NC Aug 12, 2019 - Aug 17, 2019 Community SANS
SANS Minneapolis 2019 Minneapolis, MN Aug 12, 2019 - Aug 17, 2019 Live Event
Minneapolis 2019 - SEC401: Security Essentials Bootcamp Style Minneapolis, MN Aug 12, 2019 - Aug 17, 2019 vLive
SANS San Jose 2019 San Jose, CA Aug 12, 2019 - Aug 17, 2019 Live Event
SANS Virginia Beach 2019 Virginia Beach, VA Aug 19, 2019 - Aug 30, 2019 Live Event
SANS Chicago 2019 Chicago, IL Aug 19, 2019 - Aug 24, 2019 Live Event
SANS New York City 2019 New York, NY Aug 25, 2019 - Aug 30, 2019 Live Event
SANS Tampa-Clearwater 2019 Clearwater, FL Aug 25, 2019 - Aug 30, 2019 Live Event
SANS Copenhagen August 2019 Copenhagen, Denmark Aug 26, 2019 - Aug 31, 2019 Live Event
SANS Canberra Spring 2019 Canberra, Australia Sep 02, 2019 - Sep 21, 2019 Live EventYou can also read
