Avoiding Problems with Clear-Text Services
| Transmissions between your client machine and the server (in applications such as Telnet, email, and HTTP) might seem secure to you; after all, your passwords are hidden, and everything travels in tiny packets of data that flow out onto the network along with many millions of other tiny packets. Who could have the patience to apply the networking equivalent of a wiretap and piece together the fragments of an interesting transaction? They'd have to be on the same network segment as your LAN or the LAN at the opposite endor at some trunk service provider along the wayand they'd have to possess stealth and equipment befitting James Bond. And even if they did, they'd have to eavesdrop on many different such sessions in order to unearth anything they could use. Who could have that kind of spare time? Anybody, that's who. Security in clear-text services (applications that don't encrypt, or scramble, their transactions) is a myth. Even more importantly, security through obscuritythe notion that your communications or services are secure because you think nobody pays attention to themdoesn't work, as this myth has been proven wrong repeatedly over the years. Don't fall prey to the false notion that hackers aren't interested in cracking your system. You should always assume that your traffic is constantly being watched by a hacker with malicious intent. Using tcpdump to Monitor TrafficYou can illustrate the risks inherent in your network's clear-text services by using a packet sniffer, a software tool that watches all packets on your network segment and displays the ones that interest you. A sniffer operates by putting your Ethernet card into "promiscuous mode," where it accepts all packets that it sees on the network, rather than discarding packets not addressed to it (for information on packets, see Chapter 22, "Principles of TCP/IP Networking"). The sniffer then applies all kinds of highly configurable filters to the traffic it sees. This is how an eavesdropper can extract the relevant packets from the storm of traffic to capture a transaction with ominous ease. FreeBSD's built-in packet sniffer is tcpdump, available in /usr/sbin. Its use is barred to regular users, who get a Permission denied error on the /dev/bpf0 (Berkeley Packet Filter) device; only the administrator (root) can use the program. The purpose of tcpdump is not to log the actual data of the TCP/IP packets it sees (you might want to look into tcpflow, available in the ports at /usr/ports/net/tcpflow, or the GUI-based Ethereal, available at /usr/ports/net/ethereal, for that functionality). Instead, tcpdump is much like Crack in that it's intended as an administrative security-auditing tool that allows you to see how much unencrypted traffic is being sent to and from your system, and to watch for suspicious network activity that might indicate illicit pursuits on the part of your users. Note It's possible to use tcpdump to spy on the activities of your users, regardless of whether they're doing anything wrong. A warning in the GENERIC kernel configuration file reminds you to consider the ethical issues involved with using a packet sniffer. It all depends on what kind of system you're running, naturally, but packet sniffers are the equivalent of telephone wiretaps or hidden security cameras, and you should use tcpdump only under circumstances in which you would be comfortable using wiretaps and hidden cameras to gather information. The configuration of tcpdump is quite complex, and it allows you to do a lot of very useful and versatile things. All we're interested in right now, though, is demonstrating the dangers of clear-text TCP/IP traffic. Let's set up a simple monitoring filter on the Telnet port (TCP port 23):
The x option tells tcpdump to output the first part of each packet's payload in hexadecimal; if this option is omitted, tcpdump only outputs the link-level headers. You may want to use w "filename" to send tcpdump output into a file so that you can peruse it more easily. Because tcpdump is not designed as "spyware," it does not decode the hexadecimal output for you. You can, if you wish, convert it to plain human-readable text with a hex editor such as /usr/ports/editors/hexedit. However, if you're interested in the contents of the packets, you will want to use a different program (such as tcpflow or Ethereal). Adding Extra Security with Encrypted ProtocolsThe tcpdump data isn't encrypted at all. It only takes a little bit of effort to be able to see the complete contents of every packet sent via Telnet. It's even easier with tools that do the packet decoding for you, such as tcpflow, tcpshow, and Ethereal. If these packets contain a user's login session, an attacker using any of these programs would know the user's login password and could use it to log in to your system. This security gap endangers POP3, IMAP, FTP, and HTTP traffic, too, as well as just about every small and nonessential service, such as Finger and Syslog. Safeguarding against the use of these sniffer programs is especially important in systems where passwords or any other sensitive data is transferred. Protecting communications is as much a privacy issue as it is a security concern. Fortunately, there's a way to combat the problems of sniffer programs. You can use an encrypted alternative to any of the major data-transfer protocols, many of which are part of the default FreeBSD installation. For instance, SSH (Secure Shell) is a secure alternative to Telnet, and SSL (Secure Sockets Layer) is a method for encrypting web traffic, email, and other services. Sealing the security holes inherent in clear-text services is only a matter of knowing the encrypted versions exist, implementing them, and convincing your users to adopt them. |
net.telnet: S 1972342903:1972342903(0) win 32768 <mss 1460,nop,wscale 0,nop,nop,timestamp 