Three more remarks/questions about ZA

Well, you don't have to use the Trusted Zone for this; you can create a special group instead. You referenced Groups in your other thread so it sounds like you know how to make them already, but just in case... The easiest way to make a group is in ZAP > "Firewall" panel > "Expert" tab > "Groups" button which brings up the Group Manager. Use the "Add" button. Name the group (something like "P2P Servers") and give it a description, then simply add all four servers, each as individual "locations" in that screen.

Now, use this group in your rules for the P2P program. They aren't in the trusted zone and will only be used in whatever rule you decide to enter that group name in as either the Source or Destination of packets.

Yes, the key point here is that a group set up as I described above is not in any zone, which means those servers (IP addrs) would be treated the same as any other Internet site - except for any rule in which you use that group name in either source or destination fields.

Unfortunately, I don't use any P2P software, so I may need to use another example, but let's see... POP3 email. The rule you allow for that is Source: your computer/TCP any port (or limit ports to the range 1024-5000); Destination: your ISP's email server/TCP port 110.

But, this is where I'm unsure because of not using P2P myself... When you run the P2P client yourself and it reaches out to look at available files from "out there", are both ends of the connection on only the two ports you mention, or are those ports just the "destination ports" in all cases? If so, then the source ports might be in the range of ephemeral ports (1024-5000), but again I just don't know. At the very least you should make sure which it is and set up your rules accordingly.

You should not need to because you are granting server rights to the P2P program right? So ZAP should allow the traffic in regardless. (There are sometimes weird circumstances where you might need to add a port to the Allowed port list you mention if things just aren't working, but that is very rare in my experience. Try it without. If it doesn't work, try adding them as allowed incoming ports just as a test, but you should be able to get it working without those ports there.)

Please describe exactly when you are getting that error. The only time XML data is processed should be when you are either using the Backup / Restore feature, or perhaps while making significant configuration changes. Are you getting these errors at other times during normal operation or just when trying to run a Restore or reconfigure your settings and/or rules?

I need to know more about when you are getting these errors as noted above.

That is the Backup / Restore feature available at ZAP > "Overview" panel > "Preferences" tab > "Backup and Restore Security Settings". Backup outputs all your rules and configuration settings to a new XML file for use later in a restore operation. Restore loads in an existing XML file (made from a previous backup) to reset / reload all your configurations when you need to replace or fix your ZAP configuration.

Ah, I remember that discussion now.

All I can say here is this... First, obviously this is not supposed to be happening. I think I posted last time on this that it must be a conflict or some similar incompatibility, though I can't say what. It doesn't help to know that it is kernel versus user mode or any of that because none of us have access to the internals of the ZA firewall. This information might help when you report this problem to Zone Labs and work with them diagnosing the problem, but those of us who are merely users of the product can't do anything about this.

However, that said I'm wondering if this problem is related to your XML problem (and any other problem you might be having) and the source of it all is a bad configuration. There's no way you should constantly be getting XML parsing errors. You also shouldn't be getting runaway CPU usage by vsmon.exe either. But, if there is a corrupt configuration then maybe, just maybe that's behind all the problems.

A full clean setup of ZAP can be accomplished as follows. When you have a good backup XML file that stores what you consider to be a good configuration, you save that file somewhere safe and then wipe your current ZAP configuration. To do this... 1. Shutdown the network connection. 2. Shutdown ZAP using the proper exiting procedure from the systray icon. 3. Check to be sure both the ZAP client and vsmon have exited (in Task Manager). 4. Delete all files from \Windows\Internet Logs\. 5. Start up ZAP. 6. Check to be sure the client and vsmon have started in task manager, and look in \Internet Logs\ - there should be a new set of replacement ZAP true vector database files there now. 7. Start your ISP network connection up. (If you get an alert about svchost trying to connect out, click Yes.) 8. Go into ZAP > "Overview" panel > "Preferences" tab > "Backup and Restore Security Settings" > "Restore" button... When it asks for a XML file to restore, give it the one you saved above.

Now, that is how you can get a really clean ZAP setup. Restore is supposed to work as described above. However, experience has shown me sometimes you have to reload these files more than once because of un-displayed parsing errors during restore. So what I do is I continue on like this:

9. Disconnect network again. 10. Shutdown ZAP again. 11. Start ZAP up again. 12. Connect the network. 13. Go into ZAP's Preferences tab again and twice in a row restore the same XML file, one right after another.

Don't skip any of the steps, especially the closing and restarting of ZAP; this is a very exact set of instructions!

