Recipe 3.7 Restricting Access by Remote Users

3.7.1 Problem

You want only particular remote users to have access to a TCP service. You cannot predict the originating hosts .

3.7.2 Solution

Block the service's incoming TCP port with a firewall rule [Recipe 2.6], run an SSH server, and permit users to tunnel in via SSH port forwarding. Thus, SSH authentication will permit or deny access to the service. Give your remote users SSH access by public key.

For example, to reach the news server (TCP port 119) on your site server.example.com , a remote user on host myclient could consruct the following tunnel from (arbitrary) local port 23456 to the news server via SSH:

myclient$ ssh -f -N -L 23456:server.example.com:119 server.example.com

and then connect to the tunnel, for example with the tin newsreader:

myclient$ export NNTPSERVER=localhost
myclient$ tin -r -p 23456

3.7.3 Discussion

SSH tunneling, or port forwarding, redirects a TCP connection to flow through an SSH client and server in a mostly-transparent manner. ^[1] [Recipe 6.14] This tunnel connects from a local port to a remote port, encrypting traffic on departure and decrypting on arrival. For example, to tunnel NNTP (Usenet news service, port 119), the newsreader talks to an SSH client, which forwards its data across the tunnel to the SSH server, which talks to the NNTP server, as in Figure 3-2.

^[1] It's not transparent to services sensitive to the details of their sockets, such as FTP, but in most cases the communication is fairly seamless.

Figure 3-2. Tunneling NNTP with SSH

By blocking a service's port (119) to the outside world, you have prevented all remote access to that port. But SSH travels over a different port (22) not blocked by the firewall.

Alternatively, investigate whether your given service has its own user authentication. For example, wu- ftpd has the file /etc/ftpaccess , sshd has its AllowUsers keyword, and so forth.

3.7.4 See Also

ssh(1), sshd(8), tin(1).

Recipe 3.8 Restricting Access by Remote Hosts (xinetd)

3.8.1 Problem

You want only particular remote hosts to access a TCP service via xinetd .

3.8.2 Solution

Use xinetd.conf 's only_from and no_access keywords:

service ftp
{
        only_from = 192.168.1.107
        ...
}

service smtp
{
        no_access = haxor.evil.org
        ...
}

Then reset xinetd so your changes take effect. [Recipe 3.3]

3.8.3 Discussion

This is perhaps the simplest way to specify access control per service. But of course it works only for services launched by xinetd .

only_from and no_access can appear multiple times in a service entry:

{
        no_access = haxor.evil.org

deny a particular host

no_access += 128.220.

deny all hosts in a network

...
}

If a connecting host is found in both the only_from and no_access lists, xinetd takes one of the following actions:

If the host matches entries in both lists, but one match is more specific than the other, the more specific match prevails. For example, 128.220.13.6 is more specific than 128.220.13.
If the host matches equally specific entries in both lists, xinetd considers this a configuration error and will not start the requested service.

So in this example:

service whatever
{
        no_access = 128.220.     haxor.evil.org    client.example.com
        only_from = 128.220.10.  .evil.org         client.example.com
}

connections from 128.220.10.3 are allowed, but those from 128.220.11.2 are denied . Likewise, haxor.evil.org cannot connect, but any other hosts in evil.org can. client.example.com is incorrectly configured, so its connection requests will be refused . Finally, any host matching none of the entries will be denied access.