While testing Netscape's filter Rule Manager, we hit a snag attempting to set a filter rule specifying a destination address and port number. The destination address kept showing up in the source port field. We were offered the following solution: Edit the sock5.conf file by hand and reapply the changes to Proxy Server, then restart the Socks server. The rule continued to be swapped back and forth on each successive save and apply. Netscape promises a fix is forthcoming.

Logging for Socks 5 information was extensive, with great detail about who is making connections, where they are connecting and how much data is being transferred. A complete log entry has two lines: the request, which shows date and time of connection and destination, and a line showing how much data was sent and received while processing the connection. Denials of service are also logged, showing who is running up against filter rules and how often.

Mike Fratto can be reached at mfratto@nwc.com.

Putting On The Socks: How We Tested
In this review we were interested in the management and security issues surrounding Socks 5 implementations. Major stumbling blocks to the rollout of protocols such as Socks include the impact and management overhead involved when integrating them into an existing security framework. We particularly kept an eye on how each of these servers leverage existing network services for user management and event logging for auditing and accounting.

For our setup, we configured each solution to allow some internal users out onto the Internet, but only after they had authenticated to the Socks server. And we attempted to restrict HTTP access to non-business-related sites with sports, entertainment and adult content. In addition, we wanted to track usage (per user) and destination information. Access by external users to specific servers on our internal LAN was granted only after users authenticated to the Socks server. External users could access our internal Web server and internal FTP server for downloads only.

We set up each server on a 200-MHz Pentium Pro with 128 MB of RAM and two 3Com Corp. 3C509 10/100 network adapters. The servers straddled our internal and external networks, forcing all traffic to traverse the Socks server. We used similarly configured servers for the Socks proxy chain. A Cisco Systems 4700 router tied the networks together. Meanwhile, we installed Aventail Corp.ęs AutoSocks 2.3 and NEC Corp.ęs freeware SocksCAP on Windows 95 clients. Each client was configured similarly, and we redirected specific network traffic to the Socks server while directly connecting all other traffic.