-
Notifications
You must be signed in to change notification settings - Fork 66
/
sockd.conf
294 lines (248 loc) · 8.55 KB
/
sockd.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
#
# A sample sockd.conf
#
#
# The config file is divided into three parts;
# 1) server settings
# 2) rules
# 3) routes
#
# The recommended order is:
# Server settings:
# logoutput
# internal
# external
# socksmethod
# clientmethod
# users
# compatibility
# extension
# timeout
# srchost
#
# Rules:
# client block/pass
# from to
# libwrap
# log
#
# block/pass
# from to
# socksmethod
# command
# libwrap
# log
# protocol
# proxyprotocol
#
# Routes:
# the server will log both via syslog, to stdout and to /var/log/sockd.log
#logoutput: syslog stdout /var/log/sockd.log
logoutput: stderr
# 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
internal: 0.0.0.0 port = 1080
# all outgoing connections from the server will use the IP address
# 195.168.1.1
#external: 192.168.1.1
external: eth0
external.rotation: route
# list over acceptable authentication methods, order of preference.
# An authentication method not set here will never be selected.
#
# If the socksmethod field is not set in a rule, the global
# socksmethod is filled in for that rule.
#
# methods for socks-rules.
#socksmethod: username none #rfc931
socksmethod: username none # No authentication.
# methods for client-rules.
clientmethod: none # No authentication.
#or if you want to allow rfc931 (ident) too
#socksmethod: username rfc931 none
#or for PAM authentication
#socksmethod: pam
#
# User identities, an important section.
#
# 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.unprivileged: sockd
# If you are not using libwrap, no need for the below line, so leave
# it commented.
# If you compiled with libwrap support, what userid should it use
# when executing your libwrap commands? "libwrap".
#user.libwrap: libwrap
#
# Some options to help clients with compatibility:
#
# when a client connection comes in the socks server will try to use
# the same port as the client is using, when the socks server
# goes out on the clients behalf (external: IP address).
# If this option is set, Dante will try to do it for reserved ports as well.
# This will usually require user.privileged to be set to "root".
#compatibility: sameport
# If you are using the Inferno Nettverk bind extension and have trouble
# running servers via the server, you might try setting this.
#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.
#timeout.negotiate: 30 # on a lan, this should be enough.
# 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".
#timeout.io: 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 dns info?
#srchost: nodnsunknown nodnsmismatch
#
# 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 socks server 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
# socks request.
#
# "from:" is the source address in both contexts.
#
#
# The "client" rules.
#
# Allow everyone to connect to this server.
client pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error # disconnect
}
# Allow all operations for connected clients on this server.
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: bind connect udpassociate
log: error # connect disconnect iooperation
#socksmethod: username
}
# Allow all inbound packets.
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: bindreply udpreply
log: error # connect disconnect iooperation
}
# Other sample rules below, supposing that 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
# clientmethod: rfc931 # match all idented users that also are in passwordfile
#}
# This is identical to above, but allows clients without a rfc931 (ident)
# too. In practice this means the socks server 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.
#socks block {
# from: 0.0.0.0/0 to: lo0
# log: connect error
#}
# the people at the 172.16.0.0/12 are bad, no one should talk to them.
# log the connect request and also provide an example on how to
# interact with libwrap.
#socks block {
# from: 0.0.0.0/0 to: 172.16.0.0/12
# libwrap: spawn finger @%a
# log: connect error
#}
# unless you need it, you could block any bind requests.
#socks 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.
#socks 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 packet based.
# 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.
#socks 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".
#socks pass {
# from: 10.0.0.0/8 to: .example.com port = http
# log: connect error
# clientmethod: username
#}
# block any other http connects to the example.com domain.
#socks 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.
#socks 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
#socks block {
# from: 0.0.0.0/0 to: 0.0.0.0/0
# log: connect error
#}
# route all http connects via an upstream socks server, aka "server-chaining".
#route {
# from: 10.0.0.0/8 to: 0.0.0.0/0 port = http via: socks.example.net port = socks
#}