dante   Frontpage - Dante - Download - Status - Support - Modules - Docs - Links - Survey
 

Authentication

This page provides general information on authentication. Separate pages describe details on each of the supported authentication methods.

Overview

The SOCKS 5 protocol supports authentication, allowing the server to identify the user behind a session. This information can be used in the server for access control, logging, and resource management.

This page builds on the configurations described in the Dante server and client configuration pages, and describes what need to be added or changed in order to authenticate users. This page describes the general principles behind user authentication, and how to use the information on user identities in the server socks rules. For some authentication methods additional setup might be required. Separate pages for each authentication method describe these issues.

All the examples on this page use authmethod as the name of the authentication method in use. It should be replaced with desired authentication method after consulting the page describing any authentication-specific issues.

Adding authentication is relatively simple. The list of acceptable authentication methods are specified in the server configuration file with the clientmethod and method keywords. These can then be used in the client access rules and socks command rules, respectively. If no mention of the authentication method is done in later client and socks-rules, they will default to containing all listed in the global clientmethod and method fields. The global clientmethod and method fields also give the order of preference when the SOCKS client supports several authentication methods and the SOCKS server needs to choose one.

After authentication, the server will include authentication info such as user identity in all log entries, assuming logging is enabled in the server.

Several authentication methods are supported by Dante, with different levels of security provided.

  • rfc931. This methods relies only on the output of the identd daemon on the client machine and will in most usage scenario be insecure, but provides additional information for logging. Data is transmitted unencrypted after authentication.
  • username/pam. These methods verify the client identity with a password. Note that the password is not encrypted; so these methods should only be used if one does not need to worry about eavesdropping on the network between the client and the SOCKS server. Data is transmitted unencrypted after authentication.
  • gssapi. Supports secure authentication and encryption of the data transmitted between the client and the server.

Client access rule authentication

The clientmethod keyword is used to specify authentication methods that should be applied before any SOCKS related protocol negotiation starts. This limits the possible authentication methods to those that are based on only the remote IP address and port number of the packet or connection. Currently, the supported clientmethods are rfc931 and pam.

Client configuration

The clientmethod authentication methods work independently of the configuration of the client. No changes need to be made to the client configuration file.

Server configuration

clientmethod: authmethod

The server configuration file first needs the wanted authentication methods listed after the clientmethod keyword. They should replace the none method used in the minimal server configuration (which permits access without authentication).

#block connections from specified user
# client block {
#         from: 192.0.2.0/24 to: 0.0.0.0/0
#         log: error # connect disconnect
#         user: baduser
#         method: authmethod
# }

#allow connections from authenticated users on internal 192.0.2.0/24 network
client pass {
        from: 192.0.2.0/24 to: 0.0.0.0/0
	log: error # connect disconnect
        method: authmethod
}

The example above shows how to limit access to the server to only authenticated users. Without any other client pass statements, all other connection attempts will be blocked.

The initial client block statement excludes one specifically named user, "baduser". As an alternative to the user keyword, the group keyword can be used to block or pass an entire group of users.

#allow connections from authenticated users in group socksusers
client pass {
        from: 192.0.2.0/24 to: 0.0.0.0/0
	log: error # connect disconnect
        method: authmethod
	group: socksusers
}

The pass statement above limits access to authenticated users in the group socksusers. There is no special group definition file used by Dante, it uses the default system group file (typically /etc/group). This file must be contain the group information for the users.

SOCKS command rule authentication

The method keyword specifies the authentication methods that are accepted during SOCKS 5 authentication method negotiation. The listed methods can be used in the SOCKS command rules.

Client configuration -- Environment based setup

No changes are required to use authentication if no configuration file is used by the client, with the server address being specified with e.g., SOCKS_SERVER. The client will automatically offer all supported methods to the client. There is however no way to limit the methods that are offered, for this a configuration file is needed.

Client configuration -- Environment based setup

#route to SOCKS server, (which supports both SOCKS version 4 and 5)
route {                                                                        
        from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.0.2.1 port = 1080            
        proxyprotocol: socks_v4 socks_v5
#        method: authmethod
}

The client configuration file gives greater control over the authentication methods that are offered. The method keyword can be used in rule statements to specify the authentication method to use. Without any method keyword, the client will offer all supported authentication methods, allowing the server to choose one. This is the recommended way to configure the client because it removes the need to modify the client configuration if the authentication method used by the server is changed. Commenting out the method keyword achieves this.

Server configuration

The server configuration is principally the same as for the client access rules, but are used in the pass/block statements.

method: authmethod

The server configuration file first needs the wanted authentication methods listed after the method keyword. They should replace the none method used in the minimal server configuration.

#block communication with www.example.org for user "baduser".
# block {
#        from: 0.0.0.0/0 to: www.example.org
#        command: bind connect udpassociate
#        log: error # connect disconnect iooperation
#        user: baduser
#        method: authmethod
# }

