diff options
Diffstat (limited to 'net-proxy/dante/files/sockd.conf')
| -rw-r--r-- | net-proxy/dante/files/sockd.conf | 243 |
1 files changed, 243 insertions, 0 deletions
diff --git a/net-proxy/dante/files/sockd.conf b/net-proxy/dante/files/sockd.conf new file mode 100644 index 000000000000..70b18747ba34 --- /dev/null +++ b/net-proxy/dante/files/sockd.conf @@ -0,0 +1,243 @@ +# The configfile is divided into two parts; first serversettings, +# then the rules. +# +# The recommended order is: +# Serversettings: +# logoutput +# internal +# external +# method +# clientmethod +# users +# compatibility +# extension +# connecttimeout +# iotimeout +# srchost +# +# Rules: +# client block/pass +# from to +# log +# +# block/pass +# from to +# method +# command +# log +# protocol +# proxyprotocol + +# the server will log both via syslog, to stdout and to /var/log/lotsoflogs +#logoutput: syslog stdout /var/log/lotsoflogs +logoutput: syslog + +# The server will bind to the address 10.1.1.1, port 1080 and will only +# accept connections going to that address. +#internal: 10.1.1.1 port = 1080 +# Alternatively, the interface name can be used instead of the address. +#internal: eth0 port = 1080 + +# all outgoing connections from the server will use the IP address +# 195.168.1.1 +#external: 192.168.1.1 + +# list over acceptable methods, order of preference. +# A method not set here will never be selected. +# +# If the method field is not set in a rule, the global +# method is filled in for that rule. +# + +# methods for socks-rules. +#method: username none #rfc931 + +# methods for client-rules. +#clientmethod: none + +#or if you want to allow rfc931 (ident) too +#method: username rfc931 none + +# +# An important section, pay attention. +# + +# when doing something that can require privilege, +# it will use the userid "sockd". +user.privileged: sockd + +# when running as usual, +# it will use the unprivileged userid of "sockd". +user.notprivileged: sockd + +# +# some options to help clients with compatibility: +# + +# when a client connection comes in the socksserver will try to use +# the same port as the client is using, when the socksserver +# goes out on the clients behalf (external: IP address). +# If this option is set, Dante will try to do it for reserved ports aswell. +# This will usually require user.privileged to be set to "root". +#compatibility: sameport + +# If you are using the bind extension and have trouble running servers +# via the server, you might try setting this. The consequences of it +# are unknown. +#compatibility: reuseaddr + +# +# The Dante server supports some extensions to the socks protocol. +# These require that the socks client implements the same extension and +# can be enabled using the "extension" keyword. +# +# enable the bind extension. +#extension: bind + + +# +# +# misc options. +# + +# how many seconds can pass from when a client connects til it has +# sent us it's request? Adjust according to your network performance +# and methods supported. +#connecttimeout: 30 # on a lan, this should be enough if method is "none". + +# how many seconds can the client and it's peer idle without sending +# any data before we dump it? Unless you disable tcp keep-alive for +# some reason, it's probably best to set this to 0, which is +# "forever". +#iotimeout: 0 # or perhaps 86400, for a day. + +# do you want to accept connections from addresses without +# dns info? what about addresses having a mismatch in dnsinfo? +#srchost: nounknown nomismatch + +# +# The actual rules. There are two kinds and they work at different levels. +# +# The rules prefixed with "client" are checked first and say who is allowed +# and who is not allowed to speak/connect to the server. I.e the +# ip range containing possibly valid clients. +# It is especially important that these only use IP addresses, not hostnames, +# for security reasons. +# +# The rules that do not have a "client" prefix are checked later, when the +# client has sent its request and are used to evaluate the actual +# request. +# +# The "to:" in the "client" context gives the address the connection +# is accepted on, i.e the address the socksserver is listening on, or +# just "0.0.0.0/0" for any address the server is listening on. +# +# The "to:" in the non-"client" context gives the destination of the clients +# socksrequest. +# +# "from:" is the source address in both contexts. +# + + +# the "client" rules. All our clients come from the net 10.0.0.0/8. +# + +# Allow our clients, also provides an example of the port range command. +#client pass { +# from: 10.0.0.0/8 port 1-65535 to: 0.0.0.0/0 +# method: rfc931 # match all idented users that also are in passwordfile +#} + +# This is identical to above, but allows clients without a rfc931 (ident) +# too. In practise this means the socksserver will try to get a rfc931 +# reply first (the above rule), if that fails, it tries this rule. +#client pass { +# from: 10.0.0.0/8 port 1-65535 to: 0.0.0.0/0 +#} + + +# drop everyone else as soon as we can and log the connect, they are not +# on our net and have no business connecting to us. This is the default +# but if you give the rule yourself, you can specify details. +#client block { +# from: 0.0.0.0/0 to: 0.0.0.0/0 +# log: connect error +#} + + +# the rules controlling what clients are allowed what requests +# + +# you probably don't want people connecting to loopback addresses, +# who knows what could happen then. +#block { +# from: 0.0.0.0/0 to: 127.0.0.0/8 +# log: connect error +#} + +# the people at the 172.16.0.0/12 are bad, no one should talk to them. +# log the connect request. +#block { +# from: 0.0.0.0/0 to: 172.16.0.0/12 +# log: connect error +#} + +# unless you need it, you could block any bind requests. +#block { +# from: 0.0.0.0/0 to: 0.0.0.0/0 +# command: bind +# log: connect error +#} + +# or you might want to allow it, for instance "active" ftp uses it. +# Note that a "bindreply" command must also be allowed, it +# should usually by from "0.0.0.0/0", i.e if a client of yours +# has permission to bind, it will also have permission to accept +# the reply from anywhere. +#pass { +# from: 10.0.0.0/8 to: 0.0.0.0/0 +# command: bind +# log: connect error +#} + +# some connections expect some sort of "reply", this might be +# the reply to a bind request or it may be the reply to a +# udppacket, since udp is packetbased. +# Note that nothing is done to verify that it's a "genuine" reply, +# that is in general not possible anyway. The below will allow +# all "replies" in to your clients at the 10.0.0.0/8 net. +#pass { +# from: 0.0.0.0/0 to: 10.0.0.0/8 +# command: bindreply udpreply +# log: connect error +#} + + +# pass any http connects to the example.com domain if they +# authenticate with username. +# This matches "example.com" itself and everything ending in ".example.com". +#pass { +# from: 10.0.0.0/8 to: .example.com port = http +# log: connect error +# method: username +#} + +# block any other http connects to the example.com domain. +#block { +# from: 0.0.0.0/0 to: .example.com port = http +# log: connect error +#} + +# everyone from our internal network, 10.0.0.0/8 is allowed to use +# tcp and udp for everything else. +#pass { +# from: 10.0.0.0/8 to: 0.0.0.0/0 +# protocol: tcp udp +#} + +# last line, block everyone else. This is the default but if you provide +# one yourself you can specify your own logging/actions +#block { +# from: 0.0.0.0/0 to: 0.0.0.0/0 +# log: connect error +#} |