Jetico Personal Firewall

I am back.

There were a lot of sharks, and everything else that lives in the sea.

I have Jetico 1.55 running this evening. I can't seem to find any bad behavior with it. Per the discussion above, I have sent the developers several bug reports, but have not been promised a license. Perhaps my bugs were not of great enough value.

Most likely the issue of protecting settings via a password is being saved for the commercial release.

 

Jetico support is one of the nicest and fastest responding support teams that I have dealt with. Please do not feel that your bugs were not of value to them. I am sure that all bugs are of value and just because they have not promised to send you a license doesn't mean they don't appreciate your help. Just keep sending in bugs when you find them.

Thanks,

Chris

 

Good to see you again Diver...

I've sent many bug reports to Jetico starting way back in August '04 before starting this thread, and so far they haven't promised me anything either.. Oh well...

 

Welcome back Diver, hope you had fun on your trip!

Im starting to really like this firewall the more I use it. The current version seems to be a pretty stable one, so there probably won't be too many more 1.0.1.xx releases I wouldn't think. I would be willing to pay for a new version even though I have sent in bug reports to them in the past too, just so long as they stay focused on improving what they already have now and don't try to add a bunch of new useless bloated features to the firewall.

 

Yeah, I agree completely with you... I'm hoping they just keep it a basic firewall primarily. It seems like most firewalls eventually begin to add useless features. It's nice when you find one that doesn't...

 

I just installed it again here tonight myself and I'm liking it a lot too. It really seems to be nice and tight, keeping everything out now. It's so configurable compared to others.

 

Running 1.55 now. I have some mixed feelings. Because it is so tight, I do tend to hear from it a bit more than I would like to. It would be nice if it had a way to protect the settings, but I have previously speculated this will not appear until the commercial version comes out. Likewise for a way to enter a range of addresses instead of a network mask.

I have some doubts about the spi for UDP (or sudo spi). My test for this is eMule and It does not seem to pass. eMule sends out the address of a port that it is listening on for UDP and other machines respond to this port. An inbound application rule for eMule is required to receive these responses. Perhaps the time allowed for the response is too short. I will send this question/bug/feature off to Jetico in the morning.

Has anyone noticed any changes in firewall behavior since the most recent XP mid month fix?

 

I think perhaps the timeout value is shorter/quicker than eMule wants. I kinda like this "feature" though. I always get late/random responses from my dns servers that generates outbound icmp type 3, and Jetico blocks this crap out nicely when you turn on the spi flag in the dns rules, probably because the spi timeouts are so tight for udp. So for me, that's a good thing...

Maybe an option to configure some of the spi values like you can in CHX-I?

 

Diver,

Jetico's SPI has two layers to it which is why I think your seeing this. Here is a response from Jetico to me on a question I had on its SPI before.

 

Kerodo,

I ask Jetico about there timeout values and here is what they told me:

 

Dukeb...-

Thanks for the help, but I do not completely understand it. However, the bit about which application is listening does add to my knowledge a bit.

If I am having a problem, it is more on the conceptual and convenience level.

A program like Jetico (and it is not the only one, but this thread is about it) requires a lot of user interaction. It is very difficult to preconfigure. Even machines prepared from an image are going to need user intervention simply because it is too difficult to anticipate all of the things that may happen. This problem is present in all personal firewalls to some extent, but is of a greater magnitude when there is some element of process control or sand boxing. Intervention also a problem with the emerging class of programs like Process Guard, Prevx and SSM.

A hobbyist may even enjoy this intervention due to its educational value. In a production environment it is a path to disaster because people would stop working and call IT who would be overloaded.

At the base of the problem is the desire for the system to be flexible and secure at the same time. Something like Deep Freeze is secure, but inflexible, and is used only for kiosk browsing.

The other extreme is the typical home machine which is run in the admin mode all the time. Actually, I have one box in the house run as non admin, but the user is not very demanding.

So, we look for automated solutions. AV's have progressed to the point where there is little user intervention. However, sand boxing and process control require excessive user intervention and knowledge IMO. these things are just not smart enough yet to separate the harmless from the harmful.

There are some very knowledgeable folks around here who seem to forget that most malware gets on systems due to social engineering which tricks an unaware user into installing it. that same user will probably give a pass to every flag his personal FW throws up. The user that knows the right responses to these utilities probably will never install any malware. That leaves exploits as a way in, but these are rarer.

