Figure 4.
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 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.
4. Overview of the "Lock" screen
6. Overview of the "Programs" screen