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