Jetico questions

I'm testing Jetico and I like it's flexibility, but I have a few questions:

1) Is the firewall core being loaded immediately at kernel time or slightly after the startup, alà startmenu->startup??

2) Are there any ready-to-use profiles, avoiding "training" time?

3) It looks like Jetico uses a "per user" profile, instead of system wide. Any chance to force system wide settings?

4) Any online web primer on Jetico?

Regards

 

While you wait for Stem and the other Firewallers (hey, a new word) to show up, I took the liberty to copy this earlier thread that gave me a good basic understanding of Jetico.

Posted by "HOJTSY"

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.