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.
|