Resource Management

This page describes how to do use Dantes session and bandwidth modules to control client resource usage at the SOCKS server.

The official BSD licensed distribution of Dante includes a SOCKS server with all functionality required to interact with SOCKS clients. Some additional functionality is however offered as modules that can be purchased separately. The session module can be used to limit the number of simultaneous sessions or connections going through the server. The bandwidth module similarly controls bandwidth usage.

Both session and bandwidth limitation is configured in the pass statements in the server configuration file. As a result, they can be used in combination with other keywords that are available in these rules, including source and destination addresses, protocols, and authentication information such as user and group identities. Typical usage scenarios include limiting the resources available to different users or services.

Session limitation

A session is defined as an active connection to the SOCKS server. A limit on the number of simultaneous sessions can be put in place for a pass statement by adding the maxsessions keyword.

Port (service) based limitation

# limit the number of concurrent outgoing HTTP connections to a particular
# web site.
pass {  
        from: 0.0.0.0/0 to: .youtube.com port http
        command: connect
        log: error # connect disconnect iooperation
        maxsessions: 10
}

# no limit for other sessions.
pass {  
        from: 0.0.0.0/0 to: 0.0.0.0/0
        command: bind connect udpassociate
        log: error # connect disconnect iooperation
}

The example above shows how the number of active HTTP sessions can be limited. The rule uses the port number to classify sessions as being HTTP sessions; connections to HTTP servers running on different ports will thus not be included or limited. Conversely, clients that use HTTP port for other purposes will similarly be classified as using HTTP.

The second pass statement matches all other connect commands, ensuring that no limitations are placed on other services.

It is also possible to use the maxsessions keyword in client pass statements, but these only apply while the SOCKS protocol negotiation is ongoing and is of limited use in most cases. For general usage, the maxsession keyword should only be used in the SOCKS command pass rules.

User based limitation

#limit the number of sessions from group of users.  This example
#forces the SOCKS users to authenticate to the SOCKS server, which
#is useful if the group of users initiate sessions from unknown
#IP addresses.  The group "badusers" will in this case share a total
#of 30 sessions.
pass {  
        from: 0.0.0.0/0 to: 0.0.0.0/0
        command: bind connect udpassociate
        log: error # connect disconnect iooperation
	group: badusers
	method: authmethod
        maxsessions: 30
}

#generic pass statement for other users, with a higher limit.
pass {  
        from: 0.0.0.0/0 to: 0.0.0.0/0
        command: bind connect udpassociate
        log: error # connect disconnect iooperation
	method: authmethod
        maxsessions: 300
}

The user and group keywords can be used with authentication to limit the number of active sessions based on the authentication information available.

The second pass statement allows a higher limit for all other users. Note that both of the limitations in this example apply to the combined resource usage of all matched users, not each user separately. Unless there are other pass statements, there will never be more than 330 active sessions in the server with this configuration.

Bandwidth limitation

Bandwidth limiting works in the same way as session limitation, but the resource being limited is bandwidth rather than connections. The bandwidth keyword is used to specify the upper limit on bandwidth in bytes per second. This keyword is added in pass rules, in order to impose an upper limit on bandwidth for all matching communication.

Port (service) based limitation

#limit the bandwidth of ongoing HTTP connections
pass {  
        from: 0.0.0.0/0 to: 0.0.0.0/0 port http
        command: connect
        log: error # connect disconnect iooperation
	bandwidth: 102400 #100kbps
}

#generic pass statement for the other sessions, with no bandwidth limit.
pass {  
        from: 0.0.0.0/0 to: 0.0.0.0/0
	command: bind connect udpassociate
        log: error # connect disconnect iooperation
}

The example above shows how bandwidth of HTTP traffic can be limited. The rule uses the port number to classify sessions as being HTTP sessions; connections to HTTP servers running on different ports will not be included or limited. Conversely, clients that use HTTP port for other purposes will similarly be classified as using HTTP.

The second pass statement matches all other sessions, ensuring that no limitations are placed on other services.

pass {
   from: 0.0.0.0/0 to: 10.0.0.2/32
   command: bindreply udpreply
   bandwidth: 10240 #10kbps
}

To limit traffic over connections made to a bound port, a limit can be placed on the bindreply and udpreply commands. In the example above, all traffic going to the internal machine 10.0.0.2, via ports bound with bind or udpassociate, will be rate limited. Note that a separate rule will be needed to limit traffic going in the opposite direction, from 10.0.0.2 to external machines.

User based limitation

#limit the number of sessions from a group of users.
pass {  
        from: 0.0.0.0/0 to: 0.0.0.0/0
        command: bind connect udpassociate
        log: error # connect disconnect iooperation
	group: badusers
	method: authmethod
        bandwidth: 102400 #100kbps
}

#generic pass statement - bind/outgoing traffic
pass {  
        from: 0.0.0.0/0 to: 0.0.0.0/0
        command: bind connect udpassociate
        log: error # connect disconnect iooperation
        bandwidth: 1024000 #1mbps
	method: authmethod
}

The user and group keywords can be used along with authentication to limit bandwidth for specific sets of users. The second pass statement allows a higher limit for all other users.