Back to 3proxy

Securityen

doc/html/securityen.html

0.9.93.2 KB
Original Source

3proxy Security Considerations

  • Never install 3proxy suid. If you need it to run suid, write a wrapper with a fixed configuration file.
  • Make the configuration file accessible only to the account 3proxy starts with.
  • Under Windows, if 3proxy is used as a service, create a new unprivileged local account without "logon locally" rights. Assign this account to the 3proxy service.
  • Under Unix, use chroot to jail 3proxy (make sure files included in the configuration file after the 'chroot' command, if any, are available from within the jail).
  • Under Unix, either start 3proxy with an unprivileged account or, if you need some privileged ports to be used by 3proxy, use setgid/setuid commands inside 3proxy.cfg immediately after the last occurrence of a service bound to a privileged port in the configuration file (setgid must precede setuid).
  • Always use full paths in the configuration file.
  • Try to avoid 'strong' authentication, because only cleartext authentication is currently available.
  • Always specify internal and external interfaces.
  • Always limit connections to the internal network and localhost (to 127.0.0.1 and all interfaces) with ACLs. Be careful, because the BIND command in SOCKS requires the BIND method with the external interface IP address to be allowed.
  • Before 3proxy 0.8, always use nserver and nscache under Unix; otherwise, a DoS attack is possible with an unreachable DNS server (because gethostbyname will block other threads).
  • Keep logs in a secure location, because some confidential information from user requests can be logged.
  • Use -xyz+A character filtering sequences for 'logformat', especially with ODBC logging, to prevent SQL and log record injections.
  • With the 'cacheacl' authentication type the ACL result is cached and is not re-evaluated on a cache hit, so every field the ACL limits must be a part of the 'authcache' key. Any field the ACL limits but the key does not contain makes the cached result apply to a request it was not computed for, and that limitation is not enforced. Use 'user' and 'pass' for the userlist, 'ip' for the sourcelist, 'dstaddr' and 'dsthost' for the targetlist, 'dstport' for the targetportlist and 'dstoper' for the operationlist. Use plain 'cache' instead of 'cacheacl' if ACLs may change during the cache lifetime; cache entries are not invalidated by a configuration reload.
  • 'cacheacl' must not be used together with parent proxies. The ACL is not walked on a cache hit, so no redirection is applied and the request is sent directly instead of through the 'parent' proxy of the matching ACL entry, without any error. If the parent proxy is the only sanctioned path to the network, this silently bypasses it. Use 'cache' instead. 'parent ... extip' is the only redirection which survives, and only if 'ext' is a part of the 'authcache' key.
  • The destination of every datagram of a SOCKSv5 UDP association is authorized, but only with the default '-U3' (or '-U2') of the 'socks' service. With '-U0' or '-U1' only the first destination of an association is authorized, so ACLs limiting the destination do not restrict the rest of the association.
  • Immediately report all service crashes to the developers.
  • Participate in code audit :)