8.9.1 talk

talk is a text-based real-time two-person conferencing system; it allows two people to establish a "chat" session with each other. Each of their screens gets split into two sections; what one person types appears in one section; what the other person types appears in the other section.

talk is very convoluted in that it uses UDP to negotiate the connections between the two sites and then uses TCP to actually move the data back and forth between the participants. UDP is used between the calling client and the answering server, and again between the answering client and the calling server; TCP is then used between the two clients.

To further complicate matters, there are two incompatible versions of the talk protocol, commonly referred to as either talk and ntalk (for "new talk") or otalk (for "old talk") and talk , depending on who you ask. The earlier version depended on bytes being in a certain order in memory, and basically worked only between machines of the same CPU type. The later version fixes this problem, but is incompatible with the earlier version.

The calling client contacts the answering server via UDP to announce the call. The answering server tells the user being called that someone is requesting a talk session and how he should respond if he wishes to accept the call. While waiting for the user to respond, the calling client also contacts the calling server to say that it's expecting an incoming call and to specify what TCP port it wishes to use for that call (somewhat like calling your secretary to say that you're expecting a call back from someone, and that it should be put through to the extension you're currently at). When the answering user accepts, that user's client (the answering client) contacts the calling server via UDP to find out what port the calling client is waiting on; the answering client then contacts the calling client on that TCP port. Figure 8.11 shows how talk works.

Figure 8.11: How talk works

Because of the incompatible talk protocols, talk fails relatively often even between sites that do no packet filtering, or between machines of different types within the same site. talk clients and servers are generally provided only on UNIX machines.

8.9.2 Internet Relay Chat ( IRC )

IRC is a multiuser text-based real-time conferencing system. Users run IRC client programs to connect to IRC servers. IRC servers are arranged in a spanning tree, and talk to each other to pass messages to all of the clients. Figure 8.12 shows how the IRC servers are connected. Clients might connect to any of these servers.

Most of the security problems with IRC are related to who uses it and how, not to the protocol per se. As we mentioned in Chapter 2 , many clients allow servers far more access to local resources (files, processes, programs, etc.) than they should, and a malicious server can wreak havoc with a weak or poorly configured client. Further, some of the frequent users of IRC have a nasty habit of persuading new users to naively run commands which those users think will do neat things on their systems, but which instead trash these systems.

Many well-intentioned IRC users are simply naive about security. For example, they think it's really neat to distribute software by putting up a little server on their machine, and advising people to "telnet myhost myport | sh" to have the software installed for them, which allows external users to install the software without interaction from the user, but would also let them run any command whatsoever on the internal user's host as that user. It's close to impossible to distinguish hostile people from naive ones, and users should be advised to never issue any command, in or out of their IRC client, just because somebody advised them to over IRC .

Although these problems are widespread on IRC , IRC is also a useful and popular way for people to talk to each other. Text-based, multiuser, real-time communication can be handy; it has many of the advantages of teleconferencing for a much lower price tag.

