 | Chapter 8 Configuring Internet Services |  |
| Chapter 8 Configuring Internet Services | |
There are several services available on the Internet that allow people to interact in real time on the Internet, including talk, IRC, and various services provided over the MBONE.
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.
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.
talk servers (which broker connections between talk clients, and then get out of the way) use either UDP port 517 (for old versions of talk) or UDP port 518 (for newer versions). talk clients use UDP ports above 1023 to interact with talk servers. talk clients also use TCP ports above 1023 to interact with each other. This means that, in order to allow talk across your firewall, you'd have to allow TCP connections where both ends are using arbitrary ports above 1023; this isn't safe because of vulnerabilities like X11 servers that use ports above 1023.
| Direc- | Source | Dest. | Pro- | Source | Dest. | ACK | |
|---|---|---|---|---|---|---|---|
| tion | Addr. | Addr. | tocol | Port | Port | Set | Notes |
In | Ext | Int | UDP | >1023 | 517 518[30] | [31] | External client contacting internal server |
Out | Int | Ext | UDP | 517 518[30] | >1023 | [31] | Internal server answering external client |
Out | Int | Ext | UDP | >1023 | 517 518 [30] | [31] | Internal client contacting external server |
In | Ext | Int | UDP | 517 518 [30] | >1023 | [31] | External server answering internal client |
Out | Int | Ext | TCP | >1023 | >1023 | [32] | Internal client communicating with external client |
In | Ext | Int | TCP | >1023 | >1023 | [32] | External client communicating with internal client |
[30] Old versions of talk use port 517; newer versions use port 518.
[31] UDP packets do not have ACK bits.
[32] ACK is not set on the first packet of this type (establishing connection) but will be set on the rest.
There are no available proxies for talk. It would theoretically be possible to write one. Because talk involves internal and external clients simultaneously, it would almost have to be a modified-procedure proxy server. (No generic server would handle it, in any case, because it involves both TCP and UDP.) Given the considerable difficulty of writing a talk proxy, and the extreme fragility of the process, it's unlikely that one will become available any time soon. It's more likely that talk will be abandoned altogether for cross-Internet conversations, in favor of something like IRC, which we describe in the next section.
It is impossible to safely allow talk through filters, or to proxy it, so you can't allow talk between the Internet and your internal machines. If, for some reason, you absolutely must allow talk, you will need to put a victim machine on your perimeter net that is untrusted and has no confidential data, and allow users to log into it and run talk from there.
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.
IRC is a TCP-based service. Servers generally listen for incoming connections (from both clients and other servers) on port 6667, although some servers use other port numbers. Clients (and servers contacting other servers) use ports above 1023.
Clients use ports above 1023 to talk to other clients using DCC. To start, the calling client passes an invitation to the called client through the normal IRC server channels. The invitation includes a TCP port number where the calling client is listening for an incoming connection. The called client, if it chooses to accept the invitation, opens a TCP connection to that port.
| Direc- | Source | Dest. | Pro- | Source | Dest. | ACK | |
|---|---|---|---|---|---|---|---|
| tion | Addr. | Addr. | tocol | Port | Port | Set | Notes |
In | Ext | Int | TCP | >1023 | 6667 | [33] | External client or server contacting internal server |
Out | Int | Ext | TCP | 6667 | >1023 | Yes | Internal server answering external client or server |
Out | Int | Ext | TCP | >1023 | 6667 | [33] | Internal client or server contacting external server |
In | Ext | Int | TCP | 6667 | >1023 | Yes | External server answering internal client or server |
In | Ext | Int | TCP | >1023 | >1023 | [33] | DCC connection requested by internal client; external client answering invitation from internal client |
Out | Int | Ext | TCP | >1023 | >1023 | Yes | DCC connection requested by internal client |
Out | Int | Ext | TCP | >1023 | >1023 | [33] | DCC connection requested by external client; internal client answering invitation from external client |
In | Ext | Int | TCP | >1023 | >1023 | Yes | DCC connection requested by external client |
[33] ACK is not set on the first packet of this type (establishing connection) but will be set on the rest.
Because of the spanning tree architecture, any IRC server serves as a proxy server. To configure IRC for proxying, simply put an IRC server on the proxy host and point your internal clients at it.
Although it's theoretically possible to proxy IRC, or to allow just IRC through filters, it's probably not a good idea, because of the weaknesses of the clients. The best way to allow IRC is to put an untrusted victim machine with no confidential data on a perimeter network and let users log into that machine to run IRC.
If you run an internal IRC server, be sure it can't contact or be contacted by external IRC servers; otherwise it will effectively proxy for your IRC clients and for attacks against them from the outside.
If you do allow IRC across your firewall, you can't allow DCC connections to be requested by internal clients, because that would involve accepting incoming TCP connections from external clients to any port above 1023 on the internal machines. You could allow internal clients to establish DCC connections requested by external clients, however, if you're willing to let internal machines talk to any TCP port above 1023 on any external machine.
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.)
|  | |
| 8.8 Information Lookup Services |  | 8.10 Domain Name System (DNS) |