Test Your Firewall’s Inbound Security

In this tutorial you’ll learn more about how easy it is to test your firewall’s incoming security preparedness, and what port scan results are actually telling you.

Installing personal firewall software like ZoneAlarm or Norton Personal Firewall is a great start towards protecting your PC from online dangers, but you should still test its inbound security situation at least periodically to be certain that it’s offering the protection you expect. All personal firewall programs will block incoming connection attempts by default, but if you’ve been opening ports (or allowing programs to “act as a server”) to allow others to connect to your PC, you’ll want to be sure that you haven’t left any ports open by accident. Additionally, it’s a good idea to check the status of ports occasionally in order to be sure that a malicious program (such as a Trojan horse) hasn’t wormed its way onto your system and silently opened a backdoor that would allow others to connect.

The easiest way to test the inbound security of your firewall is to use one of the many free port scanning tools available on the web. There are a number to choose from, but the one I usually recommend is ShieldsUP! at www.grc.com. This tool will perform a scan of your IP address to determine whether any ports are open and accessible to Internet users. If your firewall is configured correctly, all ports should be in stealth mode (with the exception of any ports that you have explicitly opened), meaning that these ports do not respond to requests from outside users – exactly what most users need and should want.

To test your firewall with ShieldsUP!, follow these steps:

  1. Open your preferred web browser and head to the ShieldsUP! home page.
  2. Read through the details provided on the page, and then click the Proceed button. If a Security Warning dialog box appears, click Continue.
  3. Click the buttons provided to run scans for open File Sharing, Common Ports, Service Ports, and so forth, one at a time. Complete all of the scans. Scans will take anywhere from a few seconds to over a minute to complete, depending on how busy the site is and the speed of your connection.

Once complete, review the scan’s results and proceed to the next scan. If open ports and/or vulnerabilities are found, use the details provided to make the necessary changes to your firewall. This may involve denying certain programs the ability to “act as a server” in your firewall’s program configuration settings. When ports are open, connections from outside users are allowed. When closed, connections are denied but your PC is visible to the outside world. When ports are determined to be in stealth mode, it means that the scanner couldn’t get any response from the port, making it virtually invisible.

One thing to note when your scan is complete – even if all ports are determined to be in stealth mode, you PC may still officially “fail” the test. Many firewalls (especially older versions) will automatically reply to “ping” diagnostic messages, even with all ports closed. If the firewall does reply to a ping, it tells the person who initiated it that a system does exist at your IP address. That’s doesn’t mean that they can get in, but it does mean that they could attempt a more involved attack knowing that there’s a system at your address. For this reason, almost all firewalls now automatically discard ping requests originating from the Internet. If yours didn’t, take a look through your firewall’s configuration settings and you’ll likely find an option to block ping replies – typically named “discard ping from WAN”, “block ICMP echo replies” or similar.

If your firewall shows all ports running in full stealth mode, that’s good news. It doesn’t necessarily mean that your PC is protected from all potential security threats, but it’s a good start. Don’t be afraid to experiment with other online port scanning tools, either. There’s no shortage of great options available ranging from basic probing tools through to more advanced and detailed scanners.

Planning an ISA Server Deployment (Part 2)

Welcome back to the 2000Trainers.com continuing series on ISA Server 2004! In this article, part two of “Planning an ISA Server 2004 Deployment”, we are going to cover server requirements necessary to actually install ISA 2004. We’ll talk about hardware requirements as well as some of the unique requirements we need to plan on when installing the software on both Windows 2000 and Windows Server 2003 platforms.

As we talked about in our last article, planning is of vital importance in an ISA Server 2004 deployment, in order to prevent having to go back and correct what may become serious problems later down the road after the install is declared a “success”. Before the CD is even inserted into the box which will become an ISA server, some considerations that must be taken into account are hardware and operating system platforms. We’ll talk about both of those issues in this article.

First, let’s look at hardware. ISA Server 2004 has a minimum set of hardware requirements, of course, as all Microsoft products do, but the minimum requirements are only established to set the low-end boundary of what a computer must have just to get ISA server installed, not necessarily to run it well. We’ll list the minimum requirements, but understand that you should always, especially in a large production environment, go with considerably more hardware than just the minimum if you want it to run right.

Microsoft says that the minimum hardware requirements for an ISA Server 2004 are: a Pentium III or compatible CPU running at least at 550 MHz, 256 MB of RAM, and an NTFS –formatted hard disk drive with at least 150MB of space available on it. Of course, if you are going to use the ISA server for content caching, you will need additional hard disk space. It should go without saying, of course, that a CD-ROM, keyboard, mouse, and VGA-compatible video adapter are also necessary to install the server.

Planning an ISA Server Deployment (Part 1)

In this two- part article in our continuing series on ISA Server 2004, we will look at a very critical part of the process, the planning phase. Planning is one of the most important parts of an ISA Server deployment, but is also the part that very few people put a lot of time and energy into. Unfortunately, failing to plan the deployment properly can lead to problems later that will cost you more in terms of time and work to go back and correct these issues. That’s why this phase is so important.

