[-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 sys-
tem, 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 ver-
sions 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 cir-
cumvents 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.
ever, as DCC RESUME may fail if the proxy mangles the filename.
-N Do not act as an IRC proxy. This allows the proxies ident commu-
nication 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 connec-
tions.
-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 mas-
querading, 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'' com-
mand (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
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 con-
nect 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 communica-
tion. 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 con-
taining 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.
: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 com-
mand 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
/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.
BSD May 4, 2000 BSD
Man(1) output converted with
man2html