Abstract

Recently, on BugTraq, a subscriber sent an advisory claiming that ZoneAlarm was containing a vulnerability allowing people on the same subnet to connect to your machine unreported. As it turns out, this person was using ZoneAlarm with a default configuration under the wrong context. Since ZoneAlarm, and other personal firewalls, are becoming more popular, I thought that there was a need to define guidelines on how to use this tool in order to have sufficient security from it. This paper is the collection of my experiences with ZoneAlarm v2.1.25, free for personal use. I haven't had the chance to try version 2.6 Pro, or the newly released version 3.0, but I will do as soon as I can, now that I can operate under my own company (and have more freedom on my activities). This will probably be presented on future whitepapers. What will be presented here can be used by both home users connected to the Internet or network administrators who want to improve their network security (although you should use the licensed versions for commercial use in this case, which features more options).

Targeted audience

This document is presented to anyone who has interests in computer security, network intrusion, hacking, viruses, Trojan horses, network administration and computing in general.

Table of contents

1. Introduction
2. Overview of the GUI
3. Overview of the "Alerts" screen
4. Overview of the "Lock" screen
5. Overview of the "Security" screen
6. Overview of the "Programs" screen
7. Overview of the "Configure" screen
8. Conclusion

1. Introduction

A few weeks ago, a poster sent an advisory on BugTraq claiming that ZoneLabs' ZoneALarm software contained a vulnerability that permitted DSL users who had the same Class B subnet (255.255.0.0) the ability to access his machine, while denying all other Internet users. As it turned out, this person had clicked on his network adapter's subnet to include it as part of the local network (click to the Security screen, then Advanced). There is a little explanation on the window that explains that you should do this to include machines that are part of your LAN in your local network. It is also mentioned that network adapters connected to DSL, cable modems or dial-up to access Internet should not be clicked to be part of the local network. This is the mistake that this person had made. Some other person also argued that this was a pretty loose configuration, even for a local area network, to have included by default a whole Class B subnet. While ZoneAlarm is a pretty good tool in my opinion, like most software its default configuration(s) may not be the best option in terms of security.

This paper will present an overview of the different sections of ZoneAlarm version 2.1.25, free for personal use (which is the context under which I am using it BTW). I plan to look at the commercial and newer versions in the near future, and probably submit similar papers for these versions if I feel this would be profitable to the community. So, this paper consists of 6 chapters (plus intro and conclusion) presenting each of the 5 sections of ZoneAlarm and an overview of the graphical interface. The reader should put more emphasis on the material presented in chapters 5 and 6 for the really good tips in terms of security configuration.

I haven't done it yet, so I guess I should do it here, but if you've made it so far, you probably already know what is ZoneAlarm, but anyway, I will define what ZoneAlarm is. ZoneAlarm is a security software operating as personal firewall published by ZoneLabs (www.zonelabs.com). The software works by creating a "wall" (or more exactly, a firewall) between your network connection and your operating system, filtering all traffic flow between these two components of your system accordingly to a set of rules that you have pre-defined. However, unlike traditional firewalls (for example, CheckPoint Firewall-1 or Conceal PC Firewall), ZoneAlarm doesn't concentrate its work on source and destination ports by themselves, but more to which applications on your system are allowed to access the network, and how they can access it.

To do this, it uses 2 strategies. In the first, you have the possibility to define 2 different networks (internal and external), and apply a set of pre-defined rules to each of these networks. This will define which machines can talk to this host. In the other strategy, it holds a list of which executables on your system that have access to the network. For each networked application on your computer, you can define if this application can access the local network, the external network, or no network access at all. You can also configure it so that it asks you the permission every time it tries to connect. So, knowing this, we can now go more deeply in the configuration of ZoneAlarm.

2. Overview of the GUI

I will assume that ZoneAlarm has already been downloaded and installed, so I won't cover the installation procedure. Once the program is installed and the system is rebooted, you should see in your system tray an icon like the one pointed by the arrow in Figure 1 (an alternate icon, not shown here, made by the letters ZA in white on a split red-and-yellow background, may appear instead). If you don't see the ZoneAlarm icon, you probably have configured ZoneAlarm not to launch automatically at startup. If this is the case, then start it manually.