You should be able to safely run an IRC server in a restricted ( chroot 'ed) environment on a bastion host, but it would be somewhat bizarre to run a server without having any local clients that could access it, and a server that could access the Internet would probably not be safe for clients to talk to. You may want to run one inside your firewall for private IRC conferencing.

Many IRC clients support something called Direct Client Connections ( DCC ). DCC allows two IRC clients to negotiate and establish a direct TCP connection between themselves, bypassing all the servers except for the initial negotiation. Figure 8.12 depicts the IRC server tree.

Figure 8.12: IRC server tree

8.9.3 The Multicast Backbone ( MBONE )

Most network technologies provide a way for a sending station to address a message to a particular receiving station: this is called unicasting . Many network technologies also provide a way for a sending station to address a message to all possible receiving stations: this is called broadcasting . Some network technologies also provide something in the middle, a way for a sending station to address a message to a particular set of receiving stations, without broadcasting the message to all stations: this is called multicasting .

Multicasting is particularly useful when you're dealing with high-bandwidth applications like audio and video conferencing. With such applications, you may have a number of stations all receiving the same stream of packets, and the stream may consume a significant fraction of the available network bandwidth. If a given stream consumes 10% of your available network bandwidth (which is not uncommon), you wouldn't want to unicast it to each interested host, because each of these unicasts would consume another 10% of your bandwidth, limiting you to 10 participating hosts, and that assumes that you did nothing else with the network. You also wouldn't want to broadcast it to all hosts unless all (or almost all) of your hosts were actually interested in the stream, because it places a significant load on each host to process a broadcast packet and then decide to ignore it.

IP multicasting provides a way to send packets to groups of IP hosts. With IP multicasting, groups of hosts that wish to receive a particular type of packet (e.g., a particular video stream) are assigned an IP multicast address they all share. An IP multicast address looks like a normal IP address in the range 224.0.0.0 through 239.255.255.255. IP multicast addresses are only used as destination addresses; they are never valid as source addresses (multicast packets use the regular IP address of the sending host as their source address).

Multicast groups are somewhat like cable television channels. There are a variety of channels (multicast groups) available, such as HBO , CNN , ESPN , and MTV , but most homes (hosts) subscribe to only a few of the available channels. Some multicast groups are permanent; that is, certain addresses are reserved for certain uses, such as Internet Engineering Task Force ( IETF ) meetings, NASA select video feeds (whenever the space shuttle is in orbit), and so on. Other multicast groups are transient: set up for a particular purpose or event and then shut down when they are no longer needed, to be reused for something else later on.

Multicasting is being used on the Internet today primarily for real-time conferencing services, including video, audio, and electronic whiteboard services. It's starting to be used for other services as well, such as transmitting Usenet news efficiently to a wide body of recipients.

Commercial products, such as routers and hosts, are just starting to support multicasting. Some networking technologies such as Ethernet support multicast directly. You can send an Ethernet packet of information to a magic Ethernet address on a given Ethernet segment, and all hosts on that segment that are listening for that Ethernet address will receive that packet. Other networking technologies, e.g., point-to-point leased lines, don't support multicast, so the effect has to be faked by turning a multicast packet into a series of duplicate unicast packets, each addressed to one of the multicast participants.

Obviously, you want to limit the number of duplicate unicast packets on these point-to-point leased lines, so a common approach to linking two multicast-capable networks (such as Ethernets) over a unicast-only network (such as a T1 leased line) is to create a tunnel over the unicast network, with multicast routers (often called mrouters ) at either end of the tunnel. These mrouters take multicast IP packets, encapsulate them into unicast IP packets, and send them (via regular IP unicast) through the tunnel to the mrouter on the other end, which unencapsulates them to turn them back into multicast IP packets. By creating a web of mrouters and tunnels, you can create a virtual multicast network on top of a unicast backbone.

The MBONE is the ad hoc Multicast Backbone on the Internet, and is just such a web of mrouters and tunnels. Its participants are sites that are interested in using IP multicasting for a variety of services on the Internet.

IP multicasting brings up several firewall issues. If a site uses tunneling to take part in the MBONE , what do the packets for the tunnels look like? What could be sent through the tunnels? If a site doesn't use tunnels, but uses IP multicasting directly, how will the site's packet filtering system deal with it? Can nonmulticast services (such as SMTP , NFS , NIS/YP , and so on) be accessed by attackers via multicast, whether tunneled or not?

IP multicast tunneling is currently done with IP -in- IP encapsulation. That is, a multicast IP packet is encapsulated into a regular IP packet, in much the same way that a TCP or UDP packet normally is. Instead of the usual IP packet containing a UDP packet, for example, you have an IP unicast packet that contains an IP multicast packet that, in turn, contains a UDP packet. Thus, if tunneled multicast packets need to cross a packet filtering system, the system needs to recognize IP -in- IP packets, in much the same way that it recognizes TCP , UDP , and ICMP packets. If your packet filtering system doesn't recognize IP -in- IP by name, but will allow you to specify protocol numbers instead, you need to know that IP -in- IP is protocol number 4 (for comparison, ICMP is 1, TCP is 6, and UDP is 17).

IP multicast tunnels used to be done with source-routed IP packets, but this practice caused a number of problems (not the least of which was upsetting folks who had firewalls), and it is no longer recommended.

To prevent a multicast tunnel from being used as a back door into or out of a network, the current publicly available mrouter code will only accept multicast packets through the tunnel; it won't accept unicast packets shoved through the tunnel in an attempt to bypass your firewall. If you're using a commercial multicast router, rather than the publicly available code off the Internet, you should verify that it will behave in a similar way.

If you have routers and a network topology that support multicast directly, without tunnels, you still have to worry about how any packet filtering system you use is going to cope with it. It shouldn't be too difficult, though, because from a packet filtering point of view, multicast packets just look like regular packets with somewhat unusual destination addresses (in the range 224.0.0.0 through 239.255.255.255). Treat them just as you would anything else: block them all by default and allow the ones you understand and want to support. Keep in mind that each of these multicast addresses is going to apply to multiple internal machines, and that if you're accepting multicast packets from the outside world, then all of the internal machines that are accepting those packets will have to be protected against attack from the outside world - just as if you were accepting any other packets directly from the outside world.

Even if your tunnel is restricted to only multicast packets, or if you're using multicast directly without tunneling, there is still the question of how your hosts will respond to multicast packets addressed to regular ports, such as your NIS/YP and NFS ports. Unfortunately, behavior varies from operating system to operating system, and even from release to release within the same operating system. If your operating system's code is based on Release 3.3 or later of the " IP Multicast Extensions for BSD -Derived UNIX Systems" from Xerox PARC and the University of Delaware, then your system should be safe against these kinds of attacks. Unless you installed the multicast extensions yourself, however, you could have a very difficult time determining what your operating system's multicast code is based on. (Your best bet is to ask your vendor, but don't be surprised if it's difficult to find anybody who knows.)