Jetico Rules Tutorial

I will describe the rule processing order of Jetico Firewall.

Chapter 1)
Rules in Kerio 2.x
I will start with describing the rules of the Kerio 2.x firewall and build on this knowledge later. If you are already intimate with Kerio 2.x skip to chapter 2.
In Kerio the firewall rules form a single ordered list. Any time a communication event is generated the firewall engine starts to compare the parameters of the event to the rules. First it compares the event to the first rule in the list. If the parameters of the event match with the filter criterias of the first rule, the firewall either Allows or Rejects the communication depending on the verdict indicated in the first rule. If the first rule did not match the event, the engine continues to compare it to the second rule, and all further rules until a match is found. When a match occurs the further rules are not processed, and are completely ignored for this event. The parameters of a rule can be of two kind, either it is Any, or something specific. Only the specific parameters of a rule are compared to the event and a match of those means a complete match. A rule with all parameters being "Any" would match any events. A simlified list of event/rule parameters are:
- Application name with full path
- direction (inbound or outbound)
- protocol (TCP or UDP)
- local IP address
- remote IP address
- local port
- remote port
Usually you would like to restrict the kind of communication an application is doing. For example you may want to restrict Internet Explorer from accepting inbound connections, but allow it to create outbound connections. You would need 2 rules for this:
- Application: iexplorer, direction: inbound, protocol: Any, local IP: Any, remote IP: Any, local port: Any, remote port: Any, verdict: Reject
- Application: iexplorer, direction: outbound, protocol: Any, local IP: Any, remote IP: Any, local port: Any, remote port: Any, verdict: Allow
Since there is no event which could possibly match both of these rules, the order of these two rules are not important. Anyway I think putting he Reject rules as first is better practice, because in several other cases it will be the only good solution.
Suppose you have these two rules in your ruleset. Then you realize you want to block iexplorer from connecting to remote port 138. The only valid use of this port is for NETBIOS, and iexplorer is not supposed to do any NETBIOS communication. You create a rule:
- Application: iexplorer, direction: both, protocol: Any, local IP: Any, remote IP: Any, local port: Any, remote port: 138, verdict: Reject
The question is: where should you put this rule in the list? If you would put it as a third rule, processing of events will never reach it. Even if the remote port is 138, the second rule would Allow the communcation, and this new rule would not be processed. So you need to put this rule before the Allow rule, either as first or second. Later on you might decide that you do not need NETBIOS at all, and you want to block this port for any application. The only modification you need is to change the last created rule in a way that the Application parameter is "Any". After this be careful to put all rules for other application below this NETBIOS blocking rule, so that this rule would take precedence over them. (Note that full blocking of NETBIOS affects other ports and protocols and will not be discussed here).

Let me describe a problem with this ruleset design. For example you might have 4 applications, all of which are web browsers, and you want to allow for each of them to create outbound connections to any of 6 specific remote ports. Basically you would need 6*4 = 24 rules to fully describe this. In this case you are fortunate because Kerio provides an unusual feature, to allow a list of unrelated ports in a single rule. So you only need 4 rules for your 4 applications. But what if you want to block all 4 of them to accept inbound connections? You need to create 4 more rules. Any change you would later decide to the restrictions of web browsers, would need you to create 4 more rules, or change 4 different existing rules. Consider that you have 6 more different applications which are using the same HTTP protocol for automatic updates, and you want to give them the same permissions. You will end up creating very lots of rules. It will be very hard to check that you have not made an error, and even the engine might slow down with the increasing number of rules.
In Kerio the usual solution is that you are starting to give more permissions to applications, then necessary, just to make the ruleset more simple.

