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.
• Immediately report all service crashes to the developers.
• Participate in code audit :)