TIRCPROXY(8)

NAME
tircproxy - transparent IRC proxy

SYNOPSIS
tircproxy [-CDHIKLMNQRSUahp] [-b ipaddr] [-d level] [-i ipaddr] [-o ipaddr] [-q file] [-r user] [-s port] [-t seconds] [irc-server [port]]

DESCRIPTION
This man page describes tircproxy 0.4.5.

tircproxy is a transparent IRC proxy, allowing DCC sessions to take place from behind a firewall or masquerading/NAT gateway. It can run from either inetd(8), or by itself.

tircproxy can operate in the traditional sense, as specified by RFC 1919, where the destination appears to be directly reachable to the client system, which is in fact communicating only with the proxy server. This is where the illusion of transparency comes in, and the client programs can operate as normal. The proxy server then spawns a client, connects to the intended destination, and transfers data between the two ends seamlessly.

Alternately, tircproxy can be used as a traditional application layer proxy, accepting explicit connections from the clients and connecting them to a single IRC server as specified by the administrator.

Note: For a more exhaustive discussion of tircproxy consult the program's home page: http://bre.klaki.net/programs/tircproxy/.

OPTIONS
The following command line flags and options are recongized by the proxy:

-C  Do not allow DCC CHAT sessions to take place.

-D  Do not log clients' nicknames in syslog.

-H  Ignore /etc/hosts.allow and /etc/hosts.deny.

-I  Do not interact with an ident daemon. When using a compatible ident daemon, tircproxy may not need root privaleges to correctly identify users. This flag tells the proxy not to attempt such communication with the ident daemon, which on some systems involves creating multiple temporary files.

-K  Disable the kludge that allows DCC to work with mIRC. Some versions of mIRC retrieve their IP addresses from the IRC server, rather than from the system itself. The address returned is that of the proxy server, which breaks DCC transfers. The kludge circumvents this problem by ignoring addresses specified within the packets themselves, and substituting the address that it assumes is that of the client.

    Note: Leave this enabled unless it breaks functionality, since it also improves the proxy's security somewhat.

-L  Log to stderr instead of syslog.

-M  Disable DCC SEND mangling/censorship in incoming and outgoing requests. Normally, certain files offered will be either blocked, or have their names mangled, in the interest of security. These include:

        script.ini
        dmsetup.exe
        dmsetup2.exe
        winhelper.exe
        mschv32.exe
        mirc.ini

    mirc.ini is changed to mirc.in-, while the rest are simply blocked. Beware when using this with older versions of mIRC, however, as DCC RESUME may fail if the proxy mangles the filename.

-N  Do not act as an IRC proxy. This allows the proxies ident communication features and access controls to be used for proxying other TCP/IP based protocols.

-R  Run with more relaxed behaviour. Allow users to irc in the event that no appropriate entry can be found in their respective ident file.

-S  Do not allow DCC SEND transmissions to take place. This affects DCC TSEND, DCC RESEND, and DCC TRESEND as well.

-U  Do not allow unknown DCC requests.

-a  Run in anonymizing mode. This makes the proxy attempt to hide as much information about it's clients as possible. This includes generating user-IDs for the ident daemon. Using this without strict access control (or a quiz file) is probalby a bad idea!

-b ipaddr
    Bind to the specified IP address when running in server mode. This is the address where the proxy listens for incoming connections.

-d level
    Set the debug level:

        0:	No debugging information.
        1:	Minimal debugging information.
        8:	Maximum verbosity.
        9:	Don't fork(); run in the foreground.  Redirects log to stderr.

-i ipaddr
    The internal IP address of the proxy. When using NAT or IP masquerading, this typically falls under one of the address blocks reserved by the IANA (see RFC 1597).

-o ipaddr
    The external IP address of the proxy. This is the address used to connect to the IRC server.

-p  Require the user to supply a valid username and password before allowing him to use the proxy. The username and password may be sent to the proxy either with a “PASS username%password” command (a variant on the standard way to send IRC passwords), or as a simple message responding to the proxy's challange.

-q file
    Ask the user a simple question from the named file. This is meant to keep bots from connecting though the proxy, or to limit use to people who know a secret password. An example illustrating the quiz file's format is given below.

-r user
    Run as the specified user in server mode.

-s port
    Run as a server bound to the specified port.

-t seconds
    Force a sleep(1) between multiple connections initiated under the number of seconds specified.

ACCESS CONTROLS
tircproxy makes use of Wietse Venema's TCP wrapper library (libwrap), if it is present on your system. This allows the administrator to configure access to the proxy using the files /etc/hosts.allow and /etc/hosts.deny.

See hosts_access(5) for information about the syntax of these files. tircproxy checks for the presence of the following daemon tags:

tircproxy
    This is checked whenever a client attempts to connect to IRC through the proxy.
tircproxy_dcc_files
    This is checked against the filename of files offered for DCC SEND. This allows the admin to update the DCC blacklist without restarting (or recompiling) the proxy.
tircproxy_dcc_in
    This is checked against the client's IP address and username whenever a DCC connection is requested.
tircproxy_dcc_out
    This is checked against the IP addresses of external users who request a DCC connection to one of the proxy's clients.

