Access to the proxy and it's features can be restricted in many different ways:
/etc/hosts.allow
and
/etc/hosts.deny
,The third method is discussed in the section about choosing between IP addresses.
The fourth requires no specific configuration of Tircproxy, and is also highly platform dependant. It is therefore beyond the scope of this document, refer to your operating system's documentation for more information.
Using many (or all) of these methods at the same time may be a good idea.
This feature is enabled by default. Disable it with the -H flag.
Many systems have adopted the use of Wietse Venema's TCP wrapper system, to
restrict access to daemons invoked through inetd. Originally this was
implemented using a standalone application, which was read it's
configuration from files named /etc/hosts.allow
and
/etc/hosts.deny
. Tircproxy can make direct use of these files,
without needing the wrapper program, whether it is running as a standalone
daemon or invoked from inetd.
From the hosts_access(8) man page (tcp wrappers 7.6):
The access control software consults two files. The search stops at the first match:
- Access will be granted when a (daemon,client) pair matches an entry in the
/etc/hosts.allow
file.- Otherwise, access will be denied when a (daemon,client) pair matches an entry in the
/etc/hosts.deny
file.- Otherwise, access will be granted.
A non-existing access control file is treated as if it were an empty file. Thus, access control can be turned off by providing no access control files.
Tircproxy checks for the following daemon tags:
Note: The user name provided by the identd support code is used instead of sending an authentication request to the client.
It is generally a good idea to disable this feature when you are first
testing the proxy, since may sites have a catch-all "ALL: ALL" rule in the
/etc/hosts.deny
file, which will cause the proxy to reject all
connections.
Assuming you wanted to allow only the 10.11.12.x network to connect to your proxy, but didn't want the user on 10.11.12.13 to be able to do any DCC stuff, you might use the following configuration:
/etc/hosts.allow: tircproxy_dcc_out: ALL /etc/hosts.deny: tircproxy: ALL except 10.11.12.0/255.255.255.0 tircproxy_dcc_in: 10.11.12.13 tircproxy_dcc_in: ALL except 10.11.12.0/255.255.255.0 tircproxy_dcc_files: bo.exe passwd
This also adds the file names "bo.exe" and "passwd" to the DCC SEND blacklist.
These features are disabled by default. Activate them with the -q or -p options.
In many cases it is more useful to limit access to the proxy by requiring a password than by IP address or hostname. Tircproxy supports two methods of password authentication, one based on the local user list (usually /etc/passwd) and the other based on a quiz file.
In both cases, events will happen like this:
Using passwords from the proxy server's user list is selected by the -p flag, and may require Tircproxy to run as root, depending on whether shadow passwords or some comperable system is installed or not. Administrators should beware that this optionl will require the passwords to be sent unencrypted over the network, which is generally not a good idea.
When using local usernames and passwords, the client should send it's
authentication formatted like this, "username%password
", or this,
"username password
" (without the quotes). The latter is easiest
when the user identifies himself by sending a message, but the former is
useful when using the clients built-in password support command.
Using a quiz file (the -q filename option) is a much more flexible way to authenticate your users. It allows you to customize both the messages sent to the users when they connect and what replies to accept. A simple quiz file might contain only a single question, e.g. "Password please?" and a list of accepted passwords. A more interesting example is a file with many different questions. When Tircproxy is told to use such a file it will select a question at random. This gives proxy administrators a simple but effective way to keep people from running "bots", since the bots won't be smart enough to answer the questions presented to them.
Note that the quiz system is not case sensitive, it will treat "APPLES" and "apples" as the same word.
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!