Network Computingwww.networkcomputing.com

Once the client workstation decides to invoke Socks for a particular connection, it authenticates with the server, which grants usage permission based on the user or IP address of the client. We're not terribly vigilant about strong authentication for our o utgoing connections because our IP network doesn't use DHCP and IP numbers tend to be static. As long as the IP address is an authorized inside address from an inside interface, we allow it to pass.

Socks5 does support the "ident" protocol (RFC 1413) for user authentication and Kerberos authentication (RFC 1961). This protocol is rather weak authentication, however. If you're thinking about allowing outside connections, you should use Kerberos or third-party Socks server modules that provide Windows NT Domain and NDS authentication.

We use Socks5 in concert with other proxies when appropriate. For example, we use Novell GroupWise 5's SMTP gateway, which is not a proxy by nature, but when multihomed, acts as an SMTP proxy. We've configured it to speak only TCP/IP-SMTP on its outside interface and speak IPX on its internal interface to the internal GroupWise system. Because it's a proprietary and unintelligent gateway, its capabilities are limited and it can't get into too much trouble. On the other hand , if this proxy did support Socks5, it is unlikely we would change its position to the inside of our network because that would mean allowing incoming IP connections through the Socks5 server.

Fuzzy Socks We use the sparsely documented freeware version of Socks5, so we learned most things the hard way. But the pitfalls we encountered were applicable to any implementation of Socks5; they were mainly deployment and management issues that we didn't see covered in FAQs or instructions on the Web. One potentially costly rollout mistake was that we initially used a hard-coded IP address to refer to the Socks server rather than an internal DNS name. We assumed that proxies worked like routers. Because we were accustomed to specifying routers by hard-coded IP number, we specified an IP number for the proxy as well. Fortunately, we caught this early in a test rollout, and began to use an internal DNS name--"socks"--instead. If we hadn't, we might have had to touch hundreds of machines when our configuration changed.

Socks5 has both a client and a server configuration, with access control residing on the server. Initially, we made the mistake of setting up our Socks5 server to let internal address "go anywhere." Unfortunately, this had the effect of allowing every client to use the Socks5 server as a proxy, even for internal destinations (see "Incorrect Internal Setup" on page 150). A technician should know to tell client software not to use the proxy server for internal (local) addresses, but in the real world, misconfigured clients happen more often than we'd like. These clients can slow your Socks5 server with large internal LAN-speed traffic, which should never have gotten to it in the first place. The best way to deal with this is to explicitly not allow local traffic at the server.

Hole in Toe Bringing up a secured server is pointless if you don't take steps to make sure the server isn't compromised by common methods. Any service that is in use on the server should be stopped unless you speci fically need it. For example, we needed to be able to telnet to the server, as well as reconfigure, troubleshoot and modify access. Using the regular telnet would have been foolhardy--it does very weak, clear-text password-based authentication and is a poor choice for a secured server. Instead, we used STEL (Secure telnet), available at idea.sec.dsi.unimi.it/RDPROJ/ stel.html, which offers strong encryption of the entire session and strong authentication. Other tools you might consider include ssh (secure shell) for Unix, or for a combination of Unix and Windows, Medcom Information Systems' SSR-Relay software (www.medcom.se), which enables SSL (Secure Socket Layer)-style encryption of any WinSock application or Unix daemon, such as telnetd.