docker-socks5

1
#
2
# A sample sockd.conf
3
#
4
#
5
# The config file is divided into three parts;
6
#    1) server settings
7
#    2) rules
8
#    3) routes
9
#
10
# The recommended order is:
11
#   Server settings:
12
#               logoutput
13
#               internal
14
#               external
15
#               socksmethod
16
#               clientmethod
17
#               users
18
#               compatibility
19
#               extension
20
#               timeout
21
#               srchost
22
#
23
#  Rules:
24
#        client block/pass
25
#                from to
26
#                libwrap
27
#                log
28
#
29
#     block/pass
30
#                from to
31
#                socksmethod
32
#                command
33
#                libwrap
34
#                log
35
#                protocol
36
#                proxyprotocol
37
#
38
#  Routes:
39

40
# the server will log both via syslog, to stdout and to /var/log/sockd.log
41
#logoutput: syslog stdout /var/log/sockd.log
42
logoutput: stderr
43

44
# The server will bind to the address 10.1.1.1, port 1080 and will only
45
# accept connections going to that address.
46
#internal: 10.1.1.1 port = 1080
47
# Alternatively, the interface name can be used instead of the address.
48
#internal: eth0 port = 1080
49
internal: 0.0.0.0 port = 1080
50

51
# all outgoing connections from the server will use the IP address
52
# 195.168.1.1
53
#external: 192.168.1.1
54
external: eth0
55
external.rotation: route
56

57
# list over acceptable authentication methods, order of preference.
58
# An authentication method not set here will never be selected.
59
#
60
# If the socksmethod field is not set in a rule, the global
61
# socksmethod is filled in for that rule.
62
#
63

64
# methods for socks-rules.
65
#socksmethod: username none #rfc931
66
#socksmethod: username none  # No authentication.
67
socksmethod: username # as described in the repo
68

69
# methods for client-rules.
70
clientmethod: none  # No authentication.
71

72
#or if you want to allow rfc931 (ident) too
73
#socksmethod: username rfc931 none
74

75
#or for PAM authentication
76
#socksmethod: pam
77

78
#
79
# User identities, an important section.
80
#
81

82
# when doing something that can require privilege, it will use the
83
# userid "sockd".
84
#user.privileged: sockd
85

86
# when running as usual, it will use the unprivileged userid of "sockd".
87
user.unprivileged: sockd
88

89
# If you are not using libwrap, no need for the below line, so leave
90
# it commented.
91
# If you compiled with libwrap support, what userid should it use
92
# when executing your libwrap commands?  "libwrap".
93
#user.libwrap: libwrap
94

95

96
#
97
# Some options to help clients with compatibility:
98
#
99

100
# when a client connection comes in the socks server will try to use
101
# the same port as the client is using, when the socks server
102
# goes out on the clients behalf (external: IP address).
103
# If this option is set, Dante will try to do it for reserved ports as well.
104
# This will usually require user.privileged to be set to "root".
105
#compatibility: sameport
106

107
# If you are using the Inferno Nettverk bind extension and have trouble
108
# running servers via the server, you might try setting this.
109
#compatibility: reuseaddr
110

111
#
112
# The Dante server supports some extensions to the socks protocol.
113
# These require that the socks client implements the same extension and
114
# can be enabled using the "extension" keyword.
115
#
116
# enable the bind extension.
117
#extension: bind
118

119

120
#
121
# Misc options.
122
#
123

124
# how many seconds can pass from when a client connects til it has
125
# sent us it's request?  Adjust according to your network performance
126
# and methods supported.
127
#timeout.negotiate: 30   # on a lan, this should be enough.
128

129
# how many seconds can the client and it's peer idle without sending
130
# any data before we dump it?  Unless you disable tcp keep-alive for
131
# some reason, it's probably best to set this to 0, which is
132
# "forever".
133
#timeout.io: 0 # or perhaps 86400, for a day.
134

135
# do you want to accept connections from addresses without
136
# dns info?  what about addresses having a mismatch in dns info?
137
#srchost: nodnsunknown nodnsmismatch
138

139
#
140
# The actual rules.  There are two kinds and they work at different levels.
141
#
142
# The rules prefixed with "client" are checked first and say who is allowed
143
# and who is not allowed to speak/connect to the server.  I.e the
144
# ip range containing possibly valid clients.
145
# It is especially important that these only use IP addresses, not hostnames,
146
# for security reasons.
147
#
148
# The rules that do not have a "client" prefix are checked later, when the
149
# client has sent its request and are used to evaluate the actual
150
# request.
151
#
152
# The "to:" in the "client" context gives the address the connection
153
# is accepted on, i.e the address the socks server is listening on, or
154
# just "0.0.0.0/0" for any address the server is listening on.
155
#
156
# The "to:" in the non-"client" context gives the destination of the clients
157
# socks request.
158
#
159
# "from:" is the source address in both contexts.
160
#
161