There is also a fixation with the rarely used techniques of leak testing, when most firewall exploits are done with a crude but effective terminate process call.

So, the layers are:
1:User awareness
2:AV (with or without AT, good AV's do not need AT's)
3:Firewall inbound protection
4:Simple App control
5rocess control/sand boxing

Unfortunately, some folks seem to start at the bottom of the chart.

Just editorializing (and running CHX-1 this evening.)

 

Interesting, but I'm not sure if I even understand what they're saying. My understanding of things only goes so far, based on experience mostly, and when they get into tech details I get lost fairly quickly... But thanks..

 

I think I rely mostly on 1, 2 and 3. Less on 4 and 5. But tonight I'm running Kerio 4.2 beta 2 and Prevx Home, so what the heck...

 

Hi Diver,


Below I included some more info from Jetico that they sent me to try to help explain things a little better. I am by no means an expert on Jetico, I am still learning plenty also but I think this might help you to understand it a little better. I had "System" port 445 (MSFT-DS) on my computer listening and anytime packets from outside would try to come in on that port, Jetico would always popup a message asking me to either allow or deny the traffic to "System". Well of course I denied it and by doing so I would always see 2 denied logs. One ask log for inbound diconnect with the application showing as "System" (this was the application layer) and then a reject log for incoming packet (which is the network layer). So I asked Jetico about this.

All these rule based firewalls take quite a bit of user interaction at first to setup, fine tune, and get used to. Jetico has made it even more complex by adding in the process attack table though which I could personally do without. In fact I have had many problems with it in the past which they have now fixed. At least you can turn it off if you want to. I guess it just depends on how much time your willing to spend with all these different programs and how much control you want to have.

Yep I agree with you on this.




