One way to design a network that lets you configure a packet filter to pass only packets that are part of a communication originated by the internal network is illustrated in "Sample of Secure Internet Connection." This network uses both a packet filter and a proxy server to secure the intern al network.

With this setup, internal hosts are configured to use the proxy server for applications like FTP, HTTP and telnet, and DNS name resolution. Interface E0 on the packet-filter router will pass only TCP packets that are part of a conversation originated from the internal network. UDP packets for DNS do not have to traverse the internal network because the proxy server is handling DNS name resolution in conjunction with the DNS server.

The only tricky part is delivery of e-mail from the Internet. Normally, an e-mail server will initiate a Simple Mail Transfer Protocol (SMTP) connection to deliver an e-mail message over TCP to a host. In our sample network, this is not allowed by the packet filter (which permits only outbound TCP connections). The e-mail gateway on the internal network regularly initiates a connection to the e-mail server and retrieves any new messages. This way, e-mail can be received from the Internet with a TCP connection initiat ed from within the internal network. The e-ma il gateway's ability to initiate the connection to the e-mail server is generally a function of the e-mail application in use. Programming this functionality into sendmail is not a trivial option, so make sure your e-mail system can do this before proceeding with this type of design.

The only way a hacker can compromise this setup is if he or she jumps onto an existing TCP connection by inserting a packet with the correct sequence number in the TCP stream. This is made even more difficult by firewalls that randomize TCP sequence numbers.

Other Issues to Consider To get the most out of your firewall investment, you must also consider the following issues.

· Network device password policy. Passwords need to be obscure and changed regularly. No network administrator should use the same password for a secure system as one that is used on an insecure system. If you deploy multiple firewalls, you need a simple way to coordinate password changes.

· Limited number of reports. Reports should inform you of all attempted security breaches, but little else. Too many reports are not likely to be read.

· SNMP access. If your routers are SNMP-managed, you must choose obscure community names for both read-only and read/write access, otherwise a hacker can use SNMP to obtain and potentially alter network device configuration.

· Virtual private networks. If you're considering implementing VPNs over the Internet, you'll need a firewall that supports some type of high-performance encryption.

· Secure backup devices. It's easy to overlook the security of a device that's not on the front line of Internet access, but rather holds the configuration of the devices that connect you to the Internet. Viewing the device configuration on a TFTP server that is used to store network device configuration can be just as helpful to a hacker as viewing the configuration from the device itself.

· Site screening. You may w ant to set up a list of specifically allowed or denied URLs. This feature is not supported by all firewalls, so ask your vendor about it.

· Encrypted router passwords. If a hacker does gain access to router configurations, possibly stored on a TFTP server on your network, you'll have one more layer of protection if these passwords are encrypted.

· Physical access. Security breaches are most commonly perpetrated by insiders. You need to secure physical access to sensitive systems and restrict access from external users.

For more in-depth reference material on this subject, check out Building Internet Firewalls (D. Brent Chapman and Elizabeth Zwicky, O'Reilly and Associates). Also see our Network Design Manual chapter, "Internet Firewall Essentials," online at www.NetworkComputing.com/netdesign/wall1.html.

Chris Lewis is vice president of international operations at ILX Systems. He currently is working in Europe. He can be reached at chrisl@ilx.com.