Chapter 2)
Rules in Jetico Firewall
In Jetico the firewall rules form a ordered list (the root table), elements of which can either directly contain the verdict or invoke the processing of other similar rule lists.
Every event generated by the Jetico Firewall is processed by feeding it into the root table and applying the rule sequence found there. If an event matches the filter criterias of a rule, the verdict of that rule is applied. The verdict may be:
- Allow: in this case the event is processed and no other rules will execute
- Reject: in this case the event is processed and no other rules will execute
- Ask: in this case a learning popup dialog is displayed. Uppon exiting the learning mode dialog a rule is inevitably created. The new rule is supposed to process the event.
- Continue: the event is not processed even if it matches this rule. The matching of the rule is logged if the logging is enabled for this rule. Processig of the same event continues with the next, and further rules.
- Invoke an other table: in this case the event is sent to a different table. Processing of the event continues with the rules in the invoked table, starting with the first rule. If no verdict was made in the invoked table, the processing returns from the invoked table and continues with the rule coming after the invocation. The invoked table may also invoke other tables as a verdict of rules found in the table, but loops in this invokation chain is prohibited. (Programmers could think about this table invoking as a call to a subroutine, or procedure).

The events of Jetico Firewall can be grouped into 3 big categories:
Group 1: Application events
- access to network
- inbound connection (TCP)
- outbound connection (TCP)
- listening port (TCP)
- receive datagrams (UDP)
- send datagrams (UDP)
- listening datagrams (UDP)

Group 2: Network events
- incoming packet
- outgoing packet

Group 3: Process attack events
- attacker installs system-wide Windows hook
- Attacker starts application with hidden window
- Attacker writes to application's memory
- Attacker injects own code into application
- Attacker modifies child process
- Low-level access to system memory

To match these 3 different group of events, 3 different kind of rules was defined,
- Application rules can only match application events
- Network rules can only match network events
- Process attack rules can only match process attack events.

When processing a specific event only those rules should be considered which are defined for the event group of the specific event. For example during processing of an "inbound connection" event, network rules, and process attack rules can safely be ignored as they will never match it anyway.

Chapter 3)
Communication Example

Lets consider that you start Internet Explorer after a new install of Jetico Firewall. This chapter will cover what kind of events will be generated, and how will those events be processed by the ruleset.
If your default page in iexplorer is empty, no event will be generated. Then you enter into the address line www.wilderssecurity.com. iexplorer creates and binds a new TCP socket. This results in a chain of "access to network" events, first coming to the parent processes of iexplorer, and then iexplorer itself. If you started iexplorer from the desktop, then it's only parent process is explorer.exe.

Event 1: Application event, "access to network" for explorer.exe
The event is first matched to the first rule in the Root table. The first rule in the Root table is an Application rule, matching any event. The event matches the rule, and executes the verdict. The verdict is to continue processing in the Application Table. The event is matched to the first rule of the application table. The first event in this table would block any events if the remote IP address would be in the Blocked Zone group. As this event do not have an IP address parameter, it could never match this rule. The event progresses to the second rule of the Application Table, which is supposed to allow any application events, where the remote address is in the Trusted Zone. Again, since the current event do not have any IP address it could not match this rule. The next four rules allow creation of listening ports, and sending/received UDP traffic to/from your name server. They all require a specific event, none of which is "access to network" so they will not match the event. It goes to rule 7 in the Application Table. This rule matches any application event, so it will match the current one too. The verdict is executed, which is to continue processing in the System Applications table. The first rule in the System Application table allows the "access to network" event, but for the "System" application only, so it will not match the event. Somewhere in the middle of the table, there is a rule where the application name is "explorer.exe", and the event is "access to network". This rule will match, and the verdict is "Allow". The event is processed.

