A Restricted SOCKS5 Server with Dante

Dante applies two access checks: a client rule admits an incoming source, and a SOCKS rule permits the requested destination and command. This Dante 1.4.4 example allows one client to reach one controlled destination on port 443.

Service identity and addresses

Create a dedicated low-privilege account if the installation does not provide one:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin danteproxy

Both identities can use this account for the high-port, source-allowlisted configuration below. Password authentication or privileged features require reviewing those settings again. Replace all documentation addresses before use.

logoutput: stderr
internal: 192.0.2.10 port = 1080
external: 192.0.2.10
clientmethod: none
socksmethod: none
user.privileged: danteproxy
user.unprivileged: danteproxy

client pass {
    from: 198.51.100.27/32 to: 192.0.2.10/32 port = 1080
    log: connect error
}

socks pass {
    from: 198.51.100.27/32 to: 203.0.113.20/32 port = 443
    command: connect
    log: connect error
}

internal selects the client-facing listener; external selects the outbound address. A single-interface server can use the same assigned address for both. An interface name can also be used where appropriate; check which addresses it expands to.

What this policy permits

The first rule admits the specified source to the listener. The second permits only CONNECT to the specified target. Unmatched requests remain blocked, including BIND and UDP ASSOCIATE.

The method settings provide no username authentication. Access depends on the narrow source rule and its network boundary. This arrangement is suitable only where that source identifies an authorized client.

sockd -V -f /path/to/sockd.conf

Some distributions name the executable danted. Check the configuration using the installed command before starting the service. Apply matching source restrictions at the firewall, then test both the allowed target and a controlled target that should be denied.