Outpost Rules Processing Order

[Paranoid2000]

This FAQ has been updated to include:

• Separate sections for different Outpost versions;
• The Priority flag for global rules introduced in Outpost 2.5;
• The Ignore Component Control flag's effect on rules priority (thanks to Orvman for pointing this out).
• Changes to Localhost issues for Outpost 2.5 onwards (which also corrects an error in the address range);
• Clarification of "internal" rules.

The information below is based on Outpost documentation with extra explanation by Mikhail at Agnitum and previous posts describing Outpost v1 by former moderator Cosmos - in particular How Outpost processes rules internally and Rules Processing & Policy Modes. Thanks to all who helped!

When deciding whether to permit or block traffic, Outpost applies its rules in a specific order to every packet of data sent or received. If a decision is made to permit or block, deny or reject traffic, then no further processing is done. If a packet is rejected (Outpost 2.0), then an ICMP "Port Unreachable" message is returned to the sender - if denied (Outpost 2.0) or blocked (Outpost 2.1 and later), no such message is sent (this is referred to as being "stealthed").

Since rules processing has changed between versions of Outpost, a summary of the order is listed for each version with a full explanation of the rules afterwards:

Outpost 2.5 onwards
Plugins
Application/Global Rules with "Ignore Component Control" flag
Trusted/NetBIOS Zones
Global NetBIOS Block Rules
Global Rules with High Priority flag
Blocked/Trusted Application Settings
Application Rules
Global Rules
Outpost Policy
Allow NAT Packets
Transit Rule

Outpost 2.1
Plugins
Trusted/NetBIOS Zones
Blocked/Trusted Application Settings
Global NetBIOS Block Rules
Application Rules
Global Rules
Outpost Policy
Allow NAT Packets
Transit Rule

Outpost 2.0
Plugins
Blocked/Trusted Application Settings
Trusted/NetBIOS Zones
Global NetBIOS Block Rules
Application Rules
Global Rules
Outpost Policy
Allow NAT Packets
Transit Rule

