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.

5. Overview of the "Security" screen

7. Overview of the "Configure" screen

Back to homepage