Jetico Personal Firewall

It's a good idea to have a backup. I myself do frequent reformat and reinstalls of Win2k, so maybe that's why I don't mind playing with all these firewalls. If something goes wrong and things get hosed, I just reformat. Takes a few hours, but it's no big deal to me. Everything important is on CD.

 

To: Zorro

The tables you mention were set to ask. The FW did not ask. It just locked up the system completely. Perhaps by the next update they will fix it. I had a few other applications that place an icon in the taskbar and none of them had a problem.

 

Java Lock-up Solved

To troubleshoot a lock-up in Jetico Personal Firewall when the process attack table is suspected, I had to change the default action (next to last rule on process table) to continue. Then the Java binaries were able to run and the results in the log showed what the process attack table was responding to. The events tended to be stuff like access to low level system memory or attacker opens application with hidden window. javaw.exe or some of the other binaries go where it says attacker. Presto, everything works and the next to last rule on the table goes back to the default of ask.

Oddly enough the icon did make a difference as when the icon shows javaws.exe is started.

Exactly why this caused lock-ups on my system and not on others is not known, but is probably related to different low level drivers for some other function, possibly video.

 

Doublepost

 

Diver: Good to hear that the problem is sorted!

 

I solved th problem, but I still feel more comfortable with Kerio 2.15. I have a bunch of nits and picks with Jetico, some of which may get solved in the future and some not:

1. When adding a new rule the display may freeze if no existing rule is highlighted.

2. Mot possible to add an ip address range. Only address/mask are allowed. I just do not happen to know how to use those masks as well as I would like to.

3. Perhaps not so important, but it is not possible to enter a list of non adjacent ports. A separate rule is needed for each one.

I realize that some people feel that sand boxing is the way to go, but I am not sure if I need or want it. It does provide additional protection, but at a cost in convenience. My experience with the Java problem is proof of that. Anyway, I thought my post may be helpful to anyone with the same or similar problem.

 

Well, switched back to Look 'n' Stop.
No serious problems with Jetico, and I even like the design very much, but with LnS my surfing and general computer use is faster.

The firewall looks promising though.

 

Hi,
I have a question for those who already mastered the rule creation and handling. If the processing of a communication event stops when a Reject rule is matched, and the Application Table ends with a Reject rule matching simply anything, how on earth could the tables coming after the Application Table be ever processed? No traffic should reach those tables because it should already blocked by this Reject rule.
-hojtsy-

 

The process attack table is what was causing problems for me too I discovered. Each time I connected online Jetico would freeze up immediately and stop responding. When I changed the default action of ask to accept I then found that there were no longer any problems anymore. After a bunch of testing and investigating I finally found out that it was due to the event Attacker Starts Application with Hidden Window. The attacker being Explorer.EXE and the application being Jetico's fwsrv.exe.

It sounds like there are still alot of issues yet that need to be worked out with the process attack table. Going all the way back to the beginning of this thread it sounds like people were having problems with it. I have been in contact with Nail from Jetico a couple of times now to try to help them resolve at least the issue that im having. Hopefully they can fix all these issues once and for all very soon.

 

I feel much more comfortable with Kerio 2.1.5 too which is why I have gone back to it. The layout is just so much more simple and straight-foward and easier to use.

In Jetico it just seems like everything is spread out all over the place and there are just way to many sections in it. The tree structure in the rule editor I found to be very tedious also. All the selections should be front and center in the window, so that you don't have to go searching for things. I could never find where the tcp flags was located in the rule editor for instance, it was just so difficult to use. Nail over at Jetico has said that they plan to get rid of the tree structure in the rule editor, so it should be much better.


I agree with you on the ip range and port lists, I would like to see that get added to. Also in the logs I would like to see them include the tcp flags and in the listening/active connections part it would be nice if they showed the protocols.


I think this firewall could be pretty nice eventually. We'll just have to see how much they care and listen to users input. Only time will tell I guess.

 

I think JPF is pretty good for a version 1.0. It's stateful inspection seems to be "tighter" than most others.

There is one thing that I discussed with them and I couldn't get them to see it my way though. I noticed that when packets come in to a port where there's a program listening on that port, then JPF seems to let the packet in to the operating system whether you allow it or not. For example, I have Mstask listening (on my W2k) on port 1025 all the time. Whenever I get a packet coming in to 1025, whether I accept or deny it, I always see an outbound RST ACK in the logs. This shouldn't be happening. JPF should prevent the packet from getting to the OS in the first place I believe, and thus preventing the outbound RST ACK. But instead, it seems to let the packet in. This is only happening on ports where there's a program listening. I argued with them about it for quite some time, but they said it had to be that way for some reason. I think they're wrong though. In my view, NOTHING should reach the OS unless you specifically allow it, if the firewall is set up right. I had to create a block all incoming rule for all TCP with the SYN flag set and the ACK flag cleared to fix this. While it fixes the problem, I shouldn't have to be doing this.

 

Hi Kerodo,

Thank you for bringing this to my attention, I didn't know about this before. Tonight I reinstalled Jetico just to test this out on my own system. Port 445 on my XP system is always listening, so when I scanned my system I noticed port 445 TCP RST ACK in my logs showing up as being blocked outbound but nothing showing up as being blocked from coming in. (BTW I now see there is tcp flag info in the logs when you expand the Misc tab)

Whats really strange though is that I also noticed port 113 was being blocked out as well and I don't even have any programs listening or connected on that port! So obviously Jetico is allowing packets in on that port as well. I don't like this one bit, nor do I like it that you had to argue with them over it and they still didn't do anything about it. I agree with you that this should be blocked by default unless you have a rule setup allowing it in. The block all tcp you mentioned above seemed to work for me to if I put it under the Root table. But as you mentioned, we shouldn't be having to do this. This is something they should fix!

 

