IRC is a multi-user text-based real-time conferencing system. Users run IRC client programs to connect to IRC servers. IRC servers can be arranged in a spanning tree and talk to each other to pass messages to all of the clients; these days, many IRC servers are independent and don’t take part in a tree. Figure 19.1 shows how the IRC servers are connected. Clients might connect to any of these servers.

Figure 19.1. IRC server tree

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 that those users think will do neat things on their systems but 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, multi-user, real-time communication can be handy; it has many of the advantages of teleconferencing for a much lower price tag.

While IRC clients pose a risk, IRC servers are relatively safe. You should be able to safely run an IRC server in a restricted (chrooted) 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. Most IRC servers will attempt to use the Auth protocol to get information about the user. Some IRC servers will not accept connections if Auth doesn’t work. See Chapter 21, for more information about Auth.

ICQ is a conferencing protocol developed by Mirabilis and run in conjunction with the conferences available on their servers. Although ICQ is a proprietary service, it is one of the more popular web-based chat services. Like IRC, ICQ is a popular place for attackers to look for targets, including computers that may be vulnerable and people who may be possible to manipulate with social engineering. Many people report that they notice an increased number of people probing their site when they use ICQ.

In addition to the significant indirect problems with ICQ, straightforward security problems have occurred with the ICQ client itself. These are mostly denial of service attacks where people can crash or hang the machine running the client, but some of them have been buffer overflow problems that could allow an attacker to run arbitrary commands. In addition, one version of the client set up a web server as well as the ICQ client. This is unpleasant for security no matter what web server it is (the vulnerabilities of a web server are quite a bit larger than those of a chat client) and was made worse by the fact that the particular web server that Mirabilis provided allowed any file on the machine to be transferred. Although these problems have been rapidly corrected by Mirabilis, the history of repeated problems is a cause for concern.

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 only worked reliably 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 the user should respond in order 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 19.2 shows how talk works.

Figure 19.2. 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.

Up to this point, we’ve been discussing methods of exchanging real-time messages in text. There are also real-time messaging systems that allow the exchange of other kinds of data; these include Internet telephones, video conferencing systems, and application-sharing systems. These types of data require a great deal more bandwidth than plain text and often have more security implications.

Multimedia protocols tend to have several common characteristics. First, they normally use more than one port. They use multiple data streams in order to separate data with different characteristics and in order to maximize the efficiency with which they use network resources. Thus, they normally separate audio data from video data and use different channels for data going in different directions. They also separate the actual data from administrative commands, so that the port used to send video is not the same as the port used to say “Stop sending me video, I can’t take it any more”; this maximizes the chances that the administrative commands will actually get through. The administrative functions are normally known as call control.

Most multimedia protocols use different lower-level protocols for data and for call control. Data is almost always sent over UDP, while call control is almost always sent over TCP. This is because the data needs a maximum of speed. It’s not important if some packets are lost, as long as all the packets that get through are used as soon as they arrive. The call control, on the other hand, happens less often but must not get lost; it’s worth the higher overhead of TCP in order to be guaranteed that commands will arrive.

Multimedia protocols are very difficult to protect adequately with firewalls. It would be hard to support any protocol that involved a large number of channels, going in both directions, and using both connection-oriented and connectionless protocols, but multimedia protocols further complicate the picture by requiring very high performance.

T.120 and H.323

T.120 and H.323^[30] are International Telecommunications Union (ITU) standards for conferencing. T.120 covers file transfer, chat, whiteboard, and application sharing; H.323 covers audio and video conferencing. These are both higher-level standards that use a number of lower-level protocols for various purposes, and you will occasionally hear people talk about Q.931, G.711, H.245, H.261, and H.263 in particular as parts of H.323, and T.122 through T.127 as parts of T.120. For most purposes, you don’t need to worry about these lower-level protocols, which are used in conjunction with the higher-level protocols.

Neither the H.323 nor the T.120 standard requires implementors to provide any security. H.323 is used to carry audio and video data that will be presented to the user. Although this presents a risk of information leaks, it’s not directly dangerous to the client except in the ways all protocols are dangerous to clients. Because H.323 sets up a large number of incoming data channels, both UDP and TCP, there’s a significant risk that allowing H.323 will allow people to attack other, more vulnerable services.

T.120, on the other hand, is inherently dangerous. Both file transfer and application sharing are directly attackable applications.

Packet filtering characteristics of T.120

When running over TCP/IP, T.120 uses a straightforward TCP connection on port 1503. (This is actually specified by T.123, which is the transport standard associated with T.120.)

Direction	SourceAddr.	Dest.Addr.	Protocol	SourcePort	Dest.Port	ACKSet	Notes
In	Ext	Int	TCP	>1023	1503	[31]	External client contacting internal server
Out	Int	Ext	TCP	1503	>1023	Yes	Internal server answering external client
Out	Int	Ext	TCP	>1023	1503		Internal client contacting external server
In	Ext	Int	TCP	1503	>1023	Yes	External server answering internal client
[31] ACK is not set on the first packet of this type (establishing connection) but will be set on the rest.

