github-repos/rinetd
1
0
Fork 0
mirror of https://github.com/samhocevar/rinetd.git synced 2025-04-26 04:50:21 +08:00
Code Issues Packages Projects Releases Wiki Activity

Import old rinetd 0.52.

Browse Source 
Taken from the Debian archive:
  http://archive.debian.org/debian-security/pool/updates/main/r/rinetd/
This commit is contained in:
Sam Hocevar 2016-01-10 20:46:19 +01:00
parent a359399bb2
commit d46367a44a
8 changed files with 1287 additions and 193 deletions

12
CHANGES
View File

@ -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.

4
Makefile
View File

@ -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

2
README
View File

@ -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

170
index.html
View File

@ -26,7 +26,7 @@ rinetd -- internet ``redirection server''
<p>
<font color="#FF8888" size="4">VERSION</font>
<p>
Version 0.41, 2/11/1998.
Version 0.52, 8/7/1998.
<p>
<font color="#FF8888" size="4">WHERE TO GET</font>
<p>
@ -42,52 +42,171 @@ the address/port pairs specified in the file <code>/etc/rinetd.conf</code>.
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 <strong>does not
redirect FTP,</strong> because FTP requires more than one socket.
<p>
rinetd should be launched at boot time, using the following syntax:
rinetd is typically launched at boot time, using the following syntax:
<p>
<code>/usr/sbin/rinetd</code>
<p>
The format of <code>/etc/rinetd.conf</code> is as follows:
The configuration file is found in the file
<code>/etc/rinetd.conf</code>, unless
another file is specified using the <code>-c</code> command line option.
<p>
<code>bindaddress bindport connectaddress connectport</code>
<font color="#FF8888" size="4">FORWARDING RULES</font>
<p>
Most entries in the configuration file are forwarding rules. The
format of a forwarding rule is as follows:
<pre>
bindaddress bindport connectaddress connectport
</pre>
For example:
<p>
<code>206.125.69.81 80 10.1.1.2 80</code>
<p>
<pre>
206.125.69.81 80 10.1.1.2 80
</pre>
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.
<p>
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 <code>0.0.0.0</code>
can be used. For example:
<pre>
0.0.0.0 23 10.1.1.2 23
</pre>
Would redirect all connections to port 80, for all IP addresses
assigned to the server. This is the default behavior for most
other programs.
<p>
Service names can be specified instead of port numbers. On most systems,
service names are defined in the file /etc/services.
<p>
Both IP addresses and hostnames are accepted for
bindaddress and connectaddress.
<p>
rinetd redirects TCP connections only. There is
no support for UDP.
<font color="#FF8888" size="4">ALLOW AND DENY RULES</font>
<p>
Configuration files can also contain allow and deny rules.
<p>
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.
<p>
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.
<p>
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.
<p>
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.
<p>
The format of an allow rule is as follows:
<pre>
allow pattern
</pre>
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.
<p>
For example:
<p>
<pre>
allow 206.125.69.*
</pre>
This allow rule matches all IP addresses in the 206.125.69 class C domain.
<p>
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.
<p>
<font color="#FF8888" size="4">LOGGING</font>
<p>
rinetd is able to produce a log file in either of two formats:
tab-delimited and web server-style "common log format."
<p>
By default, rinetd does not produce a log file. To activate logging, add
the following line to the configuration file:
<pre>
logfile log-file-location
</pre>
Example:
<pre>
logfile /var/log/rinetd.log
</pre>
By default, rinetd logs in a simple tab-delimited format containing
the following information:
<p>
Date and time<br>
Client address<br>
Listening host
<br>
Listening port
<br>
Forwarded-to host
<br>
Forwarded-to port
<br>
Bytes received from client
<br>
Bytes sent to client
<br>
Result message
<p>
To activate web server-style "common log format" logging,
add the following line to the configuration file:
<pre>
logcommon
</pre>
<p>
<font color="#FF8888" size="4">COMMAND LINE OPTIONS</font>
<p>
The -c command line option is used to specify an alternate
configuration file.
<p>
The -h command line option produces a short help message.
<p>
The -v command line option displays the version number.
<p>
<font color="#FF8888" size="4">REINITIALIZING RINETD</font>
<p>
The kill -1 signal (SIGHUP) can be used to cause rinetd
to reload its configuration file <strong>without</strong> 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 <code>/var/run/rinetd.pid</code>
to facilitate the kill -HUP. An alternate
file name can be provided by using the <code>pidlogfile</code>
configuration file option.
<p>
<font color="#FF8888" size="4">BUGS</font>
<p>
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 <code>SO_LINGER</code> 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 <code>SO_LINGER</code> 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 <code>close()</code> is provided, but this code is untested.
<p>
The logging is inadequate. The duration of the connection should be logged.
<p>
<font color="#FF8888" size="4">LICENSE</font>
<p>
@ -106,5 +225,8 @@ Thomas Boutell can be reached by email:
<p>
<font color="#FF8888" size="4">THANKS</font>
<p>
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.
</body>
</html>