Event 2: Application event, "access to network" for iexplorer.exe
The same path is followed by this event into the System Applications table. But in this table no rule matches the event, because of the application name. After attempting to match to the last rule, the default action is executed. The default action is displayed below the last rule, and selected to be "continue". This means, that the processing of the event continues from the point of invokation of this table. This table was invoked as a result of a rule matching in the Application Table. The next rule to be checked is the rule below the one which invoked the System Applications table. The next rule matches any application event, and invokes the "Ask User" table as a verdict. By default the first rule of this table matches any application event, and executes the verdict "ask". This verdict means, that the user should create a new rule, which would decide the fate of this event. While the user is creating the rule, the triggering application (iexplorer) is stopped. A popup dialog is displayed by the firewall, indicating the parameters of the event. Let us suppose that the user is not fully novice, and knows that iexplorer will need the permissions which are predefined for generic web browsers by the vendors of Jetico. So he/she selects the "handle as Web Browser" choice on the menu. This instructs the firewall to create a new rule, just before the rule which had the "ask" verdict. The parameters of the new rule are: appliaction="iexplorer", event="any", verdict="Web Browser". Since the event still needs a decission, it is matched with this new rule. The rule matches, and the verdict is executed. Processing is continued in the Web Browser table. The first rule of this table matches the "access to network" event, regardles of the application. The event is matched and the verdict (Allow) is executed. After this, the call to the socket bind function in iexplorer successfully returns.

The next thing attempted by iexplorer is opening an outbound TCP connection to the remote port 80 of the HTTP server. When iexplorer requests from the operating system to create this connection, a new event is generated in the firewall:

Event 3: Application event, "outbound connection", local IP: 0.0.0.0, local port: x, remote IP: 64.91.226.241, remote port: 80, protocol: TCP/IP, application: iexplorer.exe
The event goes through the same path as event 2, until it reaches the Ask User table. While event 2 was generated, a new rule was created which is now the first rule of this table. This rule matches any application event where the application is iexplorer.exe. The event is matched and the verdict (Web Browser) is executed. Processing of the event continues in the Web Browser table. The second rule of this table matches any "outbound connection" where the remote port is 80, so it matches this event. The verdict is Allow, the event is processed.

** I will continue this post later as my time permits. Please check back. **
-hojtsy-

 

It is starting to look to me that the tables in the root table are indeed processed in the order that they appear. So, it looks like Application oriented rules and the tables they refer to get a first crack at things and then the lower level System IP rules and the tables they refer to are processed later.

Anyway, this tutorial looks to be starting out right by building on the rulemaking process of the well known Kerio 2.15.

 

:BUMP:
I continued post 1.

 

thanks for the tutorial on jetico ...

I used to have kerio 2.1.5 installed on my box, then used sygate, outlook and finally looknstop. BUT jetico is by far the best. runs smoothly on my w2k sp4 (LITE version, but with all relevant updates) I like that it has application AND process level checking - which works fantastic (I did all the leaktests I could find with 100% detection and blocking). let's not forget SPI, a nice compact GUI and very low CPU and RAM usage. once you understand the rule processing (the help file is great) then it incorporates all what I expect from a dedicated firewall (I don't need a firewall to check for virus etc.). so, I can also add my experiences if the need should arise ...

CHEERS

ahh, I forgot, IT'S currently FREE of charge !!

 

How is this relevant? What methods does the Jetico Firewall take to ensure that the engine does not slow down with increasing number of rules? Regardless of how rules are related to others the key point of the engine is that it is I think (relational?) database based (uses Metakit). That is, I am assuming a rule is accessed in O(1) time no matter where it is. Kerio 2.15 I believe finds rules in O(n) time. Hence, Jetico Firewall will only result in a noticeable speed difference when the number of rules is very large. And what exactly do you mean give more permissions to applications than necessary just to make the ruleset more 'simple'?
Rather the term you are after is 'save time'. An addition to a list of rules does not add much more complexity if the list is already somewhat long. But adding rules for each application for the scenario you mentioned is tedious and uses up a lot of time.

Ok, so this equivalent to the checkbox rule selected part in Kerio 2x with logging and alerting ignored. Can I ask a dumb question here - When would this be useful, except to check that the firewall is working correctly? (A simple checkbox would be so much easier)

Can someone give an example of how this could be useful. Why did Jetico choose to have this based on parts of the table rather than rules. eg. A rule dependent on another rule, but this rule cannot be dependent on anything. Is Jetico's method more powerful? My guess is that it could be useful in relating Application rules with System-wide ones, but I don't see how or why.