Figure 1

We will notice that this icon is divided in two parts that looks like meters. The green part is your download meter, and it will show activity whenever your machine sends data to the network. The red part is the upload meter, and it will show activity whenever you receive data from the network. If we double-click on it, we will see it pop up to a window like the one in Figure 1.1. This is the compact mode, where we can see the upload/download meters, a lock in unlocked state, a STOP button and a small area where programs using the network connections are displayed (in the case of Figure 1.1, none). There is also the Help button at the far right.

Figure 1.1.

Under this part, we see 5 buttons, each one corresponding to a section that will be covered in the following chapters, namely Alerts, Lock, Security, Programs and Configure. On the lower right-hand corner, under the Configure button, we see a small arrow pointed down. If we click on this arrow, or on one of the buttons, this will expand the ZoneAlarm window like we see in Figure 1.2.

Figure 1.2.

At the very bottom of the screen, we see a status message about the last action done by ZoneAlarm, and on the far right an arrow pointed up to put ZoneAlarm back in compact mode again, as we have seen in Figure 1.1. This info will show in every screen. To minimize ZoneAlarm to our task bar, we click on "_" icon on the upper right-hand corner, and to put it back to our system tray, we click on the "X" icon just beside it.

3. Overview of the "Alerts" screen

Figure 2

Taken chronologically, this is the first screen of configuration for ZoneAlarm. This one is pretty simple, as you can see. This screen is divided in three sections, identified in Figure 2. In section 1, we have an indicator of how many bytes were sent and received during the current networking session. Section 2 will display summary information about the alerts generated by ZoneAlarm. You can browse through the alerts to see the history of events, you can connect to ZoneLabs website for more information about particular attacks by clicking the button "More info", or simply clear the current session history by clicking the "Clear alerts" button.

Section 3 lets you chose whether you want to create a log file of alerts, and if you want a popup window when an alert occurs (as shown in Figure 2.1). You also have a button that lets you erase the logs. In a security context, it is very important to have logs of monitored activity, in order to have the maximum information possible about a security event in order to investigate it. For this reason, I strongly suggest to enable the logging ability of ZoneAlarm. Unfortunately, the log files are stored in a hard coded directory (C:\WINDOWS\Internet Logs\ZALog.txt), which means that you can't change the destination. If you are a standalone user, this is not much of a concern, but for a Windows administrator who want to keep an eye on these log files (after all, he should be able to do so already with is antivirus log files) this could be more problematic. This is partly the reason why I wrote LogAgent (www.geocities.com/floydian_99/logagent.html), which lets a user to monitor pre-determined specific folders containing the log files in which we have interest into, and redirect them to a central server. This would enable the administrator of a networked site to not only protect his machines with ZoneAlarm, but also to gather up the alerts generated by it.

Figure 2.1.

