Jetico Personal Firewall

That sounds right.. And I'm thinking that it might only have a second or two left before it's closed, at most. I think Jetico is pretty tight...

 

There's no doubt about it that almost every developer is very quiet about their implementation of SPI. You hardly even hear it mentioned by some of them. ZA is one example, and Sygate is another. Sygate only mentions it briefly in their user guide, and I don't think ZA mentions it at all. I only heard ZA has SPI from someone asking in their user forum. You'd think that it would be a standardized thing by this time, with everyone following Checkpoint's definition.

I'm not sure how to judge it myself. I like those SPI implementations that screen out the random/late incoming DNS responses from my DNS servers. What happens here is that my DNS servers are sending either late or dup responses back to me, and if the firewall allows them in based on it's DNS rules, which it does, then I see as a result some ICMP type 3 outbound, because the late DNS response is hitting a closed port and thus the type 3 is generated by the OS. They're ICMP type 3 code 3 outbound. So in effect, unnecessary packets are getting thru the firewall to closed ports. While not a security threat, it seems that the firewall's SPI should screen these out.

Of all the firewalls out there, only a few can do this. Those are ZA, Kerio 4, and Jetico. I tend to view these as having tight SPI, which to me is good. But it's confusing because even CHX-I, which is supposed to have excellent SPI, can't screen out these late DNS responses. Even when you set the timeout value to 1 second it still misses a few. I think it may have something to do with connecting the response to an app (services.exe) in some firewalls (Kerio/ZA/Jetico) and that's why they can eliminate them. Not sure though. But CHX-I let's them in even though it reportedly has the best SPI.

Somewhat confusing. But that's why I like the SPI in Jetico, Kerio 4 and ZA.

 

Chuck, the current Jetico is fairly stable as Diver mentions.. It also works fine with Avast. I used to run Avast with JPF and had no problems.

I believe that the default rule set is pretty good actually. You may need to tweak the DHCP rules a little if you have XP. Just change the app in the rule from services.exe to svchost.exe. Also turn on stateful inspection in your DNS rules as well to make them a little tighter. Otherwise it's pretty good out of the box.

You'll get a lot of prompts about apps accessing the network and wanting outbound connections. At first it's a little confusing but it's not hard to deal with. Once you get things set up though, it's quite nice. And it's about as configurable as you'd want a firewall to be. There are a few things they could add like Diver mentions, but I'm sure they'll get to those in time.

It's worth a try if you're in the mood to experiment and you're familiar with rules at all.

 

Diver, I agree those are necessary additions to JPF. I would also like to see JPF run as a service. I did mention this to the developers some time ago and they seemed to be planning it, but after all this time it hasn't happened, so I think they may have misunderstood what I was asking for. Not sure...

 

K-

If the late DNS response is not a threat, why make it a design criteria? It seems to me that the CHX-1 approach is better, at least in a FW without app control. With 8Signs there is no real alternative with eMule other than to let the returning UDP packets drop. Opening ports 1024-5000 for UDP inbound on a global basis is seriously unsafe, while opening these same ports to a single application is probably acceptable to all but the most paranoid. For the record, I consider this feature of eMule to be in the category of badly behaved programs. A firewall's inability to deal with it on a purely stateful basis is probably a design decision rather than a bug. However, most NAT's will let this UDP in while excluding unsolicited UDP such as messenger spam on ports 1026 and 1027.

 

One other thing I would really like: some sort of hash-update when a program is updated!

 

SSK- Several folks have mentioned the hash update, but I believe the other issues I mentioned are more fundamental. The hash update issue is minimized by using the table structure extensively. I never have any application that appears more than twice on the main Ask User table, and there are precious few of those. That way only one new rule is required with the verdict being anoter table.

OTOH, some folks have complained that they do not like the table structure at all. They want everything in one place like Kerio 2.15.

At any rate, a hash update is not a bad idea, and certainly not a step on the road to code or interface bloat.

 

Diver, true it's not a security threat, but pyschologically I prefer that *nothing* gets in. Just a quirk of mine I guess.

Is eMule a P2P program I assume? I use one here called Shareaza (freeware also) occasionally that let's you specify in it's setup whether you can accept inbound connections or not. If you say No, you can't, then it supposedly adjusts itself to that fact. In practical experience though, I still see all the inbound UDP coming in, regardless of how I set the program options. But it does seem to work ok with only an outbound connection. Alternately, you can also specify a specific port of your choice for letting in inbound traffic. A single port. I used to run 8Signs and I set it to allow all outbound ports and then that 1 port inbound. That way it's pretty tight. Then I just disabled the rule when not using the program to be safe.

 

SSK, this is supposedly on their "to-do" list... I requested it some time ago and they agree that it's something that needs done...

 

