# $Id: sockd.conf,v 1.43 2005/12/26 16:35:26 michaels Exp $
#
# A sample danted.conf
#
#
# The configfile is divided into three parts;
#    1) serversettings
#    2) rules
#    3) routes
#
# The recommended order is:
#   Serversettings:
#               logoutput
#               internal
#               external
#               method
#               clientmethod
#               users
#               compatibility
#               extension
#               connecttimeout
#               iotimeout
#        srchost
#
#  Rules:
#    client block/pass
#        from to
#        libwrap
#        log
#
#     block/pass
#        from to
#        method
#        command
#        libwrap
#        log
#        protocol
#        proxyprotocol
#
#  Routes:

# the server will log both via syslog, to stdout and to /var/log/lotsoflogs
logoutput: syslog /var/log/danted
#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 = 8899

# all outgoing connections from the server will use the IP address
# 195.168.1.1
external: мой ип

# 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: none #rfc931

# methods for client-rules.
clientmethod: none

#or if you want to allow rfc931 (ident) too
#method: username rfc931 none

#or for PAM authentification
#method: pam

#
# An important section, pay attention.
#

# when doing something that can require privilege, it will use the
# userid:
user.privileged: root

# when running as usual, it will use the unprivileged userid of:
user.notprivileged: nobody

# If you compiled with libwrap support, what userid should it use
# when executing your libwrap commands?  "libwrap".
user.libwrap: nobody


#
# 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: 300   # 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: 194.67.194.236/24 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: 95.154.88.10/32 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 and also provide an example on how to
# interact with libwrap.
#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.
#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: 194.67.194.236/32
    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: 0.0.0.0/0 to: 0.0.0.0/0
    protocol: tcp udp
        command: bind connect udpassociate
        log: error # connect disconnect iooperation
}

pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        command: bindreply udpreply
        log: error # connect disconnect iooperation
}

# 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
#}

# 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
#}