Plugins:
These receive network data before any rules processing is applied. Those that affect traffic (like Attack Detection or Dmut's Blockpost) can therefore take priority over any other rules settings.

Trusted/NetBIOS Zones: (Options/System.../LAN/Settings...)
If the source or destination IP address lies within a network/subnet pair marked as Trusted, then traffic will be permitted. If marked as NetBIOS, then only traffic to and from NetBIOS ports on those addresses will be permitted (ports 137-139 and 445 on TCP and 137-138 on UDP).

Blocked/Trusted Application Settings: (Options/Application...)
Traffic to or from an application placed in the Trusted group is allowed, traffic to or from an application placed in the Blocked group is denied.

Global NetBIOS Block Rules:
Traffic to NetBIOS ports (137-139 and 445 on TCP and 137-138 on UDP) is blocked (traffic sent to or from a NetBIOS Zone would have been matched by the Trusted/NetBIOS rules previously and would not reach this section). This is an internal rule which cannot be adjusted.

Application Rules: (Options/Application...)
Where a specific application in the Partially Allowed group (the Blocked/Trusted groups have been dealt with previously) is sending or receiving traffic, its rules are then evaluated to see if they specifically permit or block the traffic.

Application rules can be set for TCP (Transport Control Protocol) or UDP (User Datagram Protocol) traffic. Other protocols can only be handled via Global rules (except for ICMP, Internet Control Message Protocol, which is handled via Options/System.../ICMP/Settings...).

Application rules priority can be increased by setting the Ignore Component Control option but this disables component checks for that application so this should be used sparingly.

Global Rules: (Options/System.../Global System and Rawsocket Rules/Settings...) (Global Application and System Rules in Outpost versions 2.0/2.1)
These are applied for all traffic that has not matched one of the previous sections. Rules for protocols other than TCP and UDP can only be set here (set the protocol type to IP and pick a subtype from the list presented).

Outpost 2.5 onwards allows for Global rules to be marked as High Priority (in the Actions section of the rule creation dialog) - such rules will be processed before Application Rules so this option should be used in cases where certain network traffic is to be blocked completely. The Ignore Component Control option will increase rule priority further but disables component checks so should be used sparingly.

Outpost Policy: (Options/Policy...)
When no rules have been matched and the packets are local (either the destination or source address matches a network interface on the PC) - the current Outpost policy dictates what happens next:

Allow Most will permit the traffic. Block Most will deny it. Rules Wizard will, for application and "other" (non-TCP, UDP, ICMP) protocols only, bring up a dialog box asking whether this should be allowed or blocked - while the box is present, outgoing connections will be halted and incoming connections will be denied (the reply given will then apply to the next incoming connection that matches the rule created).

TCP/UDP traffic that cannot be linked with an application ("system" traffic) will be blocked with the reason "Reject Connection To Port Opened By System".

Allow NAT Packets:
If Outpost detects that ICS (Internet Connection Sharing) is in use, then this rule will be applied. Packets coming from a network listed in LAN Settings to an outside address and the replies coming back are allowed under this rule (and Stateful Inspection is activated to allow further network connections to be established between that LAN/outside address pair). This is an internal rule which cannot be adjusted.

Transit Rule:
This is applied when neither the destination nor source IP addresses match those of any network interface (i.e. the network packet is passing through the system to somewhere else). Such packets are blocked (with the reason "Block Transit Packets" given in the Outpost log). This is an internal rule which cannot be adjusted.

Implications
Having a Trusted Zone means that any application (unless listed as Blocked in 2.0) can gain network access to the Trusted IP addresses - only allow local network addresses in this section! If you need to use it, seriously consider listing individual IP addresses (with a subnet mask of 255.255.255.255) rather than network ranges to limit its scope as much as possible. For most home networks, Trusted status is only needed if running certain applications (e.g. network games) or if ICS is being used and, for some reason, is not being detected and handled properly by Outpost. For File and Printer sharing tick the NetBIOS box only.

Depending on the network setup, access via NetBIOS may be displayed as using application NETBIOS - in this case even a Blocked Application may be able to access a NetBIOS or Trusted LAN.

Having a Deny/Reject/Block rule under Global System and Rawsocket will not affect Application Rules permitting the same type of traffic (unless that rule has the High Priority option set in Outpost 2.5 or later). This has been a particular issue with Application svchost.exe settings which can contain Remote Procedure Call and Universal Plug and Play (uPnP) rules. If you wish to completely exclude a certain port or protocol, create a Global rule with the High Priority flag set (with Outpost 2.1 and earlier, you will instead need to check every Application Rule to ensure that none are permitting it).

The Loopback Address - Security Concerns for Outpost 2.0/2.1
With Outpost 2.1 and earlier, applications sending data to the loopback address (127.0.0.0/8, the range 127.0.0.1 - 127.255.255.255) can pose a security risk. The default "Allow Loopback" global rule allows any application to send data to 127.0.0.1 and should be disabled since it does allow potentially malicious applications to acccess the Internet using the rules allowed for any proxy servers (e.g. Proxomitron, WebWasher, MailWasher, some antivirus utilities).

Even with this loopback rule disabled (which will then require you to define separate application rules for each program using a proxy), applications will still be allowed to receive traffic from the 127.0.0.0/8 address by Outpost. This could (potentially) have been exploited by a malicious application intercepting and altering data intended for a proxy, and this could have been used to affect the original application (e.g. causing a web browser to contact a different web page by sending back an HTTP redirect).

With Outpost 2.5 and later however, local proxy applications require a rule to allow incoming traffic so such attempts should be detected (either triggering a Rules Wizard popup or being blocked depending on Outpost policy).

[Manny Carvalho]

For Outpost 2008 onwards the rules sequence have changed to:

Block intruder's host (Attack Detection)
Trusted Zones
Global NetBIOS Block/Allow Rule
Low-Level System Rules with the "High Priority" flag set
Global Rules applied before application rules
Application Rules (Blocked/Trusted/Partially Allowed)
Low-Level System Rules
Global Rules applied after application rules
Allow NAT Packets
ICMP Rules
Outpost Policy
Block Transit Packets

As described in this Agnitum KB article: http://www.agnitum.com/support/kb/ar...000120&lang=en