The problem here is the stateless nature of the UDP protocol. With TCP, every packet has a connection identifier so firewalls can see which connection they belong to. With UDP, a firewall only has the IP addresses (source/destination) and ports (source/destination) to work with, so "stateful inspection" here consists of keeping track of previous UDP packets and matching up the addresses and ports. Since UDP connections do not have a closure system like TCP does, firewalls instead apply a timeout (i.e. x seconds after the last packet, they consider a UDP port/address combination closed and will block further packets).

In the case of DNS, if a server does not respond quickly enough, your PC will send the request out to the second DNS server. If the first server then comes back with a reply, Windows will send out a ICMP "Port Unreachable" since it knows that it has given up on the connection - however the firewall does not (unless it hooks into Windows' DNS system) so whether or not you see ICMP type 3s will depend on the timeout used by your firewall for UDP - a short timeout will reduce the chance of them but with the risk of blocking legitimate-but-slow UDP traffic.

The best that any firewall can do with UDP generally is the port/address comparison with a user-adjustable timeout. Special treatment could be given to DNS traffic (e.g. considering a connection to DNS server A closed if Windows sends a similar request out to DNS server B) but this would be a lot of work for a very specific (and not security-critical) situation.

 

P2K to the rescue with an understandable explanation, thanks.

K- Emule is P2P. It can specify a fixed inbound UDP port, but this is for completely unsolicited packets.

The other inbound UDP is a random port, usually between 1024 and 3000. This floating port accepts responses to outbound UDP packets, but the time out is realtively long. Not too long for CHX-1 or most NAT's, but too long for Jetico PF and many others, as best as I can guess from the above discussion. It would be nice if this port could be fixed as well, but the authors have chosen not to. The program runs without the connections, but probably not as well as it could with them. As noted above, they recommend that the program be given trusted status with full inbound and outbound access for UDP and TCP. This is no worse than using ZA free. I don't think it is necessary to turn the rule off when not using the P2P application under an application based FW as the FW takes care of that.

A single inbund port with 8Signs does not bother me, it just shows as closed when not in use. But a range of thousands bothers me since something else may be listeniing in that range that you do not want to be listening.

 

I just tested this out:

Scanned ports 1024-1024 using shields-up, with and without eMule running, but with a rule allowing inbound UDP on these ports to eMulle. The result was stealth every time. Some FW pop-ups from other applications listening in this range, but that was it.

 

Hi all,

can anybody explain me why there is a exclamation mark before rules which are leading into Application Blocked Zone?

I thing exclamation mark means there is something wrong with the rule, but it is present since default configuration.

Thank you very much.

 

Diver, I agree that other issues are more pressing. I just chimed in...

 

I do not know what the exclamation point means either, but it is present in my default installation. I do not think it means that anything is wrong.

 

Nope, nothing is wrong I'm sure. It's always there in my config also.

 

Thanks once again P2k for the explanation. Sounds reasonable. It's not something that I really worry about. It's more of an intellectual curiosity than anything else. If possible, I like to have the firewall block the late dns replies. CHX-I has that nice ability to adjust the timeout values.

 

I rarely use p2p myself, but when I do it's always a slight problem. I tend to just allow it full reign in and out in app based firewalls. But in rule based ones without app control like 8Signs or CHX-I, I usually have to create rules and then disable the rules when not in use. Any program that needs open inbound access is always slightly problematic I guess..

 

K- You have been saying that 8Signs does not do SPI for UDP. I tried it this evening (2.26) and it worked with eMule. There were no rejected UDP incomming connections in the log under circumstances where they would have shown up with Jetico. This may be a recent change.

 

Hmmm... that's very unusual and not what I expected. As far as I know, and based on looking at the firewall interface itself, 8Signs only does TCP SPI. But perhaps I'm wrong?

 

You just need to be careful when adjusting timeout values as packet loss and slow return times for UDP over the Internet are not unusual. Seeing ICMP error messages (type 3 unreachable) in response to late packets from DNS servers is normal.

Regards,

CrazyM

 

K-

Whoops, I may have spoken too soon. Looks like I imported a rule left over from an earlier installation that blocks logging of the inbound UDP leftovers. Time to try CHX-1 again. Fixing to have a major thunder storm outside...It was a dark and stormy night....

 

Yes, that's why I played with CHX-I's UPD timeout and set it to 1 second, but then later decided it was best to leave it at a higher value. The default of 60 seconds seems quite high, but something in between should be adequate for most situations I would think...

 

Ok, thanks for clarifying that... saves me some investigative work...

 

The default DNS timeout in my router configuration is 5 seconds (general UDP timeout is dealt with seaparately and set at 15 seconds, default is 30). I will still see the ICMP type 3 but allow those outbound in the firewall to the DNS servers only.

Regards,

CrazyM