162

163
#
164
# The "client" rules.
165
#
166

167
# Allow everyone to connect to this server.
168
client pass {
169
    from: 0.0.0.0/0 to: 0.0.0.0/0
170
    log: connect error  # disconnect
171
}
172

173
# Allow all operations for connected clients on this server.
174
socks pass {
175
    from: 0.0.0.0/0 to: 0.0.0.0/0
176
    command: bind connect udpassociate
177
    log: error  # connect disconnect iooperation
178
    #socksmethod: username
179
}
180
# Allow all inbound packets.
181
socks pass {
182
    from: 0.0.0.0/0 to: 0.0.0.0/0
183
    command: bindreply udpreply
184
    log: error  # connect disconnect iooperation
185
}
186

187
# Other sample rules below, supposing that our clients come from the net 10.0.0.0/8.
188

189
# Allow our clients, also provides an example of the port range command.
190
#client pass {
191
#        from: 10.0.0.0/8 port 1-65535 to: 0.0.0.0/0
192
#        clientmethod: rfc931 # match all idented users that also are in passwordfile
193
#}
194

195
# This is identical to above, but allows clients without a rfc931 (ident)
196
# too.  In practice this means the socks server will try to get a rfc931
197
# reply first (the above rule), if that fails, it tries this rule.
198
#client pass {
199
#        from: 10.0.0.0/8 port 1-65535 to: 0.0.0.0/0
200
#}
201

202

203
# drop everyone else as soon as we can and log the connect, they are not
204
# on our net and have no business connecting to us.  This is the default
205
# but if you give the rule yourself, you can specify details.
206
#client block {
207
#        from: 0.0.0.0/0 to: 0.0.0.0/0
208
#        log: connect error
209
#}
210

211

212
# the rules controlling what clients are allowed what requests
213
#
214

215
# you probably don't want people connecting to loopback addresses,
216
# who knows what could happen then.
217
#socks block {
218
#        from: 0.0.0.0/0 to: lo0
219
#        log: connect error
220
#}
221

222
# the people at the 172.16.0.0/12 are bad, no one should talk to them.
223
# log the connect request and also provide an example on how to
224
# interact with libwrap.
225
#socks block {
226
#        from: 0.0.0.0/0 to: 172.16.0.0/12
227
#        libwrap: spawn finger @%a
228
#        log: connect error
229
#}
230

231
# unless you need it, you could block any bind requests.
232
#socks block {
233
#        from: 0.0.0.0/0 to: 0.0.0.0/0
234
#        command: bind
235
#        log: connect error
236
#}
237

238
# or you might want to allow it, for instance "active" ftp uses it.
239
# Note that a "bindreply" command must also be allowed, it
240
# should usually by from "0.0.0.0/0", i.e if a client of yours
241
# has permission to bind, it will also have permission to accept
242
# the reply from anywhere.
243
#socks pass {
244
#        from: 10.0.0.0/8 to: 0.0.0.0/0
245
#        command: bind
246
#        log: connect error
247
#}
248

249
# some connections expect some sort of "reply", this might be
250
# the reply to a bind request or it may be the reply to a
251
# udppacket, since udp is packet based.
252
# Note that nothing is done to verify that it's a "genuine" reply,
253
# that is in general not possible anyway.  The below will allow
254
# all "replies" in to your clients at the 10.0.0.0/8 net.
255
#socks pass {
256
#        from: 0.0.0.0/0 to: 10.0.0.0/8
257
#        command: bindreply udpreply
258
#        log: connect error
259
#}
260

261

262
# pass any http connects to the example.com domain if they
263
# authenticate with username.
264
# This matches "example.com" itself and everything ending in ".example.com".
265
#socks pass {
266
#        from: 10.0.0.0/8 to: .example.com port = http
267
#        log: connect error
268
#        clientmethod: username
269
#}
270

271

272
# block any other http connects to the example.com domain.
273
#socks block {
274
#        from: 0.0.0.0/0 to: .example.com port = http
275
#        log: connect error
276
#}
277

278
# everyone from our internal network, 10.0.0.0/8 is allowed to use
279
# tcp and udp for everything else.
280
#socks pass {
281
#        from: 10.0.0.0/8 to: 0.0.0.0/0
282
#        protocol: tcp udp
283
#}
284

285
# last line, block everyone else.  This is the default but if you provide
286
# one  yourself you can specify your own logging/actions
287
#socks block {
288
#        from: 0.0.0.0/0 to: 0.0.0.0/0
289
#        log: connect error
290
#}
291

292
# route all http connects via an upstream socks server, aka "server-chaining".
293
#route {
294
# from: 10.0.0.0/8 to: 0.0.0.0/0 port = http via: socks.example.net port = socks
295
#}
296