Proxying characteristics of T.120

Because T.120 uses a single TCP connection on a well-defined port, it is quite easy to allow through proxies. However, since T.120 allows both relatively safe uses (chat and whiteboard) and dangerous uses (file transfer and application sharing), it would be wise to have a T.120-aware proxy to enforce some security. Such proxies do not appear to be available yet.

Network address translation characteristics of T.120

T.120 will work transparently with network address translation.

Packet filtering characteristics of H.323

H.323 uses at least three ports per connection. A TCP connection at port 1720 is used for call setup. In addition, each data stream requires one dynamically allocated TCP port (for call control) and one dynamically allocated UDP port (for data). Audio and data are sent separately, and data streams are one-way; this means that a normal video conference will require no less than eight dynamically allocated ports (a TCP control port and a UDP data port for outgoing video, another pair for outgoing audio, another pair for incoming video, and a final pair for incoming audio). Figure 19.3 shows the connections involved in a generic H.323 conference. Note that four of the dynamically allocated ports will be established from the outside to the inside (regardless of which side initiated the conversation).

Figure 19.3. An H.323 video conference, with audio

Direction	SourceAddr.	Dest.Addr.	Protocol	SourcePort	Dest.Port	ACKSet	Notes
In	Ext	Int	TCP	>1023	1720	[32]	External caller contacting internal callee
Out	Int	Ext	TCP	1720	>1023	Yes	Internal callee responding to external caller
Out	Int	Ext	TCP	>1023	1720	[32]	Internal caller contacting external callee
In	Ext	Int	TCP	1720	>1023	Yes	External callee responding to internal caller
Out	Int	Ext	TCP	>1023	>1023	[34]	Call control for data going internal to external
In	Ext	Int	TCP	>1023	>1023	Yes	Responses to call control for data going internal to external
In	Ext	Int	TCP	>1023	>1023	[34]	Call control for data going external to internal
Out	Int	Ext	TCP	>1023	>1023	Yes	Responses to call control for data going external to internal
Out	Int	Ext	UDP	>1023	>1023	[34]	Data going internal to external
In	Ext	Int	UDP	>1023	>1023	[34]	Data going external to internal
[32] ACK is not set on the first packet of this type (establishing connection) but will be set on the rest. [34] UDP has no ACK equivalent.

The extensive use of dynamically allocated ports makes H.323 very hard to deal with via packet filtering; in fact, Microsoft’s instructions for NetMeeting (which is based upon H.323 and mentioned later) suggest allowing all UDP and TCP connections in either direction where both ends are above 1024. This configuration is extremely insecure, and we don’t recommend it. However, it is the only way to allow H.323 through a nonstateful packet filtering firewall.

A stateful packet filter that can monitor the H.323 port negotiation would be capable of allowing only the needed data ports. Note that straightforward tricks like allowing only UDP responses will not work for H.323 because the incoming data streams from the remote host will not meet the normal criteria to be considered a response; the packet filtering must be H.323-aware. Unfortunately, H.323 is not particularly easy to parse, so H.323-aware packet filters are rare, although high-end packet filtering systems do offer them.

Because H.323 does not have any built-in authentication, allowing H.323 through a packet filter is not very secure, even if you use a dynamic packet filtering system that understands H.323. If you are concerned about transmitting confidential data, or about the security of your clients, you would be better off using a proxy that provides authentication features.

Proxying characteristics of H.323

H.323 has almost every characteristic that makes a protocol hard to proxy; it uses both TCP and UDP, it uses multiple ports, it uses dynamically allocated ports, it creates connections in both directions, and it embeds address information inside packets. The only good news is that the protocol provides a space where clients can specify a desired destination, making it easy for a proxy to figure out where connections should be directed.

One way of getting around the problems with proxying H.323 is to use what the standard calls a Multipoint Control Unit (MCU) and place it in a publicly accessible part of your network. These systems are designed primarily to control many-to-many connections, but they do it by having each person in the conference connect to them. It means that if you put one on a bastion-host network, you can allow both internal and external callers to connect to it, and only to it, and still get conferencing going. If this machine is well configured, it is relatively safe. However, it’s not a true proxy. The external users have to be able to connect directly to the multipoint control unit; one multipoint control unit will not connect to another. The end result is that two sites that both use this workaround can’t talk to each other. It works only if exactly one site in the conversation uses it. Several systems are available that provide this functionality, under various names.

It is also possible to get true H.323 proxies, which usually provide multipoint control and security features as well. In general, these are special-purpose products, not included with generic proxying packages. As we’ve pointed out, proxying H.323 is considerable work; it’s not a minor modification to a normal proxy. However, vendors like Cisco and Microsoft that offer wide product ranges do offer H.323 proxying as part of specialized video conferencing products.

Network address translation characteristics of H.323

Because H.323 uses embedded IP addresses to set up the server-to-client connections, it will not work with straightforward network address translation. You will need a network address translator that is H.323-aware. These translators are rare because the IP address is not embedded in a fixed location; the network address translator has to actually parse the packets in order to be able to do the translation. This functionality is included in some of the H.323 proxies.