The username used in these checks is not fetched by querying the client's ident daemon, but is looked up in the same tables as are used by the ident communication support.

Another method for access control is to use a quiz file. If activated the quiz mechanism will suppress all output from the client to the server until the client successfully answers a question selected at random from the quiz file. A simple quiz file might look like this:

    # This is a comment, ignored by the proxy
    #
    !This is a generic message, sent to all users no matter which
    !question is selected.
    This is a question?:yes:no:maybe
    Are elephants big?:yes
    Is IRC a waste of time?:yes:no:maybe:of course not!

IDENT COMMUNICATION
When started as root tircproxy will attempt to change it's runtime UID and GID based on the client that is connecting to it. This is one way to get identd to authenticate the user with some accuracy. Other methods, which may allow the proxy to run without root privaleges, involve direct communication between tircproxy and the local ident daemon. The best way is to use UDB(8) shared memory tables for configuration and communication. This requires that you use an UDB-aware ident daemon.

If tircproxy doesn't support UDB on your platform, then you must use the old filesystem based method to configure the IP-to-user mappings. For every machine you expect to connect through the proxy, create a file containing the user's username in /var/run with the name “user-x.x.x.x”, where “x.x.x.x” is the IP address of that machine. For example, if bob likes to IRC from 10.1.2.3, then the command “echo bob >/var/run/user-10.1.2.3”, should suffice.

If you are using UDB, use the udb_ipuser(8) utility to add users to the shared memory tables, like this: “udb_ipuser 10.1.2.3 bob”

Note that if you want the proxy to change UID and GID then the configured users must all have accounts (shell, home directory, and password are not required) on the proxy. If no valid user is found, and the proxy is running as root, then the connection will be dropped (the -R flag avoids this).

BROADCASTS
If the file /etc/motd.irc exists, its contents will be dumped, unformatted, to the user's socket when they connect to IRC. It is up to the proxy's administrator to format this file correctly, like so:

    :admin@isp.net 999 * :You are connected to IRC via this network's
    :admin@isp.net 998 * :transparent proxy server.
    :admin@isp.net 997 * :Have a nice day.

tircproxy will also broadcast a message to each client's socket when the server catches a HUP signal. /tmp/ircbroadcast will be dumped, and will not interfere with DCC connections.

DEDICATED MODE
In non-transparent mode (dedicated mode) the proxy will alwas connect it's clients to the same IRC server. This is activated by specifying the server name, and optionally it's port number last on the tircproxy command line.

Example:
    tircproxy -s 6667 -IH irc.undernet.org 6667

To give access to multiple IRC servers, you can run many stand-alone instances of the proxy (on different ports) or do the same thing using inetd. If no server is specified on the command line, tircproxy assumes it is operating in transparent mode.

STARTING FROM INETD
tircproxy will automatically detect if it is being run from inetd, no additional command line arguements are required, configure it just like you would configure any other TCP/IP service.

Transparent proxying on does not work on Linux, when the proxy is run from inetd.

IPF TRANSPARENT PROXYING
For transparent operation ipf(8) should be configured to redirect packets destined for remote IRC servers to the proxy. Unfortunately, when using IPFilter for transparancy the proxy must open /dev/ipnat, which can only be done by root - so for this to work you must run the proxy with full root privaleges. tircproxy does not add redirection rules dynamically, so they should be inserted into /etc/ipnat.rules. These rules should typically resemble:

    rdr xl0 10.0.0.0/8 port 6667 -> 127.0.0.1 port 7666 tcp

This would redirect all IRC connection attempts from the internal network 10.x.x.x to the proxy running on the localhost, port 7666, assuming your ethernet interface is xl0.

LINUX TRANSPARENT PROXYING
Under Linux 2.2 transparent proxying would be activated with commands something like this:

    tircproxy -s 7666 -i 10.1.2.3 ...
    ipchains -A input -j REDIRECT 7666 -p tcp -s 10.0.0.0/8 -d 0.0.0.0/0 6667

Under Linux 2.0 you must use ipfwadm instead of ipchains:

    ipfwadm -I -i accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 6667 -r 7666

This would bot redirect all IRC connection attempts from the internal network 10.x.x.x to the proxy running on the localhost, port 7666.

FILES
/etc/hosts.allow
    Access control: allowed connections
/etc/hosts.deny
    Access control: denied connections
/dev/ipnat
    Device that performs packet ipf redirection.
/etc/ipnat.rules
    Configuration of IPF forwarding rules (if any).
/etc/motd.irc
    File dumped to clients' sockets when connecting to IRC.
/tmp/ircbroadcast
    File dumped to clients' sockets when server receives SIGHUP.
quizzes.txt
    Quiz file.

SEE ALSO
inetd(8) , hosts_access(5) , oidentd(8) , identd(8)

/usr/doc/tircproxy-0.4.5/

http://bre.klaki.net/programs/tircproxy/

BUGS
Redirect rules are not added dynamically, which may pose a problem for some firewalled environments.

Authentication can only take place at a 1:1 (one user for each client machine) ratio. This can result in users being incorrectly authenticated when connecting to IRC.

THANKS
Thanks to Baker Hamilton <garath@ntplx.net> for writing the first version of this man page.