Fine-grained tunneling restrictions

'Tunneling' or 'port forwarding' refers to the ability of an SSH client (a) to have the SSH server initiate a TCP/IP connection to another server on the SSH client's behalf (called client-to-server tunneling), or (b) to have the SSH server accept incoming TCP/IP connections on a server's interface and port and forward those connections to the client (called server-to-client port forwarding). (You can learn more in our Short guide to SSH port forwarding.)

If your requirements are simple, Bitvise SSH Server provides two easy ways to control a user's or group's access to tunneling. In the Bitvise SSH Server settings entry for the account or group, there are fields Permit C2S port forwarding and Permit S2C port forwarding. Disable the first and the user will not be able to tell the SSH server to initiate outbound connections. Disable the second and the user will not be able to instruct the SSH server to listen for connections to forward to the SSH client.

Sometimes, such simple controls are not sufficient. For example, you may want to allow the user to use port forwarding to access a service provided by a particular machine on the server's local network; but you don't want to allow the user to use this capability to access any server on the internet, e.g. as a proxy for web browsing.

Such fine-grained control is provided by the Connect rules and Listening rules settings available in Bitvise SSH Server Advanced settings, separately for each group or account settings entry.

Connect rules

Connect rules control what destinations the SSH client will be able to connect to using client-2-server port forwarding. There are four types of connect rules: those that match IPv4 addresses, IPv4 addresses, DNS names, and a separate rule type that matches everything.

An IPv4 rule allows you to specify either a complete IP address (significant bits = 32) or a whole subnet (significant bits = 8 for 255.0.0.0, 16 for 255.255.0.0 or 24 for 255.255.255.0). The IP address 0.0.0.0 with significant bits = 0 will match any destination, and is equivalent to a match-all rule.

IPv6 rules work similarly to IPv4 rules, except that there are up to 128 significant bits.

A DNS name rule allows you to specify a destination either using a specific DNS name or a wildcard of the form *.com, *.bitvise.com or *.research.bitvise.com. A lone wildcard (just *) will match any destination, and is equivalent to a match-all rule.

Bitvise SSH Server processes Connect rules in the order they are configured. When the first match is found, the action configured for that rule is taken, and no further rules are searched.

If Bitvise SSH Server gets a client-to-server tunneling request for which there is no match in the account's Connect rules, the Connect rules of the corresponding group settings entry will be processed. If no match is found in the group Connect rules either, the connection is rejected.

By default, the Connect rule list for a group contains a single entry allowing access to all destinations if 'Permit C2S port forwarding' for the user is true. An account's Connect rule list is empty by default, passing all decisions to Connect rules defined for the user's group.

Listen rules

Listen rules control what server interfaces and ports the user will be able to bind in order to accept connections and forward them to the SSH client. There is a separate list of listening rules for IPv4 and IPv6 requests.

A listen rule identifies an IP address of one of the server's network interfaces, and a port range for which the SSH client is allowed or denied listening. The special address 0.0.0.0 for IPv4, or "::" for IPv6, matches any interface.

A listen rule may contain additional Accept rules which control the origin hosts from which connections to the interface and port range defined in the listen rule will be accepted. By default, the accept rule list contains a single entry allowing connections from all sources.

If Bitvise SSH Server gets a server-to-client tunneling request for which there is no match in the account's Listen rules, the Listen rules of the account's group settings entry will be processed. If no match is found in the group Listen rules either, the tunneling attempt is rejected.

By default, the Listen rule list for a group contains a single entry allowing all interfaces and ports to be bound if 'Permit S2C port forwarding' for the user is true. An account's Listen rule list is empty by default, passing all decisions to Listen rules defined for the user's group.

Example 1: Permit a client-to-server destination

