The Illustrated Network- P67

Chia sẻ: Cong Thanh | Ngày: | Loại File: PDF | Số trang:10

Thêm vào BST

Báo xấu

49
lượt xem 4
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

The Illustrated Network- P67:In this chapter, you will learn about the protocol stack used on the global public Internet and how these protocols have been evolving in today’s world. We’ll review some key basic defi nitions and see the network used to illustrate all of the examples in this book, as well as the packet content, the role that hosts and routers play on the network, and how graphic user and command line interfaces (GUI and CLI, respectively) both are used to interact with devices.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: The Illustrated Network- P67

629 QUESTIONS FOR READERS Figure 24.8 shows some of the concepts discussed in this chapter and can be used to answer the following questions. FIGURE 24.8 Ethereal capture of an SNMP response message. Note the object identiﬁers. 1. Which version of SNMP is used here? 2. Which router IP address and port are responding? 3. Express the SMI tree to the sysDescr group in English instead of numbers. It starts with “iso.org...” 4. The actual time ticks value of 1209176765 is interpreted. What does this value represent? 5. Where is the response telling the management application to go for more device-speciﬁc information?
PART Security VI Security is a major concern in networking today. This part of the book continues the theme begun with SSL, and explores the basic aspects of security used on the Internet today. ■ Chapter 25—Secure Shell (Remote Access) ■ Chapter 26—MPLS-Based Virtual Private Networks ■ Chapter 27—Network Address Translation ■ Chapter 28—Firewalls ■ Chapter 29—IP Security
CHAPTER Secure Shell (Remote Access) 25 What You Will Learn In this chapter, you will learn how the secure shell (SSH) is used as a more secure method of remote access than Telnet. We’ll talk about the SSH model, features, and architectures. You will learn how the SSH protocols operate and how keys are distributed. We’ll do a simple example of Difﬁe-Hellman key distribution using only a pocket calculator and no advanced mathematics. Not too long ago, most TCP/IP books would routinely cover Telnet as the Internet application for remote access. But today, with the focus on security the Telnet daemon is considered just too dangerous to leave running on hosts and routers, mainly because it is such a tempting target even when password encryption is mandated. There are ways to “enhance” Telnet with security mechanisms, much as the control connection used for FTP (which is little more than a Telnet session) has done. This is not to say that remote access itself is not an essential Internet and TCP/IP tool. This book could not have been written without Telnet remote access. But more and more today, the preferred application for remote access is SSH. Windows users should not let the use of the Unix term “shell” scare them. SSH is not really a Unix shell, such as the Bourne shell or other Unix interfaces. It’s really a protocol that runs, like most things, over IPv4 or IPv6.Yet the use of the word “shell” in SSH is a good one because there is a lot more to SSH than just remote access. Perhaps the term “secure suite” would have been better, but SSH is what it is. USING SSH Most people know SSH as just another way to access the remote host of a router. For example, to access router CE0 from host bsdclient and log in as admin, we would use the –l option as follows:
634 PART VI Security bsdclient lnxserver wincli1 winsvr1 eth0: 10.10.11.66 LAN2: 10.10.11.51 LAN2: 10.10.11.111 SSH client MAC: 00:d0:b7:1f:fe:e6 MAC: 00:0e:0c:3b:88:3c MAC: 00:0e:0c:3b:87:36 to access (Intel_1f:fe:e6) (Intel_3b:88:3c) (Intel_3b:87:36) IPv6: fe80::2d0: IPv6: fe80::20e: IPv6: fe80::20e: router CEO b7ff:fe1f:fee6 cff:fe3b:883c cff:fe3b:8736 Ethernet LAN Switch with Twisted-Pair Wiring Los Angeles LAN1 Office fe-1/3/0: 10.10.11.1 SSH Server for CE0 MAC: 00:05:85:88:cc:db Remote Access lo0: 192.168.0.1 (Juniper_88:cc:db) IPv6: fe80:205:85ff:fe88:ccdb 50. /3 0/0 2 ge- Ace ISP Wireless in Home P9 so-0/0/1 0 lo0: 192.168.9.1 79.2 /0/ -0 DS so 9.2 so- 0/0 50. /3 LL 5 so-0/0/3 29. /2 0/0 ink 1 2 ge- 49.2 0 /0/ -0 .1 so PE5 59 lo0: 192.168.5.1 so -0 45 /0/2 .2 so-0/0/3 /0 so 0/0 -0 49.1 so- 45 /0/ 2 4 7.1 .1 P4 so-0/0/1 lo0: 192.168.4.1 24.2 Solid rules SONET/SDH Dashed rules Gig Ethernet Note: All links use 10.0.x.y addressing...only the last AS 65459 two octets are shown. FIGURE 25.1 Using SSH on the Illustrated Network showing the host used as the SSH client and the target router used as the SSH server for remote access.
CHAPTER 25 Secure Shell (Remote Access) 635 bsdserver lnxclient winsvr2 wincli2 eth0: 10.10.12.77 eth0: 10.10.12.166 LAN2: 10.10.12.52 LAN2: 10.10.12.222 MAC: 00:0e:0c:3b:87:32 MAC: 00:b0:d0:45:34:64 MAC: 00:0e:0c:3b:88:56 MAC: 00:02:b3:27:fa:8c (Intel_3b:87:32) (Dell_45:34:64) (Intel_3b:88:56) IPv6: fe80::20e: IPv6: fe80::2b0: IPv6: fe80::20e: IPv6: fe80::202: cff:fe3b:8732 d0ff:fe45:3464 cff:fe3b:8856 b3ff:fe27:fa8c Ethernet LAN Switch with Twisted-Pair Wiring LAN2 fe-1/3/0: 10.10.12.1 New York CE6 MAC: 0:05:85:8b:bc:db Office lo0: 192.168.6.1 (Juniper_8b:bc:db) IPv6: fe80:205:85ff:fe8b:bcdb ge- .2 0/0 16 /3 Best ISP so-0/0/1 P7 lo0: 192.168.7.1 so 79.1 -0 / 17 0/2 .2 ge- /0 0/0 so-0/0/3 0/0 so- 16. 2 47. /3 27.2 1 so -0 / 17 0/2 .1 PE1 0 lo0: 192.168.1.1 /0/ -0 so 2.1 1 so- so-0/0/3 0/ 29. 0/2 27.1 0 1 /0/ -0 so 2.2 so-0/0/1 P2 1 24.1 lo0: 192.168.2.1 Global Public Internet AS 65127
636 PART VI Security bsdclient# ssh -l admin 10.10.11.1 admin@10.10.11.1's password: (not shown) --- JUNOS 8.4R1.3 built 2007-08-06 06:58:15 UTC admin@CE0> You might notice a longer wait after issuing the ssh command than other commands before being asked for the password, but if the network is fast enough this delay is mar- ginal. In fact, a blizzard of messaging is crisscrossing the network between command and password requests, and even more before the remote device prompt appears.With- out some explanation, these messages are completely opaque to users. So, let’s use bsdclient and CE0 (as shown in Figure 25.1) to explore SSH a little before looking at the messages in detail. SSH Basics Although not technically a shell, SSH lets a user do all of the things Unix commands such as rsh, rlogin, and rcp do. (SSH is sometimes implemented as slogin.) SSH is an application that allows users to log on to another host over the network, execute com- mands on the remote host, and move ﬁles around. But unlike the older “r commands” it is intended to replace, SSH provides secure communication over unsecure channels, strong authentication and encryption, and other security features. The “r commands” were vulnerable to many different types of attacks. Anyone with- out root access to the hosts or access to the packets on the network can gain unau- thorized access to the hosts in several ways. Malicious users can also log all trafﬁc to and from the host, including other users’ passwords. (In contrast, SSH never sends passwords in clear text.) The popular X Windows GUI for Unix is also vulnerable in many ways. SSH allows the creation of secure remote X Windows sessions that are transparent to the user. In fact, using SSH for remote X Window clients is easier for users. Users can still use their old rhosts and /etc/hosts ﬁles for this type of remote access, and if a remote host does not support SSH there is a way for the session to fall back to rsh. SSH is a traditional client/server protocol. The SSH server process waits for com- mands (requests) from SSH clients, executes the command if allowed, and returns the result (reply) to the client. Users are often authenticated with an encrypted key and passphrase instead of a password, and these public key ﬁles are placed on the remote computers users can access. The overall use of SSH is shown in Figure 25.2. SSH consists of several client programs and a few conﬁguration ﬁles. The programs the user runs are ssh or slogin (both essentially the same) and scp or sftp (also the same), depending on implementation. Secure shell keys are managed with ssh-keygen, ssh-agent, and ssh-add. There have been two major versions of SSH. SSH1 was developed by Tatu Ylonen at the Helsinki University of Technology in Finland in 1995 after a network attack. It was released as free software and source code. It also became an Internet draft, but several
CHAPTER 25 Secure Shell (Remote Access) 637 SSH Client Log-in Access request denied! Log-in request Copy file SSH SSH SSH Client Server Client Success! File Run Command command output SSH Client FIGURE 25.2 SSH model. Note that a way to run commands and copy ﬁles is included in the model. issues with the original (which was not systematically developed) were addressed as SSH2 in 1996. SSH2 has new methods and is not compatible with SSH1. Unfortunately, users still liked a lot of the features of SSH1 that were lacking in SSH2, and because some security is better than none, they felt little reason to switch (licensing played a role as well). OpenSSH is now available as a free implementation of the SSH2 protocol, and it is this version that has been ported to many operating systems. People still talk about the “Ylonen SSH,”“SSH1.5,” or “OpenSSH” implementations of the basic SSH protocol. SSH was an Internet draft status for a long time, and this chapter describes SSH2. SSH is now deﬁned in a series of RFFCs from RFC 4250 through RFC 4256. This group of RFCs details various aspects of SSH operation. SSH Features SSH has excellent protection features. The major ones follow: Secure client/server communication—All data are encrypted on the network. Varied authentication—Users can be authenticated by password (encrypted), the host, or a public key.
638 PART VI Security Authentication integration—SSH can be optionally integrated (and often is) with other authentication systems such as Kerberos, PAM, PGP, and SecureID. Security add-on—SSH can be used to add security to applications such as NNTP, Telnet, VNC, and a lot of other TCP/IP protocols and applications. Transparency and versatility—SSH can be transparent to the user and there are implementations for almost all operating systems (including Windows with OpenSSH implementations). SSH protects users against: IP spoofing—A remote host can send IP packets pretending to come from some- where else, such as a trusted host. Spoofers on LANs can even pretend to be the local routers to the outside world, which SSH protects against as well. IP source routing—This is another way for hackers to claim that a packet came from another host. DNS spoofing—Hackers can forge name server records supplied to a host. Intermediate device control—This is an old favorite. A hacker can take control of a router or host between hosts and execute many types of data manipulation. Clear text interception—Data or passwords sent in clear text are always targets for hackers. X Windows attacks—Hackers can listen to X Windows authentication exchanges and spoof server connections. SSH never trusts the network. Even if hackers took over the entire network, all that can happen is that SSH is forced to disconnect. Hackers cannot decrypt, play back, or compromise data on the connection. This is not to say that the SSH is perfect. Like any other tool, SSH is only as good as those setting it up and using it. For example, SSH does have an option for encryption type (none), but this is only to be used for testing purposes. (There is no real enforce- ment of this, of course.) And SSH does nothing to prevent someone who had gained access to the host another way (perhaps by sitting down in front of the unprotected host itself) from doing a lot of damage with root access. In that case, SSH is often the ﬁrst target of a local hacker. In addition, a lot of organizations with their own ﬁrewall devices are nervous when users rely on SSH to connect to hosts. Remember, everything in the SSH stream is encrypted, and fairly well at that. What SSH does is offer users a direct pipeline to their internal machines right through the ﬁrewall, an invisible tunnel into the organization. There are ways to work around this through a SSH proxy gateway, including the “mute shell” and “SSH-in-SSH” approaches. But nothing is ever perfect or 100% secure.