200
match.c Normal file
View File

@ -0,0 +1,200 @@
#include <string.h>
#include <ctype.h>
#include "match.h"
int match(char *sorig, char *p)
{
return matchBody(sorig, p, 0);
}
int matchNoCase(char *sorig, char *p)
{
return matchBody(sorig, p, 1);
}
int matchBody(char *sorig, char *p, int nocase)
{
/* Algorithm:
Word separator: *. End-of-string
is considered to be a word constituent.
? is similarly considered to be a specialized
word constituent.
Match the word to the current position in s.
Empty words automatically succeed.
If the word matches s, and the word
and s contain end-of-string at that
point, return success.
\ escapes the next character, including \ itself.
For each *:
Find the next occurrence of the next word
and advance beyond it in both p and s.
If the next word ends in end-of-string
and is found successfully, return success,
otherwise advance past the *.
If the word is not found, return failure.
If the next word is empty, advance past the *.
Behavior of ?: advance one character in s and p.
Addendum: consider the | character to be a logical OR
separating distinct patterns. */
char *s = sorig;
int escaped = 0;
while (1) {
char *word;
int wordLen;
int wordPos;
if (escaped) {
/* This is like the default case,
except that | doesn't end the pattern. */
escaped = 0;
if ((*s == '\0') && (*p == '\0')) {
return 1;
}
if (nocase) {
if (tolower(*p) != tolower(*s)) {
goto nextPattern;
}
} else {
if (*p != *s) {
goto nextPattern;
}
}
p++;
s++;
continue;
}
switch(*p) {
case '\\':
/* Escape the next character. */
escaped = 1;
p++;
continue;
case '*':
/* Find the next occurrence of the next word
and advance beyond it in both p and s.
If the next word ends in end-of-string
and is found successfully, return success,
otherwise advance past the *.
If the word is not found, return failure.
If the next word is empty, advance. */
p++;
wordLen = 0;
word = p;
while (1) {
if ((*p) == '*') {
break;
}
wordLen++;
if ((*p == '\0') || (*p == '|')) {
break;
}
p++;
}
wordPos = 0;
while (1) {
if (wordPos == wordLen) {
if ((*p == '\0') || (*p == '|')) {
return 1;
}
break;
}
if ((((*s) == word[wordPos]) ||
((*s == '\0') &&
(word[wordPos] == '|'))) ||
(((*s != '\0') && (*s != '|')) &&
(word[wordPos] == '?')))
{
wordPos++;
s++;
} else {
s -= wordPos;
if (!(*s)) {
goto nextPattern;
}
s++;
wordPos = 0;
}
}
break;
case '?':
p++;
s++;
break;
default:
if ((*s == '\0') && ((*p == '\0') ||
(*p == '|'))) {
return 1;
}
if (nocase) {
if (tolower(*p) != tolower(*s)) {
goto nextPattern;
}
} else {
if (*p != *s) {
goto nextPattern;
}
}
p++;
s++;
break;
}
continue;
nextPattern:
while (1) {
if (*p == '\0') {
return 0;
}
if (*p == '|') {
p++;
s = sorig;
break;
}
p++;
}
}
}
#ifdef TEST_MATCH
#include <stdio.h>
#include <string.h>
#include <ctype.h>
int main(int argc, char *argv[])
{
char s[1024];
if (argc != 2) {
fprintf(stderr, "Usage: match pattern\n");
return 1;
}
while (1) {
if (!fgets(s, sizeof(s), stdin)) {
break;
}
while (isspace(s[strlen(s) - 1])) {
s[strlen(s) - 1] = '\0';
}
printf("%s --> %s\n", s, argv[1]);
if (match(s, argv[1])) {
printf("Match\n");
} else {
printf("No Match\n");
}
}
}
#endif /* TEST_MATCH */