#generic pass statement for everything and everybody else.
pass {  
        from: 0.0.0.0/0 to: 0.0.0.0/0
        command: bind connect udpassociate
        log: error # connect disconnect iooperation
        method: authmethod
}

The example above shows how to limit access through the SOCKS server to only authenticated users. Without any other pass statements, all other SOCKS requests will be denied.

The initial block statement excludes one specifically named user (baduser). As an alternative to the user keyword, the group keyword can be used to pass or block an entire group of users.

#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
        method: authmethod
	group: socksusers
}

The pass statement above grants access to the listed SOCKS commands for authenticated users in the group socksusers. There is not special group definitions used by Dante, the system group file must be configured with correct group information for this to work.

# block incoming connections/packets from ftp.example.org 
# block {
#        from: ftp.example.org to: 0.0.0.0/0 
#        command: bindreply udpreply
#        log: error # connect disconnect iooperation
# }

# generic pass statement for all other incoming connections/packets
pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        command: bindreply udpreply
        log: error # connect disconnect iooperation
}

The Dante SOCKS server supports two additional commands, bindreply and udpreply. Both apply to traffic originating from external hosts. As a result, there are fewer options available for authentication. It is possible to use authentication methods such as rfc931, but these are not reliable. In general however, this should not be a problem because either command can only occur as a result of an internal client using bind or udpassociate, and both these commands can be authenticated. For this reason, the pass and block statements are kept as above, without authentication.

Should some form of authentication still be desired for bindreply and udpreply, it is possible to specify this by adding a method keyword, in the same way as for the other commands. Note however that the authentication method will need to authenticate external users and that this must be done independently of the SOCKS protocol, using e.g., rfc931.

Full client template for authentication

The recommended template for the client configuration file, in an environment where authentication is required is shown below.

##logging
#logoutput: socks.log
#debug: 1

##dns resolution
#resolveprotocol: tcp  # default                                                

##
## Clienting communication routing
##
#first matched route is used

##direct route to dns server
#route {                                                                        
#        from: 0.0.0.0/0 to: 10.1.1.1/32 port = domain via: direct              
#}                                                                              

## route to proxy server, generally only one is needed

##route to SOCKS server (which supports both SOCKS version 4 and 5)
route {                                                                        
        from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.0.2.1 port = 1080            
        proxyprotocol: socks_v4 socks_v5
#        method: none
}

##route to UPnP server
# route {
#         from: 0.0.0.0/0 to: .example.org
#             via: http://192.0.2.2:1900/InternetGatewayDevice.xml
#         proxyprotocol: upnp
#         method: none
# }

##route to HTTP proxy
#route {                                                                        
#        from: 0.0.0.0/0 to: 0.0.0.0/0 via: 10.1.1.1 port = 3128            
#        command: connect # only thing a httproxy supports.     
#        protocol: tcp
#        proxyprotocol: http_v1.0                                               
#}               

Full server template for authentication

The full recommended template for using the Dante SOCKS server with authentication can be found below. The authmethod1 and authmethod2 values should be changed to the authentication methods that one wishes to use. Some minor changes might be required to the file for some authentication methods. Consult the method-specific pages for details.

The template specifies both clientmethod and method, but using both is not necessary. Generally, authentication based on clientmethod will not be needed and these parts of the template can be ignored.

#logging
logoutput: /var/log/sockd.log
#debug: 1

#server address specification
internal: 192.0.2.1 port = 1080
external: eth1

#server identities (not needed on solaris)
#user.privileged    : root
user.notprivileged : socks
#user.libwrap       : libwrap

#authentication methods
clientmethod: authmethod1
method: authmethod2 authmethod3

##
## SOCKS client access rules
##
#rule processing stops at the first match, no match results in blocking

#block connections from specified user
# client block {
#         from: 192.0.2.0/24 to: 0.0.0.0/0
#         log: error # connect disconnect
#         user: baduser
#         method: authmethod1
# }

#allow connections from authenticated users on internal 192.0.2.0/24 network
client pass {
        from: 192.0.2.0/24 to: 0.0.0.0/0
#         log: error # connect disconnect
        method: authmethod1
}

##
## SOCKS command rules
##
#rule processing stops at the first match, no match results in blocking

#block communication with www.example.org
# block {
#        from: 0.0.0.0/0 to: www.example.org
#        command: bind connect udpassociate
#        log: error # connect disconnect iooperation
#        user: baduser
#        method: authmethod3
# }

#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
        method: authmethod2
}

# block incoming connections/packets from ftp.example.org 
# block {
#        from: ftp.example.org to: 0.0.0.0/0 
#        command: bindreply udpreply
#        log: error # connect disconnect iooperation
# }

# generic pass statement for incoming connections/packets
pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        command: bindreply udpreply
#        log: error # connect disconnect iooperation
}

Copyright © 1998-2017 Inferno Nettverk A/S