As for the popup option, it is left to the taste of the user, I usually find it more disturbing and annoying than anything if I am connected straight to the Internet, but in a LAN environment, where traffic is well controlled (or should, we'll discuss about this later in chapter 5), it could be an interesting option to keep to raise user's awareness. But in order not to raise too many false flags, application security configuration (covered in chapter 6) should be carefully designed for your environment.

4. Overview of the "Lock" screen

Figure 3

In this screen, we see the info related to the lock icon and the STOP button discussed earlier. This screen is divided in 2 sections. In section 1, we see status info related to Internet access (locked or unlocked) and about the automatic locking feature. Section 2 holds the configuration for automatic locking. While ZoneAlarm filters which programs that you use that are allowed to connect to the Internet or local network, there may be times that you want to block Internet access, either for good security consciousness or because you suspect that one of your trusted programs may be betraying you. When you lock ZoneAlarm, or if it is being locked automatically, your allowed programs will be denied Internet access until you unlock the access yourself (by clicking on the lock, you can manually lock it or unlock it). However, as we will see later, you can specify some programs to bypass the lock, in case you have a service that you cannot afford to disconnect, for example. Pushing the STOP button will effectively stop all traffic (as shown in Figure 3.1), even if it is allowed to bypass the lock.

Figure 3.1.

In Figure 3.2, we see an unlocked connection, with automatic locking enabled to start when the screen saver launches, and allowing pass-lock programs to bypass the lock. Selecting the other option, "High security, All Internet activity stopped", then simply locking the connection should do the trick, without having to resort to the STOP button (both buttons become equivalent under this configuration, and should be preferred if you intend to use the automatic lock feature). You can also choose to launch the automatic locking after a pre-determined number of minutes of inactivity instead on relying on the screen saver.

Figure 3.2.

This is not the more important part of ZoneAlarm, and I never had to play much with this section in real life situations. However, it is important to know about it, in case we need it one day. As for automatic locking, I'd say that this is left to the preferences of the users or admins. Personally, I don't use automatic locking and put more emphasis on having a secure configuration in the first place, so that I don't have to rely on the lock to protect me.

5. Overview of the "Security" screen

Figure 4

This is one of the most important configuration screen of ZoneAlarm, along with the next one (covered in chapter 6). The "Advanced" button in section 1 of Figure 4 brings the Advanced dialog box, as shown in Figure 4.1. We will discuss about it later, for now we will concentrate on the screen shown in Figure 4. Section 2 shows the security level applied to the local network. Similarly, section 3 shows the same kind of information about the Internet (or external network). Sections 2 and 3 also have a checkbox for allowing server programs on each network. Section 4 is a checkbox to enable MailSafe, a component designed to remove VBScript attachment from e-mails, as these are often used to distribute viruses (or I should say virii).

There are three pre-defined level (low, medium and high) of security in ZoneAlarm, each of them can be applied to both the local and external networks. The external network security level will always be at least as secure as for the internal network. For example, you can not have an internal network configured to have a high security setting while permitting only a medium security on the external network. This should be somewhat obvious, as you should be able to better trust your own network than the outside world.

In short, the three level of security are defined as follows; for more details about these, please refer to the ZoneAlarm help file. The first level, "Low", is of course the lowest of these three, and I wouldn't recommend to use it, unless maybe for testing purposes or for a short period of time when you need to use one application that requires a low level of security and you don't want to spend time to configure it to work on higher levels of security. Basically, it only enforces the list of applications allowed to connect to the network (we will cover this on the next chapter), and enabling the lock will only block the traffic associated with these applications, but still allows network access to listening servers on your machine. All netbios traffic for accessing shared folders and printers on this zone will be allowed, and your machine we be visible from the network (ping requests or port scans, for example).

The next level, "Medium", is somewhat better, and is recommended for the local network. You machine will still allow the Microsoft networking protocols, such as netbios, to permit access to shared files or printers (either for people to access resources shared on your machine or to let you access resources shared on a remote computer), but at least the Internet Lock will block all traffic. It still limits which applications on your machine can use the network, but your machine will still be visible for the associated network.

The third level, "High", is of course the strongest level available. This setting is recommended for the Internet zone, and should even be applied to both zones for home users who only have one PC to connect to the Internet using a modem, DSL or cable connection. This level of security still enforces the applications privileges list, but will block all other kind of traffic, either pings, port scans or attempts to use Windows resources (either local or remote resources, because when you send a request to connect to machine for shared folders or printers, the servers response will be blocked by ZoneAlarm). Your machine will be invisible to other hosts, except if you do have a valid server application running on your system to allow outside people to connect to your machine. In this mode, ZoneAlarm blocks all ports by default, and only opens a port when it is needed.

You also have a check box that enables you to block servers on the local and Internet networks. At this point, I should explain what is a server. Usually, a server is a program designed to offer resources to remote machines, and these machines use a program called the client to use the server's resources. A server will open a specified port, and will listen to it for incoming connections, and serves the requested information when he does receive a request. However, this concept is slightly modified under the context of ZoneAlarm, as some applications, that are usually classified as clients, also acts like servers, meaning that they are made to send requests to the servers for information, but they are also actively listening for information that could be pushed by that same server. To achieve this, they simply open a port, listen on it and then wait for input, just like any normal server application. I wanted to clarify this in order to avoid confusion in the next chapter. So, checking these boxes will actually block servers, even if they are allowed as servers on the "Programs" section of ZoneAlarm. This means that incoming connections for these servers will be blocked by the personal firewall. Depending on the applications you are using, you may have to leave one or both of these boxes unchecked. If you are sure that you are not using "server" applications (or if you don't want them to behave like servers), then these boxes should be checked. I strongly recommend that you test your configuration on your computing environment before deploying them on your network.