Summary of recommendations for T.120 and H.323

• Do not allow T.120 through your firewall.

• Use a special-purpose H.323 proxy that provides security features to allow H.323.

NetMeeting is Microsoft’s conferencing program. It allows multiple people to connect for file transfer, chat, whiteboard, and application sharing, or two people to connect for audio/video conferencing.

NetMeeting is based on T.120 and H.323 but uses some extra protocols; Figure 19.4 shows a full-featured NetMeeting conference.

In addition to the normal security implications of T.120 and H.323, NetMeeting has had implementation problems, including buffer overflow bugs. However, most of the security concerns with NetMeeting involve the capabilities provided by T.120 and H.323. As NetMeeting has evolved, it has added more and more features to allow clients to place limits on what can be done. For instance, it is now possible for a client to allow audio/video conferencing without permitting file transfer or application sharing, and it is possible to require authentication. On the other hand, it is still extremely difficult for an administrator to force those controls on clients. There is no good way for an administrator to make sure that clients inside the firewall are safe from attack via NetMeeting.

Packet Filtering Characteristics of NetMeeting

NetMeeting uses T.120 and H.323, but in addition to their normal ports, it uses an extra audio call control connection at TCP port 1731, an LDAP-based locator service called the Internet Locator Service (ILS) at TCP port 389, and a proprietary locator service called the User Location Service (ULS) at TCP port 522. The connections involved are shown in Figure 19.4; the table shows only the ports that are special to NetMeeting.

Figure 19.4. A NetMeeting conference

Direction	SourceAddr.	Dest.Addr.	Protocol	SourcePort	Dest.Port	ACKSet	Notes
In	Ext	Int	TCP	>1023	1731	[54]	External caller contacting internal callee, audio control
Out	Int	Ext	TCP	1731	>1023	Yes	Internal callee responding to external caller, audio control
In	Ext	Int	TCP	>1023	389		External client to internal ILS server
Out	Int	Ext	TCP	389	>1023	Yes	Responses from internal ILS server
In	Ext	Int	TCP	>1023	522		External client to internal ULS server
Out	Int	Ext	TCP	522	>1023	Yes	Responses from internal ULS server
Out	Int	Ext	TCP	>1023	1731	[54]	Internal caller contacting external callee, audio control
In	Ext	Int	TCP	1731	>1023	Yes	External callee responding to internal caller, audio control
Out	Int	Ext	TCP	>1023	389		Internal client to external ILS server
In	Ext	Int	TCP	389	>1023	Yes	Responses from external ILS server
Out	Int	Ext	TCP	>1023	522		Internal client to external ULS server
In	Ext	Int	TCP	522	>1023	Yes	Responses from external ULS server
[54] ACK is not set on the first packet of this type (establishing connection) but will be set on the rest.

As we discussed in Chapter 4, IP supports three kinds of packets; unicast (addressed to a single host), broadcast (addressed to all hosts), and multicast (addressed to a group of hosts). Multicast IP packets look just like regular IP packets with destination addresses that are in the range 224.0.0.0 through 239.255.255.255. An individual address in this range (224.0.1.1, for instance) is called a multicast group (because it addresses a group of hosts).

Because of the nature of multicast, it makes sense only to multicast IP protocols that are not session oriented. One host cannot usefully set up a single session with multiple other hosts. Since TCP is session oriented, a TCP packet should never have a multicast destination address. Currently the only IP protocols that are normally seen with multicast destination addresses are UDP, IGMP, and OSPF. Similarly, multicast addresses are valid only as destination addresses, not as source addresses (a packet can’t come from a group of hosts).

Multicasting is particularly useful when you’re dealing with high-bandwidth loss-tolerant 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 percent 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 percent 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.

Multicast groups are somewhat like cable television channels. A variety of channels (multicast groups), such as HBO, CNN, ESPN, and MTV, are available, 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 NTP, video conferencing of 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.

Not all networks will pass multicast traffic. Some networks refuse to pass multicast in order to preserve network bandwidth, and others use routing hardware that doesn’t understand multicast. In either case, it is possible to use multicast, while controlling the traffic that is passed, by using multicast tunnels.

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) 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 and NFS) be accessed by attackers via multicast, whether or not they’re tunneled?

IP multicast tunneling is currently done with IP-in-IP encapsulation, which is discussed further in Chapter 4. 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 look just like regular packets with somewhat unusual destination addresses (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. Multicast routing is handled by a special protocol called IGMP, which is discussed in Chapter 22.

For a long time, multicast was used almost exclusively for multimedia, but there are now more and more uses of multicast for administrative protocols. This has made accepting multicast much more risky, since there are now vulnerable services (NIS under Unix, WINS replication under Windows NT) that support multicast.

Even if your tunnel is restricted to only multicast packets, or if you’re using multicast directly without tunneling, and you have protected risky servers that support multicast, there is still the question of how your hosts will respond to multicast packets addressed to regular ports, such as your SMTP and NFS ports. 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.)