The first part of planning, which this particular article covers, is planning out the network infrastructure that your ISA Server will be a part of, and knowing exactly how it will fit into the architecture. This is critical because there are several considerations to look at before you actually bring the server online. There are several aspects of your infrastructure you will need to examine, including: network infrastructure, organizational security policies, client requirements, branch office connections, VPN structure, server publishing, partner access, fault tolerance, and the actual roll-out itself. We’ll briefly look at each one of these now:

Network Infrastructure: This involves having a comprehensive network diagram and configuration documentation that exactly lays out the way the network is built. Critical parts of the infrastructure that may affect and be affected by the ISA server rollout will be DHCP services, DNS, email services, Active Directory structure, perimeter network configuration, web servers, and any other network services that must be reconfigured to coexist with an ISA Server. You should know what protocols your company network uses, and how they should be secured as they enter and leave the network. You may have to move some services inside the DMZ, if you have one, or look at creating a DMZ if you don’t currently have one. You will need to decide how DNS is handled, and whether the ISA server will handle DNS resolution. You will also need to look at any web services that are accessed from outside your network and how they will be protected against unauthorized use. These are but a few of the considerations you will have to contend with on the network, but it depends on how your network is built and what your requirements are as to how you plan for them.

Deploying ISA Server 2004

Welcome back to the 2000Trainers.com series on ISA Server 2004. So far we’ve talked about what ISA server is and does, and its functions and editions. This article will take it one step further by discussing the many different ways you can use ISA server in your network, no matter how large or small.

ISA Server 2004 can be deployed in a number of different configurations to suite your organization’s needs. Since ISA server is well suited for small, medium, and large businesses, a wide variety of deployment scenarios are possible. There are three basic deployment configurations we will discuss, and then talk about some variations on these.

The first scenario is as an internet edge firewall, probably the most common scenario. The ISA Server protects an internal network from an external one, such as the Internet. One network interface is attached to the Internet, or other untrusted network, and the internal network is attached to the second interface. There may or may not be a perimeter network between the Internet-facing ISA server and the internal network, depending upon the size of the network and the needs of the organization. The ISA server may allow internal servers to be published, such as a web server, and it may even operate as a VPN server. In any case, the ISA server serves as the only entry and exit point into the internal network from the outside world, and controls all inbound and outbound network traffic.
A second method is to deploy the ISA Server as a back-end firewall. In this case, the ISA server is one of two firewalls deployed in a demilitarized zone (DMZ) or perimeter network configuration. The front-end or Internet-facing firewall serves as initial entry point into the network. This machine may or may not be an ISA server. This firewall offers some protection for the internal network and serves as the primary protection for servers deployed inside the DMZ. The ISA server acting as the back-end firewall, on the other hand, primarily protects internal assets and allows publishing of resources outside the internal network. For example, a web server in the DMZ may require data from an SQL server that resides on the internal network. The back-end server would allow access to the SQL server from the web server inside the DMZ only, and not from any other external host. Then the web server would provide requested data to an Internet host through the front-end firewall.
Yet a third scenario would be to use an ISA server as a branch office firewall and/or VPN server. In this case, the ISA server would serve as a single entry point into a smaller, geographically separated branch office network, usually connected to the Internet with a WAN connection, and connect to another ISA server at the main office, in a site-to-site VPN configuration.

Keep in mind that when factoring in additional roles for your firewall, such as proxy or caching server, VPN server, or a remote access server, this can add variations to the complexity of the basic scenarios mentioned above. You may choose to have separate ISA servers host these roles, or combine them onto one server. Additionally, having arrays configured in each of these scenarios can both add to your deployment options and the overall complexity of the deployment, as an ISA server may also function solely as a configuration storage server for an array. The bottom line to remember here is that ISA Server 2004 is quite versatile; it can be deployed to fit the unique needs of any size organization.

With that, we’ll close out this installment. In our next article, we’ll discuss an often-overlooked, but extremely critical part of getting ISA Server 2004 up and running – the planning step. See you then!

Microsoft ISA Server Editions

Welcome back to our series on Microsoft’s ISA Server 2004. In our previous article, we talked about some of the features of ISA 2004. This time, we’ll talk about the two editions of the product and how they differ from each other and their predecessor, ISA Server 2000. We’ll also talk about the various upgrade paths from ISA 2000 to 2004.

ISA Server 2004 comes in two flavors: the Standard Edition and the Enterprise Edition. Although both offer similar features, such as the firewall, caching server, and proxy server capabilities, they differ in how they are implemented, the size of the infrastructure they are targeted for, and some advanced features. We’ll discuss the features of each and the differences between the two in this article.

ISA Server 2004 Standard Edition is the basic ISA Server package. It’s suitable for almost all networks, and is used mainly in a stand-alone environment. It can be used in small- or branch-office type of scenarios, or when you only need one ISA server installed to fulfill a specific role (such as a web proxy). It can be deployed in all of the roles previously discussed, including proxy server, caching server, and firewall configurations, or a combination of all three.

ISA Server Standard Edition differs from the Enterprise Edition in that it stores its configuration data in the local registry, instead of in a central location, such as Active Directory. This means that if you make any configuration changes that need to be applied to all of your ISA servers, you’ll have to go to each one and make the change individually. Additionally, Standard Edition does not support a centralized caching database configuration, as Enterprise Edition does when configured in an array. Each Standard Edition server has its own separate content cache.