In section 4, MailSafe is enabled by default. This program should work with most mail clients that uses POP3 or IMAP protocols. It strips VBScript attachments from incoming e-mails, as these are often used to spread viruses, and that the chances of it being a valid attachment is quite slim. This should NOT be perceived as a complete antivirus solution, and the ZoneAlarm documentation does make that point clear. So in order to have decent virus protection, you should use a separate antivirus product.

Figure 4.1.

Now, if we go back to the Advanced section, obtained by clicking the button shown in section 1 of Figure 4. This section is displayed in Figure 4.1. By default, there are no host that are part of the local network, meaning that all remote machines are part of the Internet network. By clicking on an item displayed in the list (but not selecting the checkbox), we see a different message displayed at the bottom of the screen, as shown in section 1 of Figure 4.2.

Figure 4.2.

This message says that by checking the box besides a network adapter makes this adapter's subnet (255.255.0.0) part of the local network. This should only be done on a LAN environment. Dial up, cable modems and DSL adapters should NOT be checked on. This was the mistake of the BugTraq poster I mentioned earlier.

However, allowing the whole subnet as the local network can be somewhat of a too open solution. Let's say that this option is just a quick short-cut made available by ZoneLabs. You can make a more specific description of your local network by detailing its components, and you should do so. You do this by clicking on the Add button, as shown in Figure 4.3.

Figure 4.3.

You can choose to define either a host (specified by DNS name or NetBios name), a specific IP address, a specific IP range or an IP subnet of your choice, along with comments. Of course, your local network can be made of several of these components of every type. In this case, I added the DNS server as a specific IP address, as shown in Figure 4.4. The garbage at the bottom of the screen could be caused by my French keyboard configuration, but I am not sure about that. If anyone knows more about this, please let me know. But this haven't caused me any problem so far, so no big deal.

Figure 4.4.

Then, I can add other components. I have a two-pronged point of view in defining what should be considered the "local" network. First, I know from experience that local networks are usually wide-open, making it prone to abuse by would-be intruders, both internal and external (for more details about this, read "Autopsy of a successful intrusion" on my website). Secondly, as a network user, I see no reason why I should trust the other people on my network and allow them to access my machine in any way. From the user's point of view, the network is principally made of his own workstation and the various servers he interacts with (knowingly or unknowingly), and has little interests for the other workstations that are part of the same network. For these reasons, I don't think it's a good idea to define whole subnets to be part of the "local network" of ZoneAlarm. This is the approach I took when I used it to personally protect myself from my coworkers potential curiosity (BTW, personal firewalls were forbidden by the company, so this wasn't commercial use. As for the rules I had broken, they had no way to enforce it, and I designed a security policy for them that recommended its use, but that was denied).