For me, this procedure has always ensured a clean and complete restore, with no missing rules or settings. (It isn't always necessary, but it does always work.)

At this point, quite frankly I shutdown the network and ZAP, and then reboot my PC cleanly just to make sure I had everything perfect before testing anything else, but that may just be me. My system reboots in about 60 seconds and I can execute the above ZAP clean restore process, with reboot in about 6 to 8 minutes. I do this every month or so just to ensure a totally clean ZAP configuration and I rarely have any problems.

 

I don't advise setting any expert rules on the ZA client. Just use the access settings and chose either Allow ("checkmarks") or Ask ("?") for all fields in program line for ZAP. I find no value in trying to further control ZAP itself with custom rules.

Sounds like you need to repair the file associations. Did you install some other browser at some point? Do you only have IE now? One of the easiest ways is to have IE reclaim the full web file associations after you've let another browser have them is to let IE check and alert you: In IE > Tools > Internet Options... > Program tab > check "Internet Explorer should check to see whether it is the default browser". If another browser had the associations, this may cause IE to alert you and have it reset them all the next time it starts.

Otherwise, you may have to look into a more complex IE repair or reinstallation of some sort, but that's a rather different topic than this.

 

Re:The last three (short) questions about ZA

Yes, that is correct. Basically, you go into the port number box (where 'Any' is by default) and type in a port range such as your example ('1024-5000'). Take a look at the image at this link. It's from the SpywareBlaster rule thread I noted before and it shows the use of ranges of ports a couple times.

I'm sorry, I really not sure what you are asking here? Can you explain your question in more detail? Are you asking why you would make global rules in the Firewall tab's Expert section? If so, the example I gave in your first thread here, for the blocking without logging worm traffic was a good reason to make a new expert rule.

And I'm not at all sure what you mean by "What if I leave all fields empty..." - If you do that, you might as well not make a rule at all.

ZAF can't do any of these more complex things. It just has basic inbound and outbound protections, much like the defaults (uncustomized) in ZAP. In the ZA Free product, you set a program to either allow, ask or block, and have no custom settings at all for a program. In its Firewall tab, you have just trusted, internet and blocked sites - no detailed port rules or custom allows or blocks.

 

Ah, I see what you mean.

Expert rules set up in the Firewall panel are really just for customizing your access levels; they are not required in order to be secure.

By default, if you have the Firewall slider for the Internet Zone set to High, then ZA blocks all unsolicited packets. The only point in making rules under these curcumstances are to: 1. allow some things (some form of access) that you want to come in and which is being block by default in ZAP; or 2. to perhaps set different time-of-day restrictions, or different logging settings that vary from the overall configuration in ZAP.

Leaving the expert rules blank in the Firewall tab is not a bad thing at all. They are available merely to customize (usually to expand) the accesses being allowed.

But, the expert rules in the Programs section are a different case. You can add a lot of security by adding expert rules to certain programs - my Outlook Express example is a good one. You see, with ZAP if you allow a program but don't define any expert rules for it, then it is allowed to access any port, at any time, to any destination. With Program expert rules you can dramatically narrow the access of a program. So, these are worth adding in order to increase security. But global rules in the firewall section are not needed to increase security - rather they are used to allow or change access, not secure it.

 

The image you attached... Is that absolutely all that is ever alerted? If you look in the Log Viewer panel, is there anymore information? I can't tell anything just from that alert image.

But, it could be related to any of the advanced program controls. Modules, components of any type can cause alerts even if they themselves do not access the network - just so long as they are some how connected to another program, they can be involved in an alert. This could be the case here, but without more alert or log information, I can't say.

(Nice clipboard program, by the way. )

The terminology of incoming and outgoing traffic never changes, regardless of who initiated the connection or the request for the movement of the data.

It may be best to think of the ZA firewall as if it was a separate thing from your computer (in a logical sense), as if it was an external firewall of some sort. Incoming is always packets from the Internet coming in to your PC and outgoing is always packets generated on your PC heading out to some place off your PC, "through the firewall".

The place where the terms do vary like you are describing are "source" and "destination"... When you define rules, your PC can be either the source or the destination depending upon the context of the rule. If it is a rule to control incoming packets, then your PC is always the destination (and the source is out on the outside network). If it is a rule effecting packets going out from your PC to the world, then your PC is the source and the destination is somewhere out there.

But, no matter the rule or context, outgoing packets are always those heading from your PC to the Internet regardless of the program involved or the system that requested the movement of the information.

 

I'm sorry, I've never seen that error.

Generally, when you use the Backup button to create an XML output file, it should be fine when you use that file later for a Restore. (Well, so long as you don't try to edit the file or alter in it any other way.)