While companies continue to spend money on higher speed Internet connections, it’s only reasonable that they should expect more for their budget dollars. In an effort to stretch those dollars, many companies are implementing VPNs for remote access by employees. Also, they are escalating the security on these connections to ensure that only those who should have access can actually gain access to their private networks.
Although it may seem overly ambitious, we’ll be tackling several different yet related issues in this Daily Feature. The overall topic envelops a case study of a recent networking project in which I was involved. The general idea was to upgrade the client’s Internet security and provide for VPN remote access. Additionally, the remote clients would then be connecting to a terminal server inside the firewall on the LAN. As if this weren’t enough, we also had to address secure authentication schemes in a rather custom fashion. We were fortunate to find that Microsoft provided many of the features and options that we required to complete this project. You’ll see that, with a little ingenuity and a bit of customization, you, too, can secure your network.
Firewall upgrade process
In this first part, we’ll address the primary piece in this puzzle: the firewall upgrade. Fortunately, the client had decided to upgrade from MS Proxy Server 2.0 to MS Internet Security and Acceleration (ISA) Server 2000. This fairly new product is actually a firewall/cache server and is certified by ICSA. At the time of this writing, you can download a time-limited evaluation copy from the Microsoft Web site. Now, with the plugs out of the way, let’s turn our attention to the installation considerations.
Since Internet connectivity had to be maintained throughout the process, we decided to install a new server, rather than performing the MS upgrade process on the previous Proxy server. The LAN clients needing Internet access would not be deterred during our upgrade, as the old system would stay online until the new system was installed and tested. At that point, the LAN clients’ browsers would simply need to be changed to point to the new Proxy server. Fortunately, the client already had a service network set up at the Internet router with enough free public address space to accommodate both gateways simultaneously. We installed two NICs in the new server, one for the Internet connection and the other for the internal LAN. Both NICs were statically addressed with appropriate addresses for the respective networks.
When configuring the internal NIC, the WINS and DNS info were provided, but the default gateway was left blank. This is standard operating procedure when configuring most firewalls. Microsoft required that Service Pack 1 be installed prior to the ISA software. We decided to apply Win2K Service Pack 2, as it was the most current at the time. Then we installed ISA. (You have the option of installing just the firewall, just the caching server, or integrated mode, which includes both functions.) We chose to install it on a member server so that we could utilize some of the domain-based features to control content access. During the install, you’ll be asked several questions. We went with the default values, as most of them seemed appropriate (and we could change them later, if necessary).
After completing the installation, we checked for product updates on the Microsoft ISA site. There was a security alert with a patch, which we then applied. Although Windows 2000 doesn’t seem to require a restart after such operations, we recommend it after installing the firewall software, as well as any other OS patches. Essentially, the ISA install did several things on our system. For one thing, it installed and configured RRAS and packet filters to allow only some basic ICMP packets. Basically, it adheres to a deny-all model (except for ICMP). The one oddity about this is that the default, installed filters seem to allow pings from internal clients to pass through the firewall but do not allow a response to outside sources attempting to ping the external firewall interface. This may be a bit of a problem when testing connectivity with your ISP.
Configuring the firewall
After the initial installation was complete, it was time to perform any custom configuration for this site. We needed to allow traffic appropriate to the client’s site (i.e., HTTP, HTTPS, FTP, etc.). You’ll want to check the routing tables on your server after the installation is complete to insure that no unexpected routes have been added. Locally speaking, you’ll want to verify the LAT table, especially if you allowed the install process to generate the LAT. It’s automatically set up to perform logging, so you’ll want to make sure that enough disk space is available to do so. You may also want to consider a separate hard drive for logging.
The first thing we did to configure our firewall was to create an opening for basic Web and FTP traffic. To do so, we created a group of users by internal IP address range. We then created a rule allowing the aforementioned traffic and associated our group with the rule. Now that we have client access on the outbound, let’s look at how we can provide basic inbound access. You can push e-mail through ISA to your internal SMTP server and allow external Internet clients access to internal Web servers. In Microsoft terminology, this is known as Publishing. Once you publish your e-mail server, you’ll be able to receive e-mail from the Internet. There are also packet filters included that you can activate to funnel SMTP and WWW traffic.
Testing the firewall
At this point, we wanted to ensure both connectivity and security. We made sure that internal clients could ping Internet sites by address and name. This ensures that NAT is working correctly and that connectivity and name resolution are functioning properly. After this, we used a port scanner to check security at the external interface. After scanning it, we felt very good about the product, as it seemed to be a black hole for TCP/IP packets. The only thing that passed was specifically what we had allowed.
The good thing about ISA Server 2000 is its familiarity, as it seems quite similar to Proxy Server 2.0. However, it is a true and tested firewall platform, unlike Proxy Server. Unfortunately, the ISA server appears to provide no facility for printing a configuration report. Microsoft does provide the ability to save the configuration to a proprietary file type to use in case a restoration of your ISA server is necessary. All in all, the installation process is easy and straightforward, and the default configuration appears solid. Stay tuned for the next part of this series; we’ll take things a step further when we configure VPN access on our firewall.