Przekazywanie portów TCP rinetd -

rzedstawiony hack jest tłumaczeniem „Forwarding TCP Ports to Arbitrary Machines” z książki „Linux Servers Hacks” autorstwa Rob’a Flickenger’a udostępnionym on-line (Hack #48) na stronie http://hacks.oreilly.com. Do tłumaczenia zostało dodane także parę informacji od tłumacza.

Jak widzieliśmy, bardzo prosto jest przekazywać porty TCP i UDP z firewalla do komputerów znajdujących się wewnątrz sieci za pomocą programu iptables. Lecz jeśli potrzebujesz przekazywać ruch z dowolnych adresów do komputera, który nie jest nawet w Twojej sieci? Warto wypróbować program przekazujący porty w warstwie aplikacji, jak np. rinetd.

Ten prosty wycinek kodu nie jest najnowszy, ale jest mały, wydajny i doskonale radzi sobie z rozwiązaniem tego problemu. Rozpakuj archiwum (tar zxvf rinetd.tar.gz) i po prostu uruchom program make, a pojawi się niewielki plik binarny: rinted, który pozwoli Ci swobodnie przekazywać porty TCP. Niestety program rinetd nie obsługuje portów UDP.

Plik konfiguracyjny jest rozbrajająco prosty:

[Adres źródłowy] [Port źródłowy] [Adres docelowy] [Port docelowy]

Każdy przekazywany port powinien być zdefiniowany w oddzielnym wierszu. Adresy źródłowy i docelowy mogą występować w postaci nazw hostów lub adresów IP, zaś IP: 0.0.0.0 wiąże program rinted z każdym dostępnym lokalnym adresem IP:

0.0.0.0 80 some.othersite.gov 80
216.218.203.211 25 123.45.67.89 25
0.0.0.0 5353 my.shellserver.us 22

Zapisz plik pod nazwą /etc/rinetd.conf i skopiuj program rinetd w wygodne miejsce (np. /usr/local/sbin/). Następnie po prostu wystartuj go poleceniem: rinetd.

Pierwszy wpis w przykładowym pliku konfiguracyjnym przekazuje cały ruch WWW skierowany do adresów lokalnych do witryny o adresie: some.othersite.gov. Należy mieć na uwadze, że takie rozwiązanie jest dopuszczalne tylko wtedy, gdy nie ma innego procesu (jak np. Apache) związanego z lokalnym portem 80.

Następny wpis przekazuje wchodzący ruch SMTP do adresu IP: 216.218.203.211 do serwera poczty pod adresem IP: 123.45.67.89 (lecz nie ingeruje w pracę agentów SMTP związanych z innymi lokalnymi adresami IP). Ostatni przykładowy wpis spowoduje przekazanie całego ruchu wchodzącego na porcie 5353 do serwera SSH o nazwie my.shellserver.us. Wszystko to działa bez translatora NAT czy specjalnej konfiguracji jądra. Po prostu uruchom program rinetd, a stanie się on demonem i zacznie oczekiwać na dane na określonych portach.

To narzędzie może naprawdę być pomocne przy zmianie adresów numerycznych lub fizycznym przenoszeniu serwerów, ponieważ usługi pozostaną pozornie na pierwotnych adresach IP (choć pochodzą faktycznie z zupełnie innej sieci). rinetd nie wymaga nawet uruchomienia przez użytkownika root, oczywiście jeśli jest tylko wiązany z portami o numerach większych niż 1024. Są też duże możliwości sterowania dostępem i tworzenia dzienników. To malutkie narzędzie warto mieć, kiedy potrzebna będzie droga pośrednia do portów TCP.

RINETD(8)	Unix System Manager's Manual	RINETD(8)

NAME

rinetd -- internet ``redirection server''

SYNOPSIS

/usr/sbin/rinetd

VERSION

Version 0.62, 04/13/2003. Important security fix: version 0.62 corrects a potential buffer overrun caused by failure to reallocate one array when reallocating memory to accommodate more than the initially allocated capacity of 64 connections. Upgrading is strongly recommended. There are no other changes.

WHERE TO GET

For Linux: Download from our web server

For Windows 95/98/NT: Download from our web server

DESCRIPTION

Redirects TCP connections from one IP address and port to another. rinetd is a single-process server which handles any number of connections to 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. rinetd does not redirect FTP, because FTP requires more than one socket.

rinetd is typically launched at boot time, using the following syntax:

/usr/sbin/rinetd

The configuration file is found in the file /etc/rinetd.conf, unless another file is specified using the -c command line option.

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

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 23, 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.

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

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. Under Unix, 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 Unix 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

CONTACT INFORMATION

See the rinetd web page for the latest release. Feel free to contact us.

THANKS

Thanks are due to Bill Davidsen, Libor Pechachek, Sascha Ziemann, Joel S. Noble, the Apache Group, and many others who have contributed advice, encouragement and/or source code to this and other open software projects.