socks_clients - Online in the Cloud

PROGRAM:

NAME

rfinger - SOCKS client version of finger
rftp - SOCKS client version of ftp
rtelnet - SOCKS client version of telnet
rwhois - SOCKS client version of whois

SYNOPSIS

See the man pages on finger(1), ftp(1), telnet(1), whois(1).

DESCRIPTION

These programs provide the well-known functionalities to hosts within a firewall.
Normally, when a firewall is constructed, IP-accessibility across the firewall is cut off
to reduce security risk to hosts within the firewall. As a result, inside hosts can no
longer use many of the well-known tools directly to access the resources outside the
firewall.

These programs restore the convenience of the well-known tools while maintaining the
security requirement. Though the programs differ very much from their counterparts in the
use of the communication scheme, they should behave almost indistinguishable to the users.
Note though that rftp does echo the password as you type it in if you are using anonymous
as log-in name. Unlike those of the previous versions, these are "versatile" clients,
meaning that they can be used for connections to inside hosts directly and to outside
hosts via SOCKS proxy servers. So they can be used as replacements of their traditional
counterparts.

When any of these programs starts, if the environment variable SOCKS_BANNER is defined,
the program prints to stderr its version number and the name or IP address of its default
SOCKS proxy server. It then consults the configuration file to determine whether a
request should be allowed or denied based on the requesting user, the destination host,
and the requested service. For allowable requests, the configuration file also dictates
whether direct or proxy connection should be used to the given destination, and optionally
the actual SOCKS servers to use for the proxy connection. The program lookps first for
the frozen configuration file /etc/socks.fc first. If that's not found, it then looks for
the file /etc/socks.conf. If both files are absent, these programs will only try direct
connections to the destination hosts, making them behaving like their regular
counterparts.

You can use environment variable SOCKS_NS to set the nameserver for domainname
resolutions. Be sure you use the IP address of the nameserver you want to use, not its
domainname. If SOCKS_NS doesn't exist, the IP address defined by the symbol
SOCKS_DEFAULT_NS at compile time is used if the programs were compiled with that symbol
defined. Otherwise the nameservers specified in /etc/resolv.conf are used.

All the client programs uses syslog with facility daemon and level notice to log their
activities. These log lines usually appear in file /var/adm/messages though that can be
changed by modifying /etc/syslog.conf. (See syslogd(8) and syslog.conf(5).) Typical lines
look like

Apr 11 10:02:23 eon rfinger[631]: connect() from don(don) to abc.com (finger) using sockd at socksserv
May 10 08:39:07 eon rftp[603]: connect() directly from blue(blue) to xyz.edu (ftp)
May 10 08:39:09 eon rftp[603]: bind() directly from blue(blue) for xyz.edu (ftp)
May 18 13:31:19 eon rtelnet[830]: connect() from root(jon) to xyz.edu (telnet) using sockd at sockd2
May 18 14:51:19 eon rtelnet[921]: refused -- connect() from jon(jon) to xyz.edu (telnet)

Of the two user-ids appearing in each log line, the first is the effective user-id when
the program is invoked, the second (that within the parentheses) is the one used at login.
Access control applies to the effective user-ids.

Use socks_clients online using onworks.net services