A note on ZoneAlarm/Some firewall tests...

Funny thing. I always thought that ZoneAlarm was a really good firewall with good SPI because I never saw any icmp type 3 outbound to my dns servers in the logs. Very tight I thought. But when I tested it with CHX-I behind it, I found out that ZA WAS allowing those late dns packets in from my dns servers and there WAS outbound icmp type 3, but ZA just WASN'T LOGGING IT. Isn't that incredible?! I could see it all in the CHX-I logs. To think that a firewall vendor would try to fool people possibly by not logging everything? Who would have thought that ZA just wasn't logging stuff? Amazing anyway. So I'm no longer under the impression that ZA is any good. In fact, it's pretty much just like all the rest of them.

The worst part is, who knows what else it isn't logging?? Or whether it's even protecting properly. If you can't see stuff in the logs, then you're blind. There's no other way to see what's going on in a firewall. And yes, I did turn on logging of everything it offered in the options...

Live and learn...

Some background on the tests.. I've been testing many of the popular firewalls by running CHX-I in the background to see what IT would catch that the other tested firewalls missed. In all cases, the 2 co-exist fine without problems. And the tested firewall always gets the packets in and out first, before CHX-I. So you can see what the tested firewall misses by looking in your CHX-I logs.

I found that almost all the firealls tested missed stuff that CHX-I caught. Most of it was due to CHX-I's superior SPI, but sometimes it was other stuff as well, as in the ZA case. I didn't test every one out there by any means, but enough to see that most of them missed stuff, whether it was bad TCP flags or whatever. In fact, the only firewall tested that did not miss any inbound packets was Kerio 4. Kerio 4's SPI seemed to be as good as CHX-I's, catching everything, with nothing showing up in the CHX-I logs at all. Nothing.

Anyway, so much for tests. I'm back to CHX-I here permanently. But it's interesting to see how you can be fooled into thinking that everything is ok (in the case of ZA) when it could be that your firewall just isn't logging things properly.

Food for thought...

 

That why I mentioned in the other thread ....How is a average person to
know his FW is good....other than GRC...or doing leak tests

 

My opinion on it is that they've all got their faults.. But without good logging and some testing/experimentation, there's no way to be sure..

 

I know you ran NetVeda for a while....did you ever get around to doing tests
on it?

 

Nope, sorry JW, nothing on NetVeda. I had some problems with it and Treewalk DNS, so I pretty much just looked it over quick and removed it. I did notice on a previous time that it appears to allow fragmented packets in and I wrote to them mentioning this, and they asked if I'd like to see an option to block all fragments, which I said yes certainly that would be nice. I'd have to do some more testing to be certain on that one though.

I'd like to check it out again when they release the next version...

 

Okay thanks....I remember you wondering about ICMP filtering...and Arup and
I telling you that it did....I'll be looking forward to yours, and Mercuries reports.

 

You will have to refresh my memory on what type of ICMP filtering/logging ZA has for the different zones. Outbound ICMP type 3 is not always a bad thing and quite normal.

What is defining the DNS packets as late, ZA or CHX-I? Each will have it's own inspection routine. What may be passed by ZA as part of a valid connection may be considered late or out of state by CHX-I. If CHX-I is applying a stricter inspection routine to packets passed by ZA and dropping those permitted packets, how will that impact the ZA state table and it's monitoring of established connections?

Using a packet sniffer will help. You just have to make sure it is capturing the packets at the right place depending on what you want to test/monitor.

It has been my experience that the firewall that sees inbound traffic first, sees outbound last. If this is the case CHX-I would filter inbound packets after ZA and outbound packets before ZA sees them.

Missed what? Unsolicited inbound packets, packets that were not part of a user initiated connection that would be a security concern? Or just packets part of an established connection that CHX-I defines as out of state and dropping because of it's stricter inspection routine?

Or could it be the impact of packets being inspected twice by two different stateful firewalls with different inspection routines/standards?

Just a little more to chew on and ponder

Regards,

CrazyM

 

From what I could gather, it looks like ZA only logs inbound ICMP type 8. But since I didn't do any kind of scientific test, I can't be sure about all the other types. It for sure did not log outbound ICMP type 3, which it really should. In my mind, it should log ALL ICMP, in and out. And yes, I realize that ICMP type 3 isn't necessarily a bad thing, especially to one's DNS servers.

I am assuming that a late incoming DNS response is hitting a closed port and causing the corresponding outbound icmp type 3. Yes, ZA, as well as others, appeared to pass packets as part of valid connections, which would then be "caught" by CHX-I and rejected, sometimes packets with "invalid flags" according to CHX-I, sometimes packets "out of connection" (whatever that means). I'm not up on the technical details, so I can only report what I see without getting too technical about it. Sorry... That is a good point though.. how will one firewall's actions affect the state table of the other.

That is probably the best idea of all if I want to get scientific about it. That's also probably more effort than I want to put into it too. I'll leave that stuff to those more familiar with it.

I suppose that is possible, since CHX-I has no app filtering going on and my only outbound rules were for logging ICMP outbound. CHX-I definitely saw the inbound traffic last. Outbound traffic is not as certain then.

In most cases, CHX-I appeared to catch packets due to it's SPI being stricter than the firewall being tested. Whether this is really true or not, I don't know. I suppose it's also possible that the two firewalls are conflicting in some way that I can't see. But they did not appear to be. Unsolicited inbound packets were generally caught ok by the tested firewall, not CHX-I. One exception was Sygate, which seemed to allow unsolicited inbound packets to listening ports when the app rules should have denied those packets.