Suppose your SSH server resides on machine 10.10.10.5 in your internal network, and you wish to allow the user to connect, via SSH tunneling, to a Remote Desktop service running on machine 10.10.10.16. You would first need to decide whether to configure this policy for the user's group or for the individual user. If for the individual user, you would need to add a Bitvise SSH Server account settings entry for the user if one does not yet exist. Then, in Advanced settings, you would open the group or account settings entry that you wish to configure this restriction for, and perform the following:

  1. Add 'allow' rule for client-2-server connections:
    1. open the 'Connect rules' list and click Add
    2. under Address type, select IPv4
    3. under IPV4 Address, input the IP address of the server to which the user is allowed to connect - in our example, 10.10.10.16
    4. under Significant bits, enter 32 to specify that the IP address in this case identifies an individual IP (10.10.10.16), not a subnet (e.g. 24 for 10.10.10.x)
    5. under Port range rule, set 'Port from' to the RDP port (3389), and 'Port to' to the same value
    6. under Instructions, enable the 'Allow connect' setting, and leave the rest at defaults
    7. click OK to confirm and add the configured rule
  2. Add a 'deny' rule for other client-2-server connections:
    1. click Add in 'Connect rules'
    2. the default will be a rule that covers all connections. Disable the 'Allow connect' setting, and click OK to add the rule.

In this example, if you wanted to prohibit the user from setting up any kind of server-to-client port forwarding whatsoever, you would simply set 'Permit S2C port forwarding' to false. Otherwise, if you wanted to configure a specific range of ports and interfaces where the SSH client may instruct the SSH server to listen, you would add appropriate Listen rules as in the Example 2 (below).

Example 2: Permit a server-to-client binding

Suppose your SSH server machine has two network interfaces: 10.10.10.5 is the private IP address in the local area network and 123.23.12.111 is the server's public IP address on the internet. You know that the user who will be logging into the SSH server will need to run a program on the server side which will initiate a TCP connection to the client, and the user will achieve this using server-to-client port forwarding. You want to allow the user to forward connections from the server's local network through the server's 10.10.10.5 private network interface, as well as from the server itself using the 127.0.0.1 loopback interface, but you do not wish to allow the user to listen for connections from the internet through interface 123.23.12.111. You also want to restrict the user to listening only on ports 1024-65535.

Again, you would first need to decide whether to configure this policy for the user's group or for the individual user. If for the individual user, you would need to add a Bitvise SSH Server account settings entry for the user if one does not yet exist. Then, in Advanced settings, you would open the group or account settings entry that you wish to configure this restriction for, and perform the following:

  1. Add 'allow' listening rule for 10.10.10.5:
    1. open 'Listening rules: IPv4' and click Add
    2. under IPv4 Address, input the IP address of the interface - in our example, 10.10.10.5
    3. under Port range, enter 1024 into 'Port from' and 65535 into 'Port to'
    4. enable the 'Allow listening' checkbox
    5. under Instructions, enable the 'Allow connect' setting and leave the rest at default values
    6. click OK to confirm and add the configured rule
  2. Add 'allow' listening rule for 127.0.0.1:
    1. repeat steps under 1, but using 127.0.0.1 instead of 10.10.10.5. You should now have 2 listening rules.
  3. Add 'deny' rule for other listening interfaces:
    1. click Add in 'Listening rules: IPv4'
    2. the default will be a rule that covers all IPv4 listening interfaces and all ports. Disable the 'Allow connect' setting, and click OK to add the rule.
  4. Add a 'deny' rule for IPv6:
    1. click Add in 'Listening rules: IPv6'
    2. the default will be a rule that covers all IPv6 listening interfaces and all ports. Disable the 'Allow connect' setting, and click OK to add the rule. Since you're not using any IPv6 interfaces, this will be the only IPv6 Listening rule.

In this example, if you wanted to prohibit the user from setting up any kind of client-to-server forwardings whatsoever, you would simply set 'Permit C2S port forwarding' to false. Otherwise, if you wanted to configure a specific range of destination servers and their ports to which the SSH client may connect, you would add appropriate Connect rules as in Example 1 (above).