So I think that only specifying the various servers that are part of the LAN should be good enough to improve overall network security without being in the way of usability (there is a common principle that says that you have to make a balance between usability and security, and that sacrificing usability makes it hard to implement security, but in this case (the windows desktop), the users have more usability that they can handle, so I see no problem in cutting in the fat on usability in order to re-establish balance with security). I had such a configuration as the one shown in Figure 4.5 for approximately 6 months without having any problem using the networks resources (Local network was set to "Medium", the external network, including the rest of the company's LAN, set to "High"). I was totally invisible to all other machines on the LAN except for the ones I had defined in ZoneAlarm.

The first few days, ZoneAlarm blocked and reported a certain volume of netbios requests from other workstations, which is normal on a loose Windows network, since the machines often broadcasts their presences to the rest of the network. But after a while, after my machine name have been cleared from the master browser's tables, I stopped receiving these and I could more easily determine suspicious traffic (very little, but still...). Also, using a modified version of LogAgent, I could monitor in real-time my ZoneAlarm log file to see the "normal" network traffic sent to my PC from the other workstations that was being blocked. I asked a colleague to scan my IP for open ports from his machine, and he could not see my machine at all (but I could see his scan).

I think that by having such a setup deployed in a whole LAN, three benefits should come up. First, it should help reduce this "normal" network traffic between the PCs themselves (often caused by broadcasts to elect the master browser, this is a part of the protocols Windows uses). Secondly, it should improve the rate of false detection of IDS systems, as the flow of traffic will be lower, and less polluted. It should then be easier to define intrusion detection rules that will generate less false-positives and trigger on suspicious traffic. And the third benefit is improved security in your network. I will cover this more specifically in an upcoming whitepaper, but let's just say that by collecting all the log files and combining them, then it should be easier for network administrators to see what's really going on in their network, and possibly detect intrusion attempts before it is too late (an intruder who would have achieved to take control of 1 PC is more likely to create enough noise that should bring your attention since you now will have a device that monitors this for you on all your PCs). Of course, your setup should reflect your own network settings.

Figure 4.5.

6. Overview of the "Programs" screen

Figure 5

This is the other important section of ZoneAlarm, as this is where you specify which programs can or cannot access the network, and in which way. This screen is a list of all the programs that are installed on your computer that tried one day or another to connect to the network while ZoneAlarm was running. This list is broken in 4 columns, namely the application name, the connection permissions, the server permissions and the pass lock permissions. For each program, you can specify to allow access (represented by a green checkmark), to deny it (represented by a red cross) or to ask for permission every time (represented by a black question mark) for both the local and external network. You can also specify which programs can act as servers on each network, and specify which programs can bypass the lock (for the external network only). If you hover you mouse over a program name for a second or two, a small panel containing information about this program will popup, as shown in section 1 of Figure 5.1.

Figure 5.1.

In this panel, you get the following information about your program: its registered name (or the executable filename if none are registered), the whole path of the executable (meaning that having the same software installed in a second location on your PC will create a second entry in this list), the product version (or the file's creation date if no version is specified), the file's creation date, and the file size. If any of this information changes for a requesting program, ZoneAlarm will reset this file's permission to request for permission on both networks (black question mark). The idea behind this strategy is to block trojan horses that could be launched on your machines without your knowledge, thus denying access to would-be intruders. Thankfully, some program publishers do a better job than Microsoft did with its Media Player at defining these properties (Figure 5.2).

Figure 5.2.

To configure each item, simply click on them, or alternatively, you can right-click on a program to popup a menu as shown in Figure 5.3. Also, this is the only way to remove a program item from the list, pressing the delete key won't work.

Figure 5.3.

When a program that is not on the list, or that have to ask for permission every time, tries to connect to the network, a small popup like the one shown in Figure 5.4 appears. You can then select if you wish to allow or deny the connection for this session, and you can click the checkbox to make this decision permanent (you can change it later if you want form the Programs screen).

Now comes the tricky part, how do we configure our softwares? Common sense and security awareness should prevail here. You can take example on my own configuration which is partially shown in this paper. First of all, all items meant for the Microsoft local network, for example the IPC server, should be used on local networks only (and the LAN should only be your servers). As for the local permissions you set for it, or if you should allow it the act as a server, I leave it to you to determine what works better on your environment. But you should know that the IPC service allows an anonymous user to gather up a whole lot of information from the machine, which is part of the information gathering phase of any intrusion attempt. The Perl tool null.pl made by Harlan Carvey makes a quite impressive job at demonstrating this. On a user's PC, the main reason to allow this act as a server is for using Outlook to listen for incoming e-mails from the Exchange servers in their native protocol. The thought of Outlook acting as a server sends shivers down my spine.

For the components that I launch manually and that I launch manually, I allow them to access the Internet since that is exactly what I mean to do with most of these softwares (IE, XNews, SuperScan). One exception, Windows Explorer, which I strictly want to use for looking at my local files. I don't like the idea of my local browser being able to access remote files that I don't know about.

But the most important thing is the attention you should bring to command prompt tools. These tools do not have a graphical interface per se, and as such can be used by passing it parameters without using a command prompt box. That means that even when you see your tools in your DOS box when you are using it, that does not mean that you'll see it if it is launched from another program. This is why I strongly recommend to ALWAYS configure command prompt utilities to ask for permission every time on both networks. I think this is the most useful advice in this paper, so make sure to underline it. These tools should normally be used only by the IT staff anyway (it will still show in the logs, but you can account for them). Even if I normally encourage curiosity, I don't see fit that an non-IT employee satisfy his need for knowledge on the company's network. The idea is not to sanction people, but to let you know whenever this type of activity occur, as this is often this type of activity that are typical of network intrusions. When you see it happen, you can then determine what *really* happened by verifying with the user. If he doesn't know what you are talking about, then someone probably broke in his machine.

I have learned this lesson the hard way. When I started using ZoneAlarm, I was allowing these tools (ping, tracert, ftp, etc.) to access both networks at all times. When preparing for a penetration testing we were contracted for, my colleague asked me to try his newly made trojan that he planned to send to some of the company's employees. Of course, I knew this was a trojan, but I thought that it would be a good test to evaluate ZoneAlarm, as this is exactly this kind of activity that it is supposed to stop. So I launched his program and expected an alert popup, but nothing happened (with the exception of the little shoot-out game that the trojan was wrapped into, and my colleague being very happy with all the information he just extracted from my machine). I was very surprised, since this program was not in ZoneAlarm's list, so it should have raised a flag automatically. The catch was that his trojan was simply a batch file compiled into an .exe (there is a free tool that does this), and this batch file made differrent calls like ipconfig, ping requests, several net commands to determine the servers and shares available, along with user's accounts, and pointed the output of all this to a text file. He also made a copy of my SAM database, containing my local machine's password, and sent everything through a scripted ftp call. He simply used my own ftp program, instead of making the connection himself. Since I was allowing it, I saw absolutely nothing. But I have learned my lesson since then (Figure 5.4). Some people say that programs that have a GUI suffers from the same problems, but this have not been seen in the wild so far. I don't know if GUI programs can really be abused without visually exposing themselves, but knowing Microsoft I think it is very probable, so I guess it's up to you to see what kind of exposure you are able to cope with.

Figure 5.4.

As you can see, I do not allow many servers, with the exception of FTP who needs it when transferring data. Since now I can control when FTP is running, I see no problem with that. Besides, FTP woudln't work otherwise, with the exception of disabling ZoneAlarm altogether, which exposes me even more. You should run a server only if you really need it, and if it is a server intended for local network use only, then make it so. But be cautious at allowing servers running on your PCs, as each one of them is a potential entry door to your system for an intruder or a self-replicating worm. As for the pass lock, do not allow any program to bypass the lock, as it is the most secure option.

7. Overview of the "Configure" screen

Figure 6

Finally, the Configure screen closes the show. This screen is pretty simple and straightforward (Figure 6.). In section 1, we see the version number and the status of the TrueVector driver (a component of ZoneAlarm). In section 2, we have 2 check boxes which allow for launching ZoneAlarm at startup (recommended) and to have ZoneAlarm on top during Internet activity. This second option is to bring attention when Internet activity is occurring, in case we are not using it ourselves (and meaning that it is being abused). However, this can be cumbersome for some people, so I leave it to you to determine what is best for you. Section 3 is for checking for updates, and it can be done automatically if you wish. Section 4 is for registering to ZoneLabs.

8. Conclusion

As we can see, ZoneAlarm can be a really useful tool for protecting your computer(s), except that it is easy to make mistakes and make it practically useless if it is misconfigured. This document was meant for me to share my own experiences so far with this software and to define security guidelines for everybody to use to make sure it is properly configured to make it deliver its promises. ZoneAlarm is not meant as a complete security solution, but combined with other tools it can improve drastically your network security, whether you are a home user or a network admin. I have only run this kind of configuration on a single PC so far, but I plan to use it on a test network real soon and put it to a real test, in order to have more in-the-field data rather than just theoretical. I am very interested in any experiences ZoneAlarm users may have with what is presented in this paper, or with some of their own findings with that product. You can e-mail me at floydian_99@yahoo.com.