[Jetico's response]

Please note that what you and we call "System" is also
intercepted by JP Firewall not only on low Network Level,
but on Application Level too.

The picture of port listening requests looks like:

Regular Windows Applications
|
V
System
|
V
JP Firewall Application Level
|
V
Windows TDI Network level (like TCPIP driver)
|
V
JP Firewall Network Level
|
V
Windows network port driver (Ethernet card)

What JP Firewall Stateful Inspection module does is
getting information both from JP Firewall Application and
Network layers. It is necessary to block unwished packets
as earlier as possible.

If it is unwanted "Listen port" request comming from the top
of network hierarchy, it is blocked on Application level.

If it is inbound connection request, it is coming from low
"Ethernet card" level - in this case the request is blocked
by JP Firewall Network level.

And here your question is very logical: "I think it would
be better if it just got blocked and logged by just one of
Jetico's levels, in this case preferably the Network level
in my opinion."

Yes, JP Firewall really blocks inbound connection attempts
on Network level, but why we mention Application level in
that context

The answer is - it is Application level who knows that port
445 is listened by "System" (or some other application)!
It is Application level, which can define what program is
going to accept the inbound connection!

And why do we mention Stateful Inspection? Just because this
module is a bridge between Network and Application levels,
and the module stores information about "network states":
what ports are listened, what connections are created
and so on.

Hence, when inbound connection request is detected on
JP Firewall Network layer, the layer with help of
Stateful Inspection module gets information from
Application layer and then Network Layer blocks
the request.

 

This is what I sent Duke:

Its starting to make some sense, but still a bit difficult. Oddly, eMule will run whether it gets these packets or not. I could not find any explanation over at the eMule site. They cop out and tell everyone to give eMule unrestricted access for TCP/UDP Inbound/Outbound.

Anyway, the only way to get these UDP packets is to open a range of ports for inbound with Jetico. Same for every other firewall with application control that I have tried. CHX-1 lets them through. 8Signs does not, and it would not be safe to open that many ports to every application under 8Signs.

There has been a lot of debate around here about what SPI means. This throws some light on the subject.

If you did not yet, this is worth a public post.

Thanks,

-Ron (Diver)

I think the bottom line is that SPI is is being implemented differently in different firewalls and it may not simply be a matter of time outs.

 

Upon further thought I have slightly revised the layers:

So, the layers are:
1:User awareness
2:Standard security practices: updates, passwords, etc.
3:Firewall inbound protection
4:AV (with or without AT, good AV's do not need AT's)
5:Simple App control
6rocess control/sand boxing

The reasoning is that a PC can get hit by a worm in about 20 seconds just by being connected. It happened to my son. To get a virus, you usually have to do something.

Numbers 2,3 & 4 are the Microsoft pitch, but they don't say much about #1 because the level of awareness required these days is a reflection of the excessively open design of Windows.

 

I'm sure it's being implemented differently in every firewall.. It would be nice though if Jetico offered some way to adjust timeouts like CHX-I...

 

Extensive user awareness would be very nice, but also not very realistic. A person can never quantify their own ignorance.

I frequent another board where Jetico was being discussed. A member who considered himself very well protected with Mcafee AV and Sygate tried Jetico and kept getting outbound requests on ports 135 and 445. It was recommended that he uninstall his current AV and try another. Sure enough, he was infected with 2 trojans for God knows how long which his previous AV blissfully ignored- and which Sygate permitted.

Neither awareness nor security updates would have protected this particular person- but a VERY good AV would. So unless someone is totally knowledgeable about AV's, app protection/SBing are very important in my opinion.

(ps- shouldn't an Emule rule only allow incoming on 4662 and 4762?)

 

Harry Wong said:

"A person can never quantify their own ignorance."

That is a good one. I wonder if the person in your example had mis-configured Sygate. I know that by default Jetico will allow port 135 activity to trusted addresses.

With regard to eMule, it should only need inbound on those tow ports (or the two designated by the user) but, for some reason it sets up a random port to listen for UDP and broadcasts this information to every eMule server that it can find. Those servers respond. This takes place usually right after connecting and later during a global server search for a file. The UDP responses get through my router and the last one I had before it melted down. So far the only firewall that I know for sure that passes this UDP inbound traffic as a stateful response is CHX-1. Jetico requires a specific rule to allow inbound UDP on ports 1024-5000. So does Kerio 2.15. What I don't know is if the firewall knows eMule is listening on port 1070 and some misdirected traffic comes in on port 1125 where another app is listening, what sort of conflict will take place?

 

I'm still learning alot too, so don't worry about it.
I think all it means is that if a connection in the state table disconnects it then only has several seconds left and then that connection is considered to be closed by Jetico and gets removed from the table. If I am wrong please someone correct me.

 

Yeah it seems like each has there own way of doing things. Whats hard is sometimes finding out exactly how some firewalls are doing SPI due to the lack of information provided either indirectly (through help file) or directly (through email or some form of direct contact with the company). So much of what you see out there is so vague usually. Every firewall out there should be following the lead of CHX-I and there openness on how things are done.

I agree, I think adding more timeout values like what CHX-I has done in Jetico would be a good thing and allowing users to adjust the values if need be is even better. It just seems to me that it would improve the SPI even more and add greater security.

 

Has anyone tried the APT utillity from diamond CS on Jetico or anything else for that matter? I noticed that Jetico is easy to terminate. It just boils down to how much is enough (or too much for that matter). A process control app is needed to protect another process control app; its depressing.

 

Yeah that sounds really safe to me what there recommending.

I hope what I gave you helped a little. I know it can be a bit confusing at first. You can watch for instance the two layers at work if you want in the logs, just by turning on logging for the application rule and by turning on logging for the stateful inspection rule in the system internet zone which is kind of neat.

I got to run now, im going skiing!


edit: quick clarification before i leave the house. the application rule shows the application layer while the stateful inspection rule would show both layers working together.

 

Ok, question. Is the current version of Jetico stable enough with preset rules for an idiot like me, who doesn't have the knowledge to make his own rules? Also, has anyone tried it with the new version of AVAST antivirus?

I downloaded Jetico when it was first announced and had only some small problems with it. It was stealthed for me at grc.com, but then I followed this thread and saw stuff I didn't like, so removed it. I liked it otherwise and it was stable on my computer.

I'm asking because, although I'm a techno idiot, I sometimes can't resist trying new things. Can always do a system restore if things mess up. I'm on XP Home SP2 with all current updates.

 

Chuck-

The present Jetico version is stable and can be removed without incident on my machine, at least. It is more of a firewall for the advanced user. Unless you can use something like Kerio 2.15 and have some understanding of what you are doing, Jetico is not for you.

With due respect to the developers because this is not a completely finished product, Jetico PF needs password protection of its settings, termination protection and the ability to enter a range of IP addresses in addition to the network/mask convention. The first two are direct security features that seem to me to be a must for any program that attempts process control. The last one is to prevent configuration errors as network/mask addresses are easy to screw up.