diff --git a/CHANGES b/CHANGES index bf00fec..82bb24e 100644 --- a/CHANGES +++ b/CHANGES @@ -26,3 +26,15 @@ them with code that should fail gracefully without crashing the program or breaking existing connections when another application is hogging memory. +Version 0.5: added logging in both tab-delimited +and web-server-style formats. No longer exits if +an individual configuration file line generates +an error. Added allow and deny rules. Added +-c command line option to specify a configuration file. + +Version 0.51: fixed failure to check for an open +log file before writing log entries. + +Version 0.52: documentation added regarding the +ability to bind to all IP addresses, if desired, +using the special address 0.0.0.0. diff --git a/Makefile b/Makefile index 79cf791..d598b18 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ CFLAGS=-DLINUX -g -rinetd: rinetd.o - gcc rinetd.o -o rinetd +rinetd: rinetd.o match.o + gcc rinetd.o match.o -o rinetd install: rinetd install -m 700 rinetd /usr/sbin diff --git a/README b/README index 486688b..24e4454 100644 --- a/README +++ b/README @@ -1,4 +1,4 @@ -rinetd version 0.41, by Thomas Boutell. Released under +rinetd version 0.51, by Thomas Boutell. Released under the terms of the GNU Public License, version 2 or later. This program is used to efficiently redirect connections diff --git a/index.html b/index.html index dc9fb03..46747e5 100644 --- a/index.html +++ b/index.html @@ -26,7 +26,7 @@ rinetd -- internet ``redirection server''
VERSION
-Version 0.41, 2/11/1998. +Version 0.52, 8/7/1998.
WHERE TO GET
@@ -42,52 +42,171 @@ the address/port pairs specified in the file /etc/rinetd.conf.
Since rinetd runs as a single process using nonblocking I/O, it is
able to redirect a large number of connections without a severe
impact on the machine. This makes it practical to run TCP services
-on machines inside an IP masquerading firewall.
+on machines inside an IP masquerading firewall. rinetd does not
+redirect FTP, because FTP requires more than one socket.
-rinetd should be launched at boot time, using the following syntax: +rinetd is typically launched at boot time, using the following syntax:
/usr/sbin/rinetd
-The format of /etc/rinetd.conf is as follows:
+The configuration file is found in the file
+/etc/rinetd.conf, unless
+another file is specified using the -c command line option.
-bindaddress bindport connectaddress connectport
+FORWARDING RULES
+Most entries in the configuration file are forwarding rules. The +format of a forwarding rule is as follows: +
+bindaddress bindport connectaddress connectport +For example: -
-206.125.69.81 80 10.1.1.2 80
-
+
+206.125.69.81 80 10.1.1.2 80 +Would redirect all connections to port 80 of the "real" IP address 206.125.69.81, which could be a virtual interface, through rinetd to port 80 of the address 10.1.1.2, which would typically be a machine on the inside of a firewall which has no direct routing to the outside world.
+Although responding on individual interfaces rather than on all
+interfaces is one of rinetd's primary features, sometimes it is
+preferable to respond on all IP addresses that belong to the server.
+In this situation, the special IP address 0.0.0.0
+can be used. For example:
+
+0.0.0.0 23 10.1.1.2 23 ++Would redirect all connections to port 80, for all IP addresses +assigned to the server. This is the default behavior for most +other programs. +
Service names can be specified instead of port numbers. On most systems, service names are defined in the file /etc/services.
Both IP addresses and hostnames are accepted for bindaddress and connectaddress.
-rinetd redirects TCP connections only. There is -no support for UDP. +ALLOW AND DENY RULES +
+Configuration files can also contain allow and deny rules. +
+Allow rules which appear before the first forwarding rule are +applied globally: if at least one global allow rule exists, +and the address of a new connection does not +satisfy at least one of the global allow rules, that connection +is immediately rejected, regardless of any other rules. +
+Allow rules which appear after a specific forwarding rule apply +to that forwarding rule only. If at least one allow rule +exists for a particular forwarding rule, and the address of a new +connection does not satisfy at least one of the allow rules +for that forwarding rule, that connection is immediately +rejected, regardless of any other rules. +
+Deny rules which appear before the first forwarding rule are +applied globally: if the address of a new connection satisfies +any of the global allow rules, that connection +is immediately rejected, regardless of any other rules. +
+Deny rules which appear after a specific forwarding rule apply +to that forwarding rule only. If the address of a new +connection satisfies any of the deny rules for that forwarding rule, +that connection is immediately rejected, regardless of any other rules. +
+The format of an allow rule is as follows: +
+allow pattern ++Patterns can contain the following characters: 0, 1, 2, 3, 4, 5, +6, 7, 8, 9, . (period), ?, and *. The ? wildcard matches any one +character. The * wildcard matches any number of characters, including +zero. +
+For example: +
+
+allow 206.125.69.* ++This allow rule matches all IP addresses in the 206.125.69 class C domain. +
+Host names are NOT permitted in allow and deny rules. The performance +cost of looking up IP addresses to find their corresponding names +is prohibitive. Since rinetd is a single process server, all other +connections would be forced to pause during the address lookup. +
+LOGGING +
+rinetd is able to produce a log file in either of two formats: +tab-delimited and web server-style "common log format." +
+By default, rinetd does not produce a log file. To activate logging, add +the following line to the configuration file: +
+logfile log-file-location ++Example: +
+logfile /var/log/rinetd.log ++By default, rinetd logs in a simple tab-delimited format containing +the following information: +
+Date and time
+Client address
+
+Listening host
+
+Listening port
+
+Forwarded-to host
+
+Forwarded-to port
+
+Bytes received from client
+
+Bytes sent to client
+
+Result message
+
+To activate web server-style "common log format" logging, +add the following line to the configuration file: +
+logcommon ++
+COMMAND LINE OPTIONS +
+The -c command line option is used to specify an alternate +configuration file. +
+The -h command line option produces a short help message. +
+The -v command line option displays the version number. +
+REINITIALIZING RINETD
The kill -1 signal (SIGHUP) can be used to cause rinetd
to reload its configuration file without interrupting existing
-connections (this was added in version 0.4). Under Linux\(tm the process id
-is saved in the file \fI/var/run/rinetd.pid\fR
-to facilitate the kill -HUP (added in version 0.41).
+connections. Under Linux(tm) the process id
+is saved in the file /var/run/rinetd.pid
+to facilitate the kill -HUP. An alternate
+file name can be provided by using the pidlogfile
+configuration file option.
BUGS
-rinetd does not currently produce any log information. The
-server redirected to is not able to identify the host the
-client really came from. Sockets would theoretically lose
-data when closed with SO_LINGER turned off, but in Linux
-this is not the case (kernel source comments support this
-belief on my part). On non-Linux platforms, alternate code
-which uses a different trick to work around blocking close()
-is provided, but this code is untested. The manpage
-is sketchy.
+The server redirected to is not able to identify the host the
+client really came from. This cannot be corrected; however,
+the log produced by rinetd provides a way to obtain this
+information. Sockets would theoretically lose data when closed
+with SO_LINGER turned off, but in Linux this is not the case
+(kernel source comments support this belief on my part). On non-Linux
+platforms, alternate code which uses a different trick to work around
+blocking close() is provided, but this code is untested.
+
+The logging is inadequate. The duration of the connection should be logged.
LICENSE
@@ -106,5 +225,8 @@ Thomas Boutell can be reached by email:
THANKS
-Thanks are due to Bill Davidsen. - +Thanks are due to Bill Davidsen, Libor Pechachek, Sascha Ziemann, the +Apache Group, and many others who have contributed advice +and/or source code to this and other open software projects. +