Services like the Web, electronic mail, and newsgroups allow people to send each other messages that will be read at later times, but what if you want to send an immediate message or have a discussion instead? Several services available on the Internet allow people to interact in real time on the Internet, ranging from "chat rooms" where people can send text messages to teleconferencing programs with video, audio, and whiteboard facilities.
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.
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.
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.
Direction | SourceAddr. | Dest.Addr. | Protocol | SourcePort | Dest.Port | ACKSet | Notes |
|---|---|---|---|---|---|---|---|
In | Ext | Int | TCP | >1023 | 6667[1] | [2] | External client or server contacting internal server |
Out | Int | Ext | TCP | 6667[1] | >1023 | Yes | Internal server answering |
Out | Int | Ext | TCP | >1023 | >1023 | [2] | DCC connection requested by external client; internal client answering invitation from external client |
In | Ext | Int | TCP | >1023 | >1023 | Yes | DCC connection from external client |
Out | Int | Ext | TCP | >1023 | 6667[1] | [2] | Internal client or server contacting external server |
In | Ext | Int | TCP | 6667[1] | >1023 | Yes | External server answering |
In | Ext | Int | TCP | >1023 | >1023 | [2] | DCC connection requested by internal client; external client answering invitation from internal client |
Out | Int | Ext | TCP | >1023 | >1023 | Yes | DCC connection from internal client |
[1] Although 6667 is the most commonly used port for IRC, some servers use other port numbers. [2] ACK is not set on the first packet of this type (establishing connection) but will be set on the rest. | |||||||
When all IRC servers were part of the same spanning tree, any IRC server could serve as a proxy server. These days, IRC servers tend to be independent, and users are likely to want to contact many different servers. It's therefore necessary to have true proxies. A SOCKS-aware IRC client, mIRC, is available for most Unix variants; so is a security-aware dedicated IRC proxy called tircproxy.
DCC connections will not work with mIRC through SOCKS but will with tircproxy, which intercepts and rewrites them. tircproxy is also capable of intercepting, denying, or sanitizing DCC and other dangerous requests, limiting the number of attacks that are possible. It also provides for user authentication on outgoing requests, either in the form of genuine authentication of individual users with username/password information (passed in cleartext) or in the form of quiz questions intended to let all human beings through while preventing people from using bots, programs that take part in IRC.
Normal IRC connections do not include embedded IP addresses and work without problems through network address translation. Some servers will require access to an Auth server on the same apparent IP address, so you will need to provide a mapping that will allow inbound Auth to succeed. DCC connections are more complicated, since they require passing IP addresses and port numbers and allowing inbound connections. In order to allow DCC, the network address translation system will need to understand the IRC protocol, correctly modify the IP addresses and port numbers in DCC commands, and accept the incoming connections associated with them. Alternatively, you can use tircproxy in combination with network address translation and provide static translation for the host running tircproxy. tircproxy will do the work of intercepting the DCC commands.
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 is not part of a tree of external IRC servers; otherwise, it will effectively proxy for your IRC clients and for attacks against them from the outside.