any 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, "Authentication and Auditing Services", for more information about Auth.
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.
|External client or server contacting internal server|
|Out||Int||Ext||TCP||6667||>1023||Yes||Internal server answering|
|Out||Int||Ext||TCP||>1023||>1023||||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||||Internal client or server contacting external server|
|In||Ext||Int||TCP||6667||>1023||Yes||External server answering|
|In||Ext||Int||TCP||>1023||>1023||||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|
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.
|18.3. Remote Graphical Interfaces||19.2. ICQ|
Copyright © 2002 O'Reilly & Associates. All rights reserved.