So the point of an 'access to network' rule is to check blocked IPs first. Am I right?

I apologize in advance if I did not read your post properly and my questions were already answered by them. And yes, I do realise you're not the Jetico support line. And yes I do know I'm being critical on Jetico Firewall. I just want to know whether there is actually a very good reason for the mess that they call an interface.

Re: Kerio's problems with multiple user editing or similar rules:
Maybe this could elimated by just adding group capabilities, similar to how Kerio 3 was progressing.

eg. Application groups (just application names)
Rule groups (rules with no application assigned to them)
Time groups (allowed time periods)
Address Groups (IP, hostname addresses, masks and ranges)

This is what I'm considering doing with my own project.

 

Thanks for the Jetico rules tutorial Hojtsy. I've been running kerio 2.1.5 for about a year. I really like kerio, and plan on staying with it, unless a bug is discovered in the future. If that happens, I will give Jetico firewall a try.

 

I insist that the multiple tables design improves performance by decreasing the number of rule comparison attempts to approximately half compared to the single-table approach. The actual number depends on the rules you are using. Let me give a simplified example: If you have 2 web browsers, both are allowed outbound to remote ports 80,443,8000,8080, and denied any inbound connections. This means 10 rules in Kerio (I suppose the multi-port rules are expanded in the engine). With Jetico you have two rules for the two applications, both directing to the Web Browser table, which will have 5 rules. The Jetico engine need to store 7 rules. Now let us see the number of rule match attempts. For Kerio the best case is 1, and worst case is 10, average is 5. For Jetico the best case is 2, the worst case is 7, average is 4.5. If you are using a different (third) application in this example, Kerio adds an overhead of 10 rule match attemps, and Jetico adds and overhead of 2 rule mach attempts. The more applications you have the difference increases. The actual improvement in seconds, or cpu allocation depends on many things, and can be hardly estimated.

I have used Kerio for a long time. I found that it is very tedious to configure the ruleset so that every one of my approx. 10 security application is allowed to do auto-updates via HTTP, but denied other commincations. The correct configuration of this would need a crazy number of rules. What I have done is that I set all of these applications to Allow any outbound communcation, just to simplify the ruleset.

On the contrary. In my current Jetico configuration I allow my many antivirus/antispy applications to function as a Web Browser. This needs 1 rule per application. It provides more restricted controll than I was willing to do with Kerio, and took less time to set up. Implementing the same or better restrictions in Kerio would need 5 times more rules in the engine, and 2 times more on the GUI. For some tricky cases you can always choose to do the same as in Kerio - a big list of unrealted rules. But you also have the possiblity to build up a different structure. Remember: more choice is better. If You still prefer to have one single big table for all application rules, it is quite much possible to restructure the ruleset for this. Jetico is not for those who want it to "just work" withouth any configuration.

"Continue" is also useful as a default verdict of a table.

Could you please explain your problem in more details. I don't understand your example. But Application and System-wide rules don't have to do anything with the table-invocation concept, so there should be some misunderstanding here. The table-invocation is not invented by Jetico, this mature concept has a glorious backround in "iptables" of Unix and hardware firewalls.

Incorrect. 'access to network' event comes before the application would declare the remote IP, so this event does not have IP parameters. So 'access to network' rules will NOT be able to check blocked IPs. 'access to network' is rather useful to stop untrusted applications from starting trusted processes to do the communcation for them.

I will try to provide any info I am aware of. But I am not from Jetico and any "improvement suggestions" written to this forum will most probably not be read/heard by them. I encourage you to write to Jetico Support if you have a specific improvement idea, or bug report - they are providing premium class support.

-hojtsy-

 

hojtsy,
I have found this tutorial most useful. I tried Jetico a number of weeks ago and couldn't get my head around it and ditched it. After reading your post it become much clearer so I installed it again on my test PC and made far more progress than I did before and actually feel that I understand it it enough to use properly. I'll try it out for a couple of weeks before I try it on my main PC.

Thanks.