NAME
sockd.conf - SOCKS server configuration file
SYNOPSIS
/etc/sockd.conf
DESCRIPTION
The file /etc/sockd.conf is used to control access to SOCKS proxy
server sockd and its services. (See sockd(8).) Permission and denial
of a service request can be decided based on various combinations of
the requesting host, the destination host, the type of service
(destination port number), as well as the requesting user. A line in
/etc/sockd.conf can be up to 1023 characters long. Each line may
contain the following fields in the indicated order:
action [?=use_identd] [*=userlist] src_addr src_mask [dst_addr
dst_mask] [op dst_port] [ : shell_cmd ]
Spaces and tabs separate the fields. Fields enclosed in square brackets
are optional. Blank lines are allowed. Except for lines that start with
#NO_IDENTD: or #BAD_ID:, everything from the first appearance of # to
the end of the line is considered comment and thus ignored by sockd
during normal validation.
The action field must be either permit or deny and indicates the action
to be taken if a request matches the conditions specified in that line.
The use_identd field, when present, must be I, i, or n, and is used to
specify whether identd verification should be employed for the current
line. ?=I demands the use of identd for verifying the user’s identity,
denying access if connection to client’s identd fails or if the result
does not match the user-id reported by the client program. ?=i also
specifies the use of identd, but denies access only if client’s identd
reports a user-id different from what the client program claims. ?=n
turns off the use of identd. For the line in which these fields are
used, they override the global identd setting, which is determined by
options -I and -i on the sockd command line.
The userlist field, when present, consists of one or more user-ids or
filenames, with comma as separator. No spaces or tabs are allowed in
the list. The user-ids should be ids of users on the requesting host,
not those on the destination host or the SOCKS server host. The
filenames must be full pathnames with the leading /. Inside the
specified files, user-ids may be listed one or several per line, with
any combination of blanks, tabs, and commas as separators. The
appearance of # marks the remainder of the line as comment. Each line
in the files may be up to 1023 characters long. If the *=userlist
field is omitted, the line applies to all user-ids.
The src_addr and dst_addr fields either specify IP addresses of hosts,
networks, or subnets in the usual dotted form, e.g., 129.201.4.0, or a
domain name, e.g., internic.net. The src_mask and dst_mask fields are
masks for the corresponding IP addresses. Bits in these masks that are
set to 0 indicate the bit positions to be ignored during comparisons of
IP addresses. So, specifying 255.255.255.255 in the mask demands an
exact match with the specified IP address field, whereas 0.0.0.0 in the
mask causes a match no matter what IP address is specified. The
contents of the mask fields are ignore, though they must still be
supplied (use 0.0.0.0), if domain names are used for the corresponding
address fields. If the domain name starts with a period, it specifies a
zone and matches all domain names within that zone, otherwise it
matches only the domain name itself. For example, xyz.com matches only
xyz.com, while .xyz.com matches not only xyz.com, but also abc.xyz.com
and this.and.that.xyz.com, among others. The special symbol ALL (which
must be entirely in uppercase) matches everything. Domain names are
otherwise case-insensitive.
If the dst_addr dst_mask pair is omitted, the line applies to all
destination hosts.
The op field must be eq, neq, lt, gt, le, or ge, for the condition of
equal, not equal, less than, greater than, less than or equal, and
greater than or equal, respectively. The dst_port field can be either
a port number, e.g., 23, or the equivalent service name as specified in
the file /etc/services, e.g., telnet for port number 23. If this pair
is omitted, the line applies to all services, i.e., all destination
port numbers.
For example, consider the line
permit *=root,clivep 128.103.4.10 255.255.255.255 179.200.20.0
255.255.255.0 le 1023
To match the conditions indicated in this line, a request must come
from a user named ’root’ or ’clivep’ on the host whose IP address is
128.103.4.10 exactly, the destination host must have 179.200.20 in the
first three bytes of its IP address (the last byte doesn’t matter), and
the service must use a port number less than or equal to 1023 on the
destination host. Since the action field is permit, such requests will
be granted.
When a request is received by sockd, it checks against the lines in
file /etc/sockd.conf, one line at a time. Once it finds a line with
conditions that are matched by the request, the request is either
granted or denied based on the action field of that line. The remaining
lines of file /etc/sockd.conf are skipped. If no matching line is found
in the entire file, the request is denied.
Be very careful how you order the lines in file /etc/sockd.conf. The
following two lines in the indicated order
deny *=abxyz 128.140.13.24 0.0.0.0
permit 128.140.13.24 0.0.0.0
disallow all requests by user ’abxyz’ from host 128.140.13.24, but
allow all requests by other users from the same host. Switch the order
of the two lines and even requests by user ’abxyz’ are granted.
The shell_cmd field specifies a command string that is executed when
the conditions on that line are satisfied. The following substitutions
occur before the string is presented to the Borne shell for execution:
%A -- replaced by the client host’s domainname if known, by its IP address otherwise
%a -- replaced by the client host’s IP address
%c -- replaced by "connect" or "bind", the command sockd is asked to execute
%p -- replaced by the process id of sockd
%S -- replaced by the service name (e.g., ftp) if known, by the destination port number otherwise
%s -- replaced by the destination port number
%U -- replaced by the user-id reported by identd
%u -- replaced by the user-id reported by the client program
%Z -- replaced by the destination host’s domainname if known, by its IP address otherwise
%z -- replaced by the destination host’s IP address
%% -- replaced by a single %
Several shell commands can be strung together in the usual way. For
example,
/usr/ucb/finger @%A | /usr/ucb/mail -s ’SOCKS: rejected %u@%A to %Z (%S)’ root root@%A
will finger the client host and pipe the result into an email message
for superusers at the server host and the client host with an
appropriate Subject line. Most often this feature is used with a deny
line, but it can be used with permit also.
Although there is an implied ’deny all’ at the end of the configuration
file, you may supply one explicitly so as to take some specific action
when requests are so rejected, e.g., (in one continuous line),
deny 0.0.0.0 0.0.0.0 : /usr/ucb/finger @%A |
/usr/ucb/mail -s ’SOCKS: rejected %u@%A to %Z (%S)’ root root@%A
You may also specify in /etc/sockd.conf commands to be executed when
sockd cannot connect to client’s identd or when the user-ids reported
by the client programs and the client’s identd do not match. These
special entries must have #NO_IDENTD: and #BAD_ID: at the very
beginning of the line, followed by the shell commands to be executed.
For example:
#NO_IDENTD: /usr/ucb/mail -s ’Please run identd on host %A’ root@%A
#BAD_ID: finger @%A | /usr/ucb/mail -s ’%U pretends to be %u on %A’ root root@%A
Strictly speaking, sockd has no concept of inside/outside, it does know
which is the requesting host and which the destination and that is the
basis of its access control. Therefore it can be used to facilitate
access from outside world into your internal networks as well. Needless
to say, you have to take extreme caution if you choose to do so. If you
don’t need that kind of access, it is recommended that you specifically
deny such connections in sockd.conf. For example, if the Class B IP
network 129.1 is your internal network, use
deny 0.0.0.0 0.0.0.0 129.1.0.0 255.255.0.0
as the first line of your sockd.conf to protect your inside hosts from
all attempts of access from the outside world through SOCKS. If your
internal network consists of several IP networks, you have to use one
such line for each of them. In that case, it may be more convenient to
use domain name instead, for instance,
deny 0.0.0.0 0.0.0.0 .myowm.com 0.0.0.0
or
deny ALL 0.0.0.0 .myown.com 0.0.0.0
may be used, assuming that myown.com is your domain.
Though the use of domain names can be very convenient and can also
reduce start-up overhead by reducing the number of lines in the
configuration file, you should be very careful with your DNS (Domain
Name System) setup. Here are some details that you should know.
The original information the SOCKS server has of the source or the
destination host is in the form of its IP address. The SOCKS server
does a reverse DNS lookup to find the domain name correspodning to that
IP address. It then does a normal DNS loopkup to translate the domain
name back to an IP address. If the two IP addresses match, the SOCKS
server retains both the domain name and the IP address as identifier of
the host, and will use whichever as appropriate when it checkes the
configuration file. If either of the two DNS lookups fails or if the
two IP addresses do not match, SOCKS server retains only the original
IP address as the only identifier of the host, with the consequence
that it will not match any line in the configuration file which
specifies a domain name (other than ALL) in the corresponding address
field.
Suppose now you add a new host to your internal network before updating
your nameserver’s data with both the A record and the PTR record of the
new host. When the SOCKS server receives a request with the IP address
of the new host as its destination, at least one of the DNS lookups
will fail. Consequently it will not be protected by lines in which the
domain name is used in the destination address field.
So, if you want to use domain name in the configuration file, be very
sure that you always keep your DNS information up-to-date. It’s
probably a good idea to update your DNS data before adding a new host
to your network. Also make sure that your SOCKS server always queries a
nameserver which has the most up-to-date information of your internal
network.
You have the option of using the frozen configuration file
/etc/sockd.fc instead of /etc/sockd.conf. The frozen file is produced
by make_sockdfc and is essentially the memeory image of the parsed
configuration file. Using it can reduce the start-up delay of the SOCKS
server since it eliminates the need for parsing.
When the SOCKS server starts, it always looks for the frozen
configuration first and reverts to the unfrozen version only if no
frozen configuration is found. All modifications to the configuration
must be done on the plain-text, unfrozen file. Be sure that you run
make_sockdfc every time after you modify /etc/sockd.conf or your SOCKS
server would be using the frozen version of an older configuration.
SEE ALSO
dump_sockdfc(8), make_sockdfc(8), sockd(8), socks.conf(5), sockd.fc(5),
May 6, 1996