Could be..

Thanks CrazyM. It's probably more to chew on that I can handle here with my limited knowledge. But I did find it all interesting.

 

Hi all!

Intresting thread. Just out of curiousity Kerodo, is there any reason why you had both CHX-I and ZA filtering traffic at the same time?? Just curious. I for one wouldn't filter at all using ZA, even for testing purposes. Becuase of CHX-I using Psuedo SPI on ICMP (UDP) traffic and not ZA. Plus the fact that both firewalls are kernel level driven, they are most likely fighting for resources or conflict in some way. It is your decision and choice, but it seems like you are unsure wheather to stay without application filtering of some sort or go with. (at least this week I only use either ZA or LNS for app filtering only. I also ran tests with both LNS and CHX-I packet filtering enabled and have adverse effects...

CU
Jazzie

 

Jazzie - I was just experimenting here and playing around, seeing what would happen if I ran CHX-I with a variety of firewalls. They seem to co-exist ok. It wasn't like ZA would get some of the inbound traffic and then CHX-I would get some and back and forth. ZA always got it first inbound, and then CHX-I would get anything remaining I guess. I assume that CHX-I just had slightly stricter SPI than ZA, ZA allowing some things that CHX-I wouldn't accept..

Right now I'm using Kerio 4. I like the idea of just using CHX-I alone because it's so light on resources and gets the job done with inbound traffic, but then I start to want some app control too. Can't decide...

 

Since Kerio 4 is starting to look good and has a very tight packet filtering as you mentioned before, looks like Kerio 4 is finally here to stay.

 

Kerio 4 will probably never get over it's bad reputation... unfortunately.. no matter how good it gets...

 

Tiny is managing to get rid of its previous rep, gradually Kerio will too, once people realize it's benefits, they tend to overlook its past follies. Case in point being Sygate, many who dont use Proxy use it and love it.

 

Yeah, no matter what application filtering fw you install, it will be in that order! (Kerio, LNS, ZAP, ect... first before CHX-I) .. You ran into strange traffice before with Kerio and now with ZA> If they both filter at the packet level, you are going to see more of these type of anomolies. My advice is either RUN just one firewall, or one application filtering/Packet filtering fw in tandem. I think no matter what test you run on two types of packet filters, you are going to have adverse effects..... (I added this after original posting)..........

CU
Jazzie

 

Kerodo - like CrazyM alluded to, a more detailed list of your settings in ZA would make it easier to find out whether this really is ZA undocumented (or for that matter not immediately obvious) behaviour. Also, I wouldn't be so quick to believe CHX-1's SPI; it may be too sensitive.

Kerodo and Arup - I still would not touch Kerio4, even if I was paid money to run it. The latest beta is even more of a complete nightmare ( http://forums.kerio.com/index.php?t=msg&th=5507&start=0&S=a07eabef7010a34a782e6ac35b98b19a ) ( http://forums.kerio.com/index.php?t=msg&th=5525&start=0&S=a07eabef7010a34a782e6ac35b98b19a )

 

ghost,

I have not touched Kerio 4 either but can you tell me how to run Kerio 2.15+BZ rules and Treewalk DNS together, I am getting massive reboots.

 

Jazzie - I am done with the experiments here. I have (just tonight) settled on CHX-I with ZA for app control only. The 2 seem to work fine together. I want to run CHX-I but I would also like a little app filtering as well. I'm using ZA 2.6.362 free for app filtering, which has absolutely zero bloat and just the basic app control questions (allow/deny/server/etc). I don't even care about the component control in the newer pro versions so I'm not using them.

At any rate, I'm using your own solution and it seems to work well here too..

 

Ghost, I have stopped the experiments and settled down to just CHX-I and some app filtering from ZA (internet filtering turned off completely in ZA). As Jazzie mentions, it seems to be a decent solution.

Kerio 4 looked good, but after using the latest 4.2 beta 5 for a day or two, I saw memory leaks and inordinately high CPU usage, so I have removed it for now. I still have some hope for Kerio 4 eventually, but who knows how long it will take for them to get it stable and useful. But the core firewall itself does seem to be fairly decent. It's just all the bugs that are impossible to live with.. as you well know..

 

As a rule and app based firewall for those not running proxies, Sygate seems to be a formidable and stable alternative.

 

Agreed! If it weren't for CHX-I's strong packet filtering and TOR (Privoy) combo, Sygate would be one of my alternatives, next to Jetico or Outpost.


CU
Jazzie

 

I think CHX-1+Sygate too would be a good option. Sygate has good stateful inspection but CHX would make it even stronger.

 

Arup-

The problem with that is, there is no way of turning off Sygate packet inspection (option) like in LNS and ZA& (clones). I tested it, along with Kerio 2.15. They will run together, that isn't the issue. It is the conflict for packet filtering at the kernel level. Now if Sygate would filter only applications and gave you the info it does on any newly lauchned apps (and components) it would be the bomb! (pardon the term) But as you very well know, all firewalls one way or another have thier minuses. Too bad one of these rich flavored app firewalls didn't have CHX-I's packet inspection!!!


CU
Jazzie

 

I fully agree Jazzie, luckily Sygate has DLL protection and if combined with programs like Antihook, PG, SSM, Winsonar etc, you can have some level of outbound protection as well, Sygate does handle fragmented packets pretty tightly.