Yes, I agree that it needs fixing.. It's not right. Nothing should be allowed in. What you're seeing is JPF allowing the 445 packet in and then when the OS responds with the RST ACK, you're seeing the outbound response being blocked by JPF's stateful inspection, or so they say. I don't like the situation at all. So the incoming packet never gets an outbound response, but if you ask me, as I said before, no packets should ever be allowed into the OS to begin with. They're just not doing things right..

I believe port 113 is Ident. I asked them about this also, and they claim that they're allowing 113 in because some systems need it. I suggested that they should block 113 incoming and then let those who need it create a special rule to allow it. They didn't seem to agree with me on that either.

Just a few things that I don't think they're doing properly...

 

Hi all

Anyone can post a file of rules with best protection ?
I need an example of configuration file.

Thx

 

I just tried the new 1.0.1.48 version of Jetico and the problem I was having before with the process attack table is still not fixed I see. Nor have they responded back to an email of mine I sent them last week about Jetico allowing packets into the OS. I guess they don't want to talk about that one anymore lol. I can't say im all that impressed with them at all.

 

The problems that I had with process attack conflicting with Sun Java have been solved. I am impressed.

I did a bunch of firewall scan tests and all of them showed the ports to be stealthed.

In one situation some listening ports were detected, but it turned out that another rule for the same appliction was explicitly allowing the contact. After fixing that, the problem went away.

 

Just curious, has the listening port problem been solved to your satisfaction Kerodo or Dukedevil?

 

No, I believe that the problem still exists. I have just reinstalled the latest JPF, and although I believe they're doing things wrong with that problem, I must admit that it doesn't affect me much since I added a rule to block all inbound TCP. So for all practical purposes, the problem is solved.

I did find one other problem too. I copied my previous config file to the configs folder and then did a File open to load it. Then I selected the new config, renamed it and so on. Then when I exited and reloaded JPF, I found that it didn't remember my previous policy config at all. It seems to just use "Optimal" config. I even looked for my other config file in the Options menu so I could check it to load at startup, but it doesn't show up. So I reported all this to Jetico and we'll see if it's a bug and gets fixed I guess.. I'd like to be able to have several configs loaded and switch between them if I need to.

 

Dukebluedevil... I'm not surprised they didn't respond yet. I had talked at length about this one with Nail at Jetico. In the end, he kept explaining it away. At first, I noticed the problem on programs listening on Localhost. So they DID fix that one. But they never acknowledged that the other port listening problem was even a problem, let alone fix it.

I'd suggest pounding away at them about it. I'll send another email myself on the subject and see what happens. But for now I've just used that block all rule on incoming TCP and it seems to take care of the problem.

I really like the firewall a lot. I'm planning on running it for a while now.

 

Diver... all ports will show stealth on scans such as grc.com and so on. However, if you look in your logs after the scan, you will see outbound RST ACKs every time a scan hits a listening port. The RST ACK never gets out or back to the scanner, so you get a stealth result, but the packets should never be getting in to the OS in the first place, as evidenced by the outbound response of the OS (the RST ACK).

 

Kerodo,

I now understand what you are talking about and have seen the activity in my logs, which is interesting because both of these listening ports are blocked with an explicit application rule for inbound TCP.

Could you please explain your solution with a bit more detail, like where do you put the rule and its parameters? I guess it is a "system ip rule".

 

That's interesting that it's getting in even though you have a rule blocking those ports.. must have something to do with the rule placement..

I simply put the rule in the System Internet Zone table. Near the top, and make sure it's BEFORE the stateful inspection rules at the bottom, otherwise it'll never get seen apparently.

Create a System IP rule to Deny All TCP Incoming, then go into the protocol-specific options at the end of the edit box and edit the TCP Flags. You want to Set the SYN flag, and Clear the ACK flag. Leave everything else alone. That should do it.

 

Just a note.. I wrote to Jetico just now and pleaded with them to fix the listening port problem. I also mentioned this Wilders Forum and the Jetico thread. So perhaps they'll take notice and maybe even answer some questions here (although that's probably wishing for too much...)

 

I don't know what pleading with them will do...

First I tried placing the rule in the root, but it would only work if limited to the known listening ports. Otherwise, i could not connect to the internet.

Then I tried it your way and it works without specifying a port.

Question: How do you know to specify the ack flag as not set? In my log the incomming packets had syn set and that was it.

I also just noticed that this rule is blocking some legitimate traffic for an AV automatic update originating on port 20 of the remote, so it would have to be limited to the listening ports, and even then it might interfere with some traffic.

I think that I will leave it alone for the time being.

 

I think you have to have the ACK flag cleared so you can get incoming responses back from legitimate outgoing TCP traffic. But I'm certainly no expert in these matters. I simply did what Nail at Jetico recommended. If you set the SYN flag then that would block incoming connection attempts, but you have to have some way to allow legit return traffic I think, so I assume that's what the ACK flag cleared is doing.

Don't know why you're have trouble with that AV program on remote 20. I assume you're using the FTP Client presets or something similar? I use this rule as mentioned above and everything works fine for me here, including AV updates, browser, email, newsreaders, and any other programs using various remote ports and so on. You shouldn't have to specify any ports... Are you sure the AV thing worked ok before the block rule? Maybe you need to set up a rule for that program alone in the ask user section? Or create a rule above the block all rule to allow incoming from remote port 20 for that app?

As a last resort, if you still have conflicts with the AV updater, you might instead of blocking ALL TCP incoming, just block it for those listening ports. That would probably work just as well.. Put the rule in the System Internet Zone. Try using the same flags settings also so you don't block legit responses to outbound traffic on those ports, if any.