9
match.h Normal file
View File

@ -0,0 +1,9 @@
#ifndef MATCH_H
#define MATCH_H 1
extern int match(char *s, char *p);
extern int matchNoCase(char *s, char *p);
extern int matchBody(char *s, char *p, int nocase);
#endif /* MATCH_H */

154
rinetd.8
View File

@ -12,7 +12,7 @@
.Sh SYNOPSIS
.Nm /usr/sbin/rinetd
.Sh VERSION
Version 0.41, 3/1/1998.
Version 0.52, 9/7/1998.
.Sh DESCRIPTION
.Nm rinetd
redirects TCP connections from one IP address and port to another. rinetd
@ -21,13 +21,18 @@ 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.
.Pp
rinetd should be launched at boot time, using the following syntax:
rinetd is typically launched at boot time, using the following syntax:
.Pp
/usr/sbin/rinetd
.Pp
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.
.Sh FORWARDING RULES
Most entries in the configuration file are forwarding rules. The
format of a forwarding rule is as follows:
.Pp
bindaddress bindport connectaddress connectport
.Pp
@ -41,38 +46,145 @@ 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.
.Pp
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:
.Pp
0.0.0.0 23 10.1.1.2 23
.Pp
Would redirect all connections to port 80, for all IP addresses
assigned to the server. This is the default behavior for most
other programs.
.Pp
Service names can be specified instead of port numbers. On most systems,
service names are defined in the file /etc/services.
.Pp
Both IP addresses and hostnames are accepted for
bindaddress and connectaddress.
.Pp
rinetd redirects TCP connections only. There is
no support for UDP.
.Sh ALLOW AND DENY RULES
Configuration files can also contain allow and deny rules.
.Pp
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.
.Pp
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.
.Pp
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.
.Pp
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.
.Pp
The format of an allow rule is as follows:
.Pp
allow pattern
.Pp
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.
.Pp
For example:
.Pp
allow 206.125.69.*
.Pp
This allow rule matches all IP addresses in the 206.125.69 class C domain.
.Pp
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.
.Pp
.Sh LOGGING
rinetd is able to produce a log file in either of two formats:
tab-delimited and web server-style "common log format."
.Pp
By default, rinetd does not produce a log file. To activate logging, add
the following line to the configuration file:
.Pp
logfile log-file-location
.Pp
Example: logfile /var/log/rinetd.log
.Pp
By default, rinetd logs in a simple tab-delimited format containing
the following information:
.Pp
Date and time
.Pp
Client address
.Pp
Listening host
.Pp
Listening port
.Pp
Forwarded-to host
.Pp
Forwarded-to port
.Pp
Bytes received from client
.Pp
Bytes sent to client
.Pp
Result message
.Pp
To activate web server-style "common log format" logging,
add the following line to the configuration file:
.Pp
logcommon
.Sh COMMAND LINE OPTIONS
The -c command line option is used to specify an alternate
configuration file.
.Pp
The -h command line option produces a short help message.
.Pp
The -v command line option displays the version number.
.Sh 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).
connections.
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).
.Pp
to facilitate the kill -HUP. An alternate
filename can be provided by using the <code>pidlogfile</code>
configuration file option.
.Sh LIMITATIONS
rinetd redirects TCP connections only. There is
no support for UDP. rinetd only redirects protocols which
use a single TCP socket. This rules out FTP.
.Sh 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 each connection should be logged.
.Sh LICENSE
Copyright (c) 1997, 1998, Thomas Boutell and Boutell.Com, Inc.
This software is released for free use under the terms of
the GNU Public License, version 2 or higher.
the GNU Public License, version 2 or higher. NO WARRANTY
IS EXPRESSED OR IMPLIED. USE THIS SOFTWARE AT YOUR OWN RISK.
.Sh CONTACT INFORMATION
See http://www.boutell.com/rinetd/ for the latest release.
Thomas Boutell can be reached by email: boutell@boutell.com
.Sh 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 free software projects.

929
rinetd.c
View File

File diff suppressed because it is too large Load Diff