I have specified six basic categories of firewall rules (not all of which are currently used in NIS 3.0+). In general terms, the rules in a particular category should be grouped together, but there are circumstances in which a rule of a particular category may be most appropriate physically located else where in the ruleset. I will talk about this below.

The categories, in their preferred sequential order are:

Monitor Rules -- Primarily used for analysis and ruleset tuning; these are the IGNORE/LOG ONLY/MONITOR rules which create an entry in the firewall event log, but take no action on a particular kind of Internet communication.

Global PERMIT/BLOCK Rules -- Primarily used to PERMIT or BLOCK all communications to and/or from a particular range of IP addresses.

System-Wide Rules -- Primarily provide or restrict communications required for basic Internet connectivity, e.g., DNS, ICMP, NetBIOS, Loopback, etc.

Application-Specific Rules -- Primarily provide or restrict communication for specific Internet-enabled applications, e.g., browsers, mail clients, new readers, instant messaging capabilities, and other Internet-enabled applications; there are quite frequently multiple rules associated with a particular application.

Default Trojan Block Rules -- Primarily provide notification of unsolicited incoming attempts to access a port frequently used by default by a Trojan server.

Block Everything Rules -- Primarily provide to explicitly prohibit any communication not expressly permitted by any rules in the preceding categories.

Monitor Rules

These rules are rarely found and are typically used only by advanced users for diagnostic or ruleset tuning purposes.

Normally, monitor rules are intended to capture all activity associated with their individual specifications; consequently, the rules need to be placed at the top (beginning) of the ruleset. However, there are instances in which an Administrator will desire to move a particular monitor rules about in the ruleset in its entirety to determine where a particular communication is being blocked or permitted. It is not clear that this is even possible in the current NIS/NPF 3.0+ Internet Access Control user interface.

All (enabled) monitor rules will be processed for all communications, so there is no performance consideration in how the individual rules are sequenced. However, for management purposes, it is convenient to ensure that rules that are similar to be grouped together, e.g., if multiple rules are present for monitoring LAN connections, then it would be advisable to group them together.

For performance reasons, all rules in this group should be capable of being retained, but persistently enabled/disabled.

By default, all (enabled) rules in this category should be logged in the firewall event log; but the Administrator should be able to change all default logging settings.

Global PERMIT/BLOCK Rules

These rules are rarely found in rulesets. NIS 3.0+ uses Trusted/Restricted Zones to provide a simple form of this functionality. There are three problems with the Trusted/Restricted Zone implementation that bothers advanced users: First, the specific IPs that are blocked or permitted are not explicitly documented in reports available to the user; hence any change in such rules is not immediately obvious when problems emerge. Second, IP addresses listed in the Trusted/Restricted Zone implementation are all or nothing. Third, there is no recording possible with communication attempts associated with either the Trusted Zone or Restricted Zone in the firewall event log. Either all communications involving the specified remote IP addresses are permitted (Trusted Zone) or all are denied (Restricted Zone). It is the Trusted Zone implementation that presents a potential problem here to the advanced user. Whereas a firewall administrator may well be willing to give Trusted Zone computers greater access than normal Internet connections, the cautious administrator is seldom willing to give such machines completely unrestricted access. And, as matters currently stand, reliance on Trusted/Restricted Zones effectively eliminates any possibility for an Administrator to log communication events at all for such sites.

In all situations with which I am familiar, Global PERMIT/BLOCK rules should come immediately after any Monitor rules that may be present in the ruleset. If there are no monitor rules, these rules should be at the top (beginning) of the ruleset. There may be circumstances in which these rules might be more appropriately situated further down in the ruleset, but I am not aware of any such scenario at the moment.

These Global PERMIT/BLOCK rules are typically applicable to all remote IP addresses specified in a list or range. An explicit firewall rule to correspond to a Trusted/Restricted Zone specification would indicate Any Protocol, Any Direction, Any Remote/Local Service. However, customized rules in this subset may be more refined.

It is possible to optimize the sequencing of the Global/Block rules somewhat to improve overall firewall performance. Those rules most commonly invoked should ideally be first in this sub-block.

For performance reasons, all rules in this group should be capable of being retained, but persistently enabled/disabled.

By default, all (enabled) DENY/BLOCK rules in this category should be logged in the firewall event log; but the Administrator should be able to change all default logging settings for all rules.

System-Wide Rules

Rules in this category should be found in all firewall rulesets that allow any sort of Internet connectivity; the rules should be explicit and loggable (should the user choose). Furthermore, the applicable rules should be customizable to satisfy the requirements of a particular hardware/LAN/connection configuration. Rules applicable to a particular functionality, e.g., DNS, are typically grouped together and the internal sequencing of such rules in the sub-group can create radically different functional capabilities.

System-wide rules are typically applicable to Any Application on the system. They may well be restricted to particular Local/Remote Services and even specific Local/Remote IP Addresses. To ensure that any allowed activities are consistent with Global PERMIT/RESTRICT rules, these rules should typically follow those rules.

Somewhat more significant performance enhancements may be obtained by setting the sub-groups of system-wide rules that are more frequently invoked nearer to the beginning of the System-Wide rules group. On my own system, well over half of rule invocations during a typical session are actually system-wide rules.

By default, all (enabled) DENY/BLOCK rules in this category should be logged in the firewall event log; but the Administrator should be able to change all default logging settings for all rules.

Application-Specific Rules

Rules in this category typically constitute the bulk of rules found in a rule-based firewall. Rules applicable to a particular application, e.g., a specific Web browser, are typically grouped together and the internal sequencing of such rules in the sub-group can create radically different functional capabilities. It is common to provide distinct rules for distinct functionality associated with a particular application. For example, many of today's browsers may provide HTTP, FTP, and gopher functionality (and sometimes considerably more). Separating rules for each functionality, allows the administrator to quickly set the permissibile Internet functionality for the specific application in question (or to enable/disable certain functionality for certain situations).

An administrator should also be able to specify rules for applications not physically present on the machine at the time the rule is created. Usually, these will be rules to DENY access to applications that should not be installed on the machine; however in this situation, the administrator would have no knowledge of the full path to which the application might subsequently be installed, hence a wild-card specification for the path to the executable should be allowable. Unless the Implicit Block Rule handles this situation (and the Rules Assistant is disabled), this functionality is not currently present.

For that matter, there may well be applications installed on the machine which the Administrator prefer to explicitly deny any or all Internet access. Windows Explorer and Microsoft Word are two common examples. There are advantages to keeping the detailed rules for these applications in the Ruleset but also in changing action from the default PERMIT to DENY.

Generally speaking, Application-specific rules should immediately follow the System-wide rules. Unfortunately, in more recent Microsoft operating systems, there are some rules that are really applicable system-wide, but are technically application-specific. These rules should therefore be ordered at the beginning of the Application-specific rules, i.e., at the end of the other system-wide rules.

Additional firewall performance enhancement may be obtained by ordering the application-specific subgroups so that those most frequently invoked are near the beginning of the Application-specific rules group.

For performance reasons, all rules in this group should be capable of being retained, but persistently enabled/disabled. Indeed, may users with extensive earlier reliance on AtGuard expect this functionality for their needs.

By default, all (enabled) DENY/BLOCK rules in this category should be logged in the firewall event log; but the Administrator should be able to change all default logging settings for all rules.

Default Trojan Block Rules

Rules in this category typically form the second largest group of rules in NIS/NPF implementations; they are much rarer in AtGuard rulesets. For the most part, these rules only serve as notification devices for novice users of a potential scan of their system for the presence of a Trojan server (assuming the Trojan server is using its default 'listening' ports). However, if a Trojan server has been surreptitiously installed on a machine, but the user has not been tricked into granting Internet access (inbound and/or outbound) to the Trojan, these rules can be important in maintaining Stealth on a system, if the user is interested in doing this. These rules do not detect the presence (or lack thereof) of a Trojan installed on the system. This is important and needs to be emphasized.

There is another set of Default Trojan rules not currently implemented; these would be explicit rules to block any Trojan server or client from initiating calls out to default ports on other machines.

The Default Trojan Block Rules must follow the Application-specific rules and would specify BLOCKing Any Application.

I suspect that at this point, it is possible to provide a far more efficient implementation of these rules than that currently used and hope to see such an approach implemented in some of the next implementations of NIS/NPF. The current structure might well have sufficed when only a dozen or so such rules were present, but today there are approximately sixty and the number will only increase.

Typical users will seldom see these rules being invoked. There is no particular performance consideration (for most users) therefore in exactly how these rules are ordered within the Trojan Blocl Rules group. For management purposes, however, it might be best to arrange these rules alphabetically by name of the Trojan suspected.

By default, all (enabled) rules in this category should be logged in the firewall event log; but the Administrator should be able to change all default logging settings for all rules.

Block Everything Rules

These rules are rare and usually only invoked by advanced users. There could be as many as six of these rules, two for ICMP, two for TCP, and two for UDP in the current AG/NIS/NPF protocols addressed. It is not clear that these rules can be invoked at all in the current NIS/NPF 3.0+ Internet Access Control user interface.

These rules must lie at the very end of the ruleset if they are used.

All rules in this group should be capable of being retained, but persistently enabled/disabled.

By default, all (enabled) rules in this category should be logged in the firewall event log; but the Administrator should be able to change all default logging settings for all rules.

jvmorris