A Guide to Producing a Secure Configuration for Outpost

[Paranoid2000]

What follows is a guide I have produced with feedback and help from the other forum moderators on configuring Outpost with the emphasis on security. It provides comprehensive details on every part of Outpost's configuration and covers several topics that have been discussed elsewhere in this forum.

As there is a 10,000 character limit on posts, I have had to spread this guide across several posts. For those who would prefer one document that can be read offline, a zipped copy in Rich Text Format is also enclosed.

Anyone with queries or suggestions about this guide is invited to post them in the General Discussions forums.

Recent Updates
The guide has been updated to version 1.01:

• Section added for Outpost Free.
• Terminology changed - "DNS Heavy" now described as "Application DNS", "DNS Lite" as "Global DNS".
• Recommendation for ICMP Destination Unreachable packets altered.
• Global DNS section includes reference to application rules for services.exe/svchost.exe.
• Application DNS section now mentions DNShell leaktest.
• Added HTTP block rule to Email Client (to stop images being downloaded for spam emails).
• Sections G7-9 added for Blockpost, HTTPLog and SuperStealth plugins.
• Document History section added.

Copying This Guide
You may take and distribute copies of this guide, in full or in part, subject to the following conditions:

• You must include mention of the guide's original location (either a link to this thread or a mention of the www.outpostfirewall.com forum will suffice);
• You may make additions to the guide (while not modifying existing content) but they must be clearly labelled as such and include your contact information to allow anyone with queries to raise them with you.

[Paranoid2000]

A Guide to Producing a Secure Configuration Using Outpost Firewall

Introduction

The following suggestions are intended to help provide a more secure configuration for those running Outpost with the emphasis on restricting outgoing traffic. With the increasing amount of software attempting to "phone home" without user consent, and the increase in the number of trojans and viruses seeking to disguise their activity as legitimate Internet traffic, having a restrictive policy on what is allowed out is now every bit as important as limiting what is allowed in.

Since a number of changes to default rules are included, if you encounter any problems and post in the forum, please mention which rules you have used from this list (e.g. section D1-(b) Application DNS). This document assumes familiarity with Outpost - new users should consider reading the Web-Hiker's Guide to Outpost Firewall before considering the steps in this guide.

There is always a tradeoff between security and usability - some of the changes below may require significant extra work and can make certain actions (like changing ISP's) far more difficult. Certain network configurations (particularly in business/corporate settings) may cause problems with some sections. Please check the benefits and costs listed for each section before implementing it - if in doubt, try one change at a time and test thoroughly, reviewing the relevant Outpost logs (especially the Blocked log). The intention of these recommendations is to favour security over convenience.

Finally, please note that this document is not produced or supported by Agnitum. Any issues arising from the recommendations below should be raised in the Outpost Firewall forum, not with Agnitum themselves.

Credits

This guide was initially produced by Paranoid2000 and has been expanded upon following feedback from the other forum moderators and Agnitum. In particular special thanks are due to David for his work in developing and testing the ruleset for svchost.exe in section E2, a critical issue for Windows XP users.

Note for Outpost Free Users

The settings in this guide have not been tested with Outpost Free and some parts, notably section D dealing with global rules, cannot be implemented fully (since global rules can be disabled but not altered in Outpost Free) while others (Component Control) are features new to Outpost v2. Nevertheless many of the points made here should still apply and make a worthwhile improvement to system security.

A - LAN Settings (under Options/System/LAN/Settings)

Benefits: Improves security by limiting privileged access to your PC.
Costs: More work to setup and maintain, especially for a large LAN.

This section specifies which IP address ranges should be considered as "trustworthy". From the security standpoint, the smaller the range of entries listed here the better, since traffic to and from these addresses may be permitted, overruling any application or global rules (please see the Outpost Rules Processing Order FAQ thread for more details on this).

For a standalone PC, no entries are needed at all. In this case, clear the "Auto-detect new network settings" box to prevent a default entry from being added by Outpost.

Entries here should only be considered for the following cases:

• PCs on a Local Area Network (LAN) which contain files or printers you wish to access in Windows;
• PCs on a LAN which need to be accessed using networked applications which cannot be accommodated using Application rules;
• Internet Connection Sharing (ICS) gateway PCs should include the IP address of each ICS client as a Trusted address. Please see the FAQ thread LAN and DNS settings for V2 for more details.

In any case, the default network settings supplied by Outpost will be overly broad since it assumes that anything in the same network should be included.

Instructions:

• Disable the "Auto-detect new network settings" to ensure that Outpost adds no new entries to the settings. Note that if new network cards are installed, new addresses will need to be added manually with this option disabled;
• Add the address for each PC individually (which should then appear with a 255.255.255.255 network mask). Internet addresses should never be listed here;
• For File/Printer sharing, check the NetBIOS box for the PCs involved;
• For network applications, check the Trusted box for the PCs involved.

If you have a large LAN, making the listing of individual PCs impractical, then an alternative approach would be to list the network range and use the Blockpost plugin to block unnecessary addresses within that range (Blockpost, unlike Outpost itself, does allow you to define arbitrary IP address ranges).

Please note that LAN activity can be misinterpreted as an attack by the Attack Detection plugin. If you encounter this problem (notably with Browse Masters and Domain Controllers on a Windows network), please refer to section F4 for details on configuring the plugin to prevent this.

B - ICMP Settings (under Options/System/ICMP/Settings)

ICMP (Internet Control Message Protocol) is a part of the Internet Protocol used to send diagnostic and error messages. For full information on this, please consult RFC 792 - Internet Control Message Protocol.

The default settings allow for the following:

• Basic connectivity testing using the Ping command (Echo Request Out and Echo Reply In) - incoming Pings will be blocked to hide your computer's online presence;
• Messages indicating that an Internet address is unavailable (Destination Unreachable In and Out);
• Messages indicating that an Internet address is out of reach (Time Exceeded for a Datagram In). This is used and required for the Tracert command - incoming traceroute attempts will be blocked to hide your computer's online presence.

These settings should be secure enough for the majority of users. However, allowing outgoing Destination Unreachable packets may cause your system to reveal itself to certain types of scans (the vast majority will be blocked by Outpost) so blocking these may reduce your system's visibility further on the Internet.

Benefits: Hides your system from those few scan attempts that may pass through Outpost.
Costs: Destination Unreachables will be sent legitimately in some cases (for instance with slow DNS responses) which will show as blocked. May cause delays and timeouts for some network applications (like peer-to-peer) where others are connecting to your system.

Instructions:

• Clear the "Destination Unreachable (3)" Out box.

If you are running a server then you may wish to have it visible to Ping and Tracert commands. Some Internet Service Providers (ISPs) may require you to respond to their Pings in order to stay online. Only follow the instructions below in these cases.

Benefits: Allows users to check connectivity and network performance to your server. May be required by some ISPs.
Costs: Exposes your system to a possible Denial-of-Service attack.

Instructions:

• Check the "Echo Reply (0)" Out and "Echo Request (8)" In boxes to allow responses to Pings.
• Check the "Destination Unreachable (3)" Out and "Time Exceeded for a Datagram (11)" Out boxes to allow responses to Tracert.

Alternative Instructions: The previous instructions allow pings and traceroutes from everyone. It is possible instead to use a global rule to allow ICMP from trusted addresses only - but this will allow all ICMP messages, overriding Outpost's ICMP settings for packets to and from those addresses. However if specific addresses are known, this may be preferable. To do this:

• Create a global rule with the following parameters:
  
  Allow Trusted ICMP: Protocol IP type ICMP, Remote Host <add trusted addresses here>, Allow
  
  Note that direction should not be included with this rule (both incoming and outgoing traffic needs to be permitted here).

C - Firewall Mode (under Options/System)

This should be left at "Stealth". No changes are recommended.

[Paranoid2000]

D - Global/Systems Rule Changes (under Options/System/Global Application and System Rules)

D1 - Specifying DNS Server Addresses

DNS (Domain Name System) is the method by which an IP address is found for a domain name (e.g. outpostfirewall.com has the IP address 216.12.219.12 - a full description is available in RFC 1034 - Domain names - concepts and facilities). Since DNS traffic has to be allowed through firewalls in order to be able to perform the IP-address lookup needed when connecting to a site, some trojans and leaktests attempt to disguise their traffic as a DNS request. However by limiting access only to those DNS servers offered by your Internet Service Provider (ISP), this tactic can be effectively blocked. There are two options to follow here:

(a). The "Global DNS" Option - Add the ISP DNS server addresses to the Global rule

Benefits: Provides the benefits given above with the minimum of extra work needed.
Costs: If you use multiple ISPs, the addresses for all their servers needs to be included - if you change ISP, or the ISP changes their server addresses, then this rule must be updated with the new DNS addresses. If you have an application or network environment that uses iterative DNS queries (Windows normally does recursive queries, iterative ones are typically made between DNS servers as explained here) then this rule will cause problems and should not be used.

Instructions:

• Find the IP addresses of the DNS servers used by your ISP. The quickest way is to either type ipconfig -all from a DOS Box/Command Prompt (the DNS Server addresses should be listed near the end) or (for Windows 9x/ME/XP users) use Start Menu/Run... and type winipcfg for a GUI utility that provides the same information.
• Add these addresses to the "Allow DNS Resolving" global rule as Remote Hosts.

Windows 2000/XP users should also add these addresses to the application rules for services.exe/svchost.exe respectively (full details are given in section E2).

(b). The "Application DNS" Option - Remove the Global rule, add a DNS rule to every application

Benefits: New applications will now normally need 2 rules (the DNS rule plus their normal rule) reducing the chances of accidentally granting access to suspicious programs. Malicious programs trying to "phone home" face the extra obstacle of trying to lookup the necessary IP address. Malicious programs may be fooled into thinking that no network connection is available and "go dormant" until one is detected. Trojan software that only uses the DNS protocol will now require a specific Outpost rule rather than being able to use global rules. This is the only option that can block the DNShell leaktest and similar exploits.
Costs: Much more work is needed - every application will need one extra rule. Changing ISP's will require that all these rules are updated to cover the new DNS addresses.

Instructions:

• If running Windows 2000 or XP, disable the DNS Client Service (via Start Menu/Settings/Control Panel/Administrative Options/Services). This will force applications to make their own requests for DNS access rather than delegating it to services.exe (Win2000) or svchost.exe (WinXP).
• Disable or delete the global "Allow DNS Resolving" rule.
• For each application, add a rule with the following parameters:
  
  <Application> DNS Resolution: Protocol UDP, Remote Port 53, Remote Address <your ISP DNS server addresses>, Allow

Rules creation can be simplified by creating this rule as a preset instead. To do this, disconnect from the network, shutdown Outpost, open the preset.lst file (in the Outpost program folder) and make the following addition at the end:

; Application DNS Resolution

[Application DNS Resolution]
VisibleState: 1
RuleName: Application DNS Resolution
Protocol: UDP
RemotePort: 53
RemoteHost: <enter the IP addresses of your ISP's DNS servers separated by a commna>
AllowIt

With this in place, simply select the Application DNS Resolution preset whenever prompted by the Rules Wizard (assuming you wish to allow the prompted traffic). Note that in this case, the IP addresses will be shown with a (255.255.255.255) subnet mask in Options/Application. This indicates an IP address range of one entry and is functionally identical to a single address. Note that that Outpost's Tools/Automatically Check for Updates option should be disabled since changes to preset.lst may be reset by an update (Agnitum Update will prompt before overwriting newer files however). Backup this file to another folder, run the update manually and, if necessary, restore the modified file.

Wrapping Up - Considerations for Both DNS Options

Whichever option is chosen above, another case needs to be considered - DNS queries using TCP (Transport Control Protocol) rather than UDP (User Datagram Protocol). Queries using TCP are rare and normally happen for complex queries - in practice they can be blocked since this appears to result in the queries being resent using UDP. Therefore a Global rule specifying this should be added (where Reject/Block is specified as an Action, this means Reject for Outpost 2.0 and Block for Outpost 2.1 or later - similarly for Deny/Block):

Block DNS (TCP): Protocol TCP, Outgoing, Remote Port 53, Reject/Block

If allowing these is the preferred solution, then either change this rule to Allow (Global DNS) or create a second DNS rule for every application specifying TCP instead of UDP (Application DNS).

Reporting Possible Trojan DNS Activity

Any DNS request to other IP addresses should be regarded as suspicious and not permitted without investigation (a check with an ipconfig /all in a DOS Box/Command Prompt window can be used to check if the ISP DNS server addresses have changed, needing a DNS rule update).

To enforce this and highlight any need for an update, if using Global DNS add the following global rules after the other DNS rules - the second one is only needed if TCP DNS is Allowed:

Possible Trojan DNS (UDP): Protocol UDP, Remote Port 53, Deny/Block & Report
Possible Trojan DNS (TCP): Protocol TCP, Outgoing, Remote Port 53, Deny/Block & Report

This will highlight and block any attempted access. This option is not recommended for Application DNS users since legitimate DNS server addresses need to be excluded from these rules to avoid false alarms (i.e. when an application with no rules created requests access) - this should be possible by specifying IP address ranges but is not currently due to Outpost's inadequate handling of IP ranges.

[Paranoid2000]

D2 - Specifying DHCP Server Addresses

DHCP (Dynamic Host Configuration Protocol) is the method used by most ISP's to assign temporary IP address to users when they login. Since DHCP traffic has to be permitted to allow connection to an ISP, this is a potential method for trojans to exploit when trying to send data undetected. Also, sending a flood of DHCP requests to a specific address could be used as a Denial of Service (DoS) attack. For more information on DHCP, please review RFC 2131 - Dynamic Host Configuration Protocol.

If your system has a fixed IP address (either due to being on a private LAN or using a router which is given a dynamic address) then this section can be skipped. To check whether DHCP is in use or not, open a DOS Box/Command Prompt window and type ipconfig /all - if DHCP is in use, the lease details will be given at the end.

Limiting DHCP to a specific server is slightly more complicated than with DNS because Outpost does not seem to always accurately identify the direction of DHCP traffic (in part due to it using UDP and in part due to the change in IP address that it can involve). Therefore the recommended rule uses local and remote port restrictions rather than direction. Also, the first DHCP request sent is a broadcast to the 255.255.255.255 address (which should reach all hosts on the local network only) since at startup there is no way of knowing what the DHCP server address is. Further DHCP requests (to renew the IP address lease) will be addressed to the server.

Windows 2000 and XP users can restrict DHCP further by only allowing broadcasts with the global rule and using an application rule for other requests (services.exe for Windows 2000, svchost.exe for Windows XP). Please consult section E2 for more details on these application rules.

Benefits: Prevents abuse of DHCP permissions.
Costs: If using multiple ISPs, each will have a separate address which needs to be included. If changing ISPs, this rule will need updating. Some ISPs may need multiple entries - especially if they have large networks with several entry points.

Instructions:

• Find the IP address of the DHCP server by using ipconfig -all or winipcfg as described in the DNS settings above. Note that this will not usually be the same as the DNS server address.
• Create the following global rule for Windows 9x/ME:
  
  Allow DHCP Request: Protocol UDP, Remote Address <ISP Server address>, 255.255.255.255, Remote Port BOOTPS, Local Port BOOTPC, Allow
• For Windows 2000/XP use:
  
  Allow DHCP Broadcast: Protocol UDP, Remote Address 255.255.255.255, Remote Port BOOTPS, Local Port BOOTPC, Allow

Since DHCP server addresses can change, it is advisable to try disabling the "Remote Address" entry of these rules if any problems in renewing an IP address lease are encountered - if a lease renewal can then be made, verify and update (if necessary) the DHCP server address before re-enabling this rule. DHCP servers are less likely to move networks however, so using a wildcard address (e.g. 192.168.2.*) should be an effective method of reducing this problem.

D3 - Disable "Allow Loopback" Rule

The "Allow Loopback" global rule included in the default configuration presents a significant security risk to those using proxy servers (software like AnalogX Proxy, Proxomitron, WebWasher and some anti-spam/anti-virus software) since it allows any application not specifically blocked to access the Internet using the rules set up for the proxy. Disabling or deleting this rule removes this possibility.

Benefits: Prevents proxy server rules from being exploited by untrusted software.
Costs: Every application using a proxy server (e.g. web browser with Proxomitron, etc) will need an extra rule to allow access to the proxy (the one suggested by the Rules Wizard should be sufficient in most cases).

Instructions:

• Go to Options/System/Global Application and System Rules/Settings to see listing of global rules;
• Clear the checkbox beside the "Allow Loopback" rule to disable it.

D4 - Disable Unnecessary Global Rules

Some of the global rules may not be relevant and can therefore be disabled (by clearing the adjacent checkbox). These include:

• Allow Inbound Authentication - this is a simple and unreliable, hence rarely used, method of checking the owner of a network connection. If it is required, then removing this may cause a delay in logging into some email servers;
• Allow GRE Protocol, Allow PPTP control connection - these are both needed for Virtual Private Networks (VPNs) using the Point-to-Point Tunneling Protocol. Otherwise they can be disabled.

Benefits: Prevents any possible future exploits using these protocols.
Costs: Blocking Inbound Authentication may result in delays in retrieving email (re-enable the rule in this case, adding the email server as a Remote Host).

Instructions:

• Go to Options/System/Global Application and System Rules/Settings to see listing of global rules;
• Clear the checkboxes beside the relevant rules to disable them.

D5 - Block Unused and Unknown Protocols

Global rules can be defined for the Internet Protocol (IP) as well as TCP and UDP protocols. With IP, a long list of types is available and it is suggested that they all be blocked with the following exceptions:

• ICMP (1) - this is dealt with via the ICMP settings;
• IGMP (2) - this is used for multicasts (e.g. live video streams), if these are desired then do not block this;
• ESP (50) and AH (51) - these are needed for IPSec so VPN (Virtual Private Network) users should not block these.

Corporate users should carefully consider this list - a few of the options may be needed for routing traffic in a network.

A global rule can also be defined to cover unknown protocols (which would include ones like IPX or NetBEUI) - it is suggested that that one be created to block these.

Benefits: Prevents any possible future exploits using these protocols.
Costs: Due to the way Outpost handles rules, these changes may significantly increase the amount of processing involved, especially for users running file-sharing software or on a busy LAN.

Instructions:

Unused Protocols

• Go to Options/System/Global Application and System Rules/Settings;
• Click "Add" to create a new Global rule;
• Set the protocol to IP, a "Type" entry should then appear in the Rules Description with an Undefined setting;
• Click on the "Undefined" to bring up a window listing IP types;
• Check the State box beside each one to block and click OK;
• Set the Action to Deny (Outpost 2.0) or Block (Outpost 2.1 or later), enter an appropriate Rule Name and click OK.

Unknown Protocols

• Go to Options/System/Global Application and System Rules/Settings;
• Click "Add" to create a new Global rule;
• Set the protocol to Unknown, the Action to Deny (Outpost 2.0) or Block (Outpost 2.1 or later), enter an appropriate Rule Name and click OK.

[Paranoid2000]

E - Application Rules (under Options/Application)

E1 - Remove Entries in the "Trusted Applications" Group.

Even when applications have legitimate need for Internet access, providing this without restriction is generally unwise. Some applications may request more connections than are needed (wasting bandwidth), others may have "phone home" functionality which could have privacy implications. To this end, move any entries from "Trusted Applications" into the "Partially Allowed" group, then set rules as suggested below.

E2 - Tighten Up Partially Allowed Applications

Outpost's Auto-configuration option will create default rules for all programs that it is aware of. However these defaults are set with the intention of ease-of-use and therefore can be tightened for most people. However deciding what access to allow is undoubtedly the most challenging part of firewall configuration - and will vary depending on individual setup and preferences. The following rulesets therefore use colour-coding to distinguish between recommendations and suggestions.

Recommendations are shown in red
Suggestions are shown in blue
Optional rules are shown in green

Where Deny/Block is specified as an Action, this means Deny for Outpost 2.0 and Block for Outpost 2.1 or later.

If the Application DNS option detailed in section D1 (b) is being used, then each application will need a DNS rule in addition to the ones given below. Please note that these application rules will take precedence over global rules, as detailed in the Outpost Rules Processing Order FAQ thread.

Notes on Using Domain Addresses in Rules
When a domain name is supplied as a Local or Remote Address, Outpost will immediately look up the corresponding IP address (and requires DNS access for this). If that domain subsequently changes address, the rule will not be updated automatically - the domain name must be re-entered. Consider this possibility if an application or global rule including domain names no longer seems to function.

Some domains may have multiple IP addresses - Outpost will find all such addresses when a rule is created via Options/Application but not when it is created using the Rules Wizard prompt. Therefore, with Rules Wizard created rules, re-enter the domain name using Options/Application to ensure all addresses are picked up.

Svchost.exe (Windows XP systems only)
Svchost.exe is an awkward case - it requires some Internet access in order to carry out basic networking tasks, but giving it full access will leave systems vulnerable to RPC exploits like the Blaster and Welchia/Nachi worms. Creating an appropriate ruleset for this application is therefore of critical importance.

Allow DNS (UDP): Protocol UDP, Remote Port 53, Remote Address <your ISP's DNS servers>, Allow
Allow DNS (TCP): Protocol TCP, Outgoing, Remote Port 53, Remote Address <your ISP's DNS servers>, Allow
Possible Trojan DNS (UDP): Protocol UDP, Remote Port 53, Deny/Block & Report
Possible Trojan DNS (TCP): Protocol TCP, Outgoing, Remote Port 53, Deny/Block & Report

• DNS rules - see section D1 for more details. They are only needed here if the DNS Client Service is not disabled, since in this case, svchost.exe will then do the lookups;
• As only one TCP rule is needed here, it is set to Allow;
• Since there are trojan applications that attempt to disguise their traffic as DNS, it is recommended that any attempted access to servers other than your ISP's be treated as suspicious - the Trojan DNS rules will therefore report on such access. If the access is legitimate (if your ISP has changed DNS server addresses and the Allow rules need updating for instance) then having this reported is preferable to losing network connectivity and having to check the Blocked logs to find out why.

Block Incoming SSDP: Protocol UDP, Local Port 1900, Deny/Block
Block Outgoing SSDP: Protocol UDP, Remote Port 1900, Deny/Block

• This blocks Simple Service Discovery Protocol (SSDP) which is used to find Universal Plug and Play (UPnP) devices on the local network. Since UPnP has had multiple security problems, it is best disabled unless absolutely needed - if it is, then set this rule to Allow. If the "Block Other UDP" rule at the end is included, this should prevent SSDP so these rules are suggestions.

Block Incoming UPnP: Protocol TCP, Incoming, Local Port 5000, Deny/Block
Block Outgoing UPnP: Protocol TCP, Outgoing, Remote Port 5000, Deny/Block

• These block UPnP packets - as per the SSDP rules above, if you absolutely need UPnP then set them to Allow but add the IP addresses of the UPnP devices as Remote Addresses to limit their scope. If the "Block Other TCP" rule at the end is included, this should prevent UPnP so these rules are suggestions.

Block RPC (TCP): Protocol TCP, Incoming, Local Port 135, Deny/Block
Block RPC (UDP): Protocol UDP, Local Port 135, Deny/Block

• these are a duplicate of the default global rules for blocking RPC/DCOM traffic - they should therefore not be strictly necessary here but should be considered as an extra safeguard. If RPC/DCOM access is needed, then set these rules to Allow but only to trusted Remote Addresses.

Allow DHCP Request: Protocol UDP, Remote Address <ISP DHCP Server address>, Remote Port BOOTPS, Local Port BOOTPC, Allow

• DHCP rule - see section D2 for more details (note that this is unnecessary if static IP addresses are used - normally only the case on private LANs). It is needed here since svchost.exe is responsible for DHCP lookups - the global DHCP rules will not come into play due to the "Block Other TCP/UDP" rules at the end.

Allow Help Web Access: Protocol TCP, Outgoing, Remote Port 80, 443, Allow

• Windows Help may need Web access using svchost for some functions - if you do not intend to use Help (or do not wish Microsoft to know when you do...) then exclude this rule.

Allow Time Synchronisation: Protocol UDP, Remote Port 123, Remote Address time.windows.com, time.nist.gov, Allow

• Used for time synchronisation - include this rule only if you wish to use this feature of Windows XP.

Block Other TCP Traffic: Protocol TCP, Outoing, Deny/Block
Block Other TCP Traffic: Protocol TCP, Incoming, Deny/Block
Block Other UDP Traffic: Protocol UDP, Deny/Block

• List these rules last - they will prevent multiple Rules Wizard popups for undefined services. Any further rules added need to come before these.

Business users should consult Microsoft KnowledgeBase Article 832017 - Port Requirements for the Microsoft Windows Server System for details of extra ports that may need to be allowed for system services.

Services.exe (Windows 2000 systems only)

Allow DNS (UDP): Protocol UDP, Remote Port 53, Remote Address <your ISP's DNS servers>, Allow
Allow DNS (TCP): Protocol TCP, Outgoing, Remote Port 53, Remote Address <your ISP's DNS servers>, Allow
Possible Trojan DNS (UDP): Protocol UDP, Remote Port 53, Deny/Block & Report
Possible Trojan DNS (TCP): Protocol TCP, Outgoing, Remote Port 53, Deny/Block & Report

• DNS rules - see section D1 for more details. They are only needed here if the DNS Client Service is not disabled, since in this case, services.exe will then do the lookups;
• Since only one TCP rule is needed here, it is set to Allow;
• As with the svchost rules above, the "Possible Trojan" rules report on DNS access to other addresses.

Allow DHCP Request: Protocol UDP, Remote Address <ISP DHCP Server address>, Remote Port BOOTPS, Local Port BOOTPC, Allow

• DHCP rule - see section D2 for more details (note that this is unnecessary if static IP addresses are used - normally only the case on private LANs). It is needed here for the same reason as given above in svchost.exe.

Block Other TCP Traffic: Protocol TCP, Outoing, Deny/Block
Block Other TCP Traffic: Protocol TCP, Incoming, Deny/Block
Block Other UDP Traffic: Protocol UDP, Deny/Block

• list these rules last - they will prevent multiple Rules Wizard popups for undefined services. Any further rules added need to come before these.

As with svchost.exe above, business users should consult Microsoft KnowledgeBase Article 832017 - Port Requirements for the Microsoft Windows Server System for details of extra ports that may need to be allowed for system services.

Outpost and Agnitum Update
Aside from DNS, Outpost 2.0 has no further need for Internet access. Outpost 2.1 and later have the ability to download news and plugin information from Agnitum. To allow this, use the following:

Allow Outpost News and Plugin Info: Protocol TCP, Outgoing, Remote Port 80, Remote Address www.agnitum.com, Allow

A similar rule can be used for Agnitum Update:

Allow Agnitum Update: Protocol TCP, Outgoing, Remote Port 80, Remote Address www.agnitum.com, Allow

[Paranoid2000]

Web Browsers (Internet Explorer, Netscape/Mozilla, Opera, etc)
Outpost's autoconfiguration utility and the preset rulesets provide a wide range of permissions for browsers - for most people these can be trimmed down to the following:

Allow Web Access: Protocol TCP, Outgoing, Remote Port 80, Allow
Allow Secure Web Access: Protocol TCP, Outgoing, Remote Port 443, Allow

• These rules allow for standard (HTTP) and secure (HTTPS) web access. If however a proxy is being used and you wish to ensure that all traffic does go through it (especially important for an anonymising proxy) then consider setting these rules to Deny/Block. Note that such a proxy will require a separate rule (the exact details depend on the proxy so are not listed here).

Allow Alternate Web Access: Protocol TCP, Outgoing, Remote Port 8000, 8010, 8080, Allow

• Some websites may trigger connections to other remote ports (e.g. 8080 - this should be visible in the URL which should be in the form http://domain.com:port-number) - it is suggested that rules be added only for those sites that cannot function without these connections.

Allow File Transfers: Protocol TCP, Outgoing, Remote Port 21, Allow

• This rule allows for file transfers. As with Web access, consider setting this to Deny/Block if you wish all transfers to take place through a proxy. File transfers normally require further connections - these will be permitted automatically by Outpost (see the Stateful Inspection FAQ for more details on this).

If the browser has email, newsgroup and/or Instant Messaging capabilites, then add the appropriate rulesets given below.

Email Clients (Outlook, Eudora, Thunderbird, etc)
Two protocols (and hence two rulesets) can be used for retrieving email while one is used for sending. If you are using antivirus software that uses a proxy server to read and scan emails, then it may require the rulesets specified below - in this case the email client should only need a single rule (Email Antivirus Access: Protocol TCP, Outgoing, Remote Address 127.0.0.1, Allow) to access the antivirus proxy.

One simple method to create the appropriate rulesets in this case is to download and send email with Outpost in Rules Wizard policy and then use the "Create Preset using Custom" rule option in the popup dialogs for the email client and antivirus proxy. Once this is done, open the ruleset in Options/Application and re-enter any email server names - this will pick up any servers with multiple IP addresses (the Rules Wizard popup will only include one IP address).

Read Email via POP3: Protocol TCP, Outgoing, Remote Port 110, 995, Remote Address <your ISP POP3 email servers>, Allow

• This rule is for reading email using the Post Office Protocol (POP3) which is the most commonly used. Either open (port 110) or secure (port 995) access is covered. The email servers used should be available in the email program configuration - some ISPs will use a single server for sending and receiving email while others may use separate servers for each protocol.

Read Email via IMAP: Protocol TCP, Outgoing, Remote Port 143, 993, Remote Address <your ISP IMAP email servers>, Allow

• This is for reading email using the Internet Message Access Protocol (IMAP) and may be added in place of or alongside the POP3 rule above. Whether it is needed will depend on your email application. This covers open (port 143) and secure (port 993) access.

Send Email via SMTP: Protocol TCP, Outgoing, Remote Port 25, 465, Remote Address <your ISP SMTP mail servers>, Allow

• This rule is for sending email using the Simple Mail Transfer Protocol (SMTP) and covers open (port 25) and secure (port 465) access. Due to the number of viruses that try to spread via email and attempts by spammers to hijack vulnerable computers to send junk emails, it is strongly recommended that this be restricted to your ISP email servers only. The addresses should be available from the ISP. This rule is needed regardless of the choice of POP3 or IMAP for email access.

Block Web Links: Protocol TCP, Outgoing, Remote Port 80, Deny/Block

• This will prevent the email client from downloading any links included with HTML-formatted email. Many spam emails use these as a means of identifying if the mails are read (and therefore confirm your email address as "live"). This will affect legitimate emails also but this usually removes images only, not text (and images enclosed as attachments will not be affected);
• If you need to see images for certain emails, create a rule allowing access to the domains they use before this rule;
• Do not use this rule if you use your browser to read email since it will block normal web access.

Download Managers (GetRight, NetAnts, Go!illa, Download Accelerator, etc)

Special Note: Many download managers or accelerators include advertising which may track your usage. Should this be the case with yours, either switch to one which does not - GetRight being a good example - or add a rule to block access to the home/ad site used and ensure this rule is listed first. To find the site used, check the software's activity using Outpost's Network Activity window.

Allow File Transfer: Protocol TCP, Outgoing, Remote Port 21, Allow

• This rule allows for standard file transfers. As with web browser rules, consider setting this to Deny/Block only if you wish all transfers to take place through a proxy.

Allow Web Access: Protocol TCP, Outgoing, Remote Port 80, Allow

• Many downloads now use the HTTP protocol.

Newsgroup Readers (Forte Agent, Gravity, etc)
These use the Network News Transfer Protocol (NNTP). For full details of this, please refer to RFC 997 - Network News Transfer Protocol.

Allow Usenet Access: Protocol TCP, Outgoing, Remote Port 119, Allow

• This is needed for normal newsgroup access.

Protocol TCP, Outgoing, Remote Port 563, Allow

• This rule is needed for secure newsgroup access, if it is offered by your ISP or a third-party provider.

Internet Relay Chat (mIRC, ViRC, etc)
Internet Relay Chat can be used to converse with others online as well as to send and receive files using DCC (Direct Client-to-Client) protocol. For more details on this, please consult RFC 1459 - Internet Relay Chat Protocol.

Special Note: Take special care with files received through IRC since it is all too easy for malicious individuals to distribute viruses or trojans. Review this IRC Security article beforehand. If you receive or send files frequently, consider using a specialist anti-trojan tool (like TDS-3 or TrojanHunter) to scan incoming and outgoing files as well as updated anti-virus software.

Allow IRC Chat: Protocol TCP, Outgoing, Remote Port 6667, Allow

• This is needed for chatting online.

Allow IRC Ident: Protocol TCP, Incoming, Local Port 113, Allow

• This rule may be needed to connect to some IRC servers which use the Ident/Auth protocol to authenticate your connection - add it if this is the case.

Receive Files with IRC DCC: Protocol TCP, Outgoing, Remote Port 1024-65535, Allow
Send Files with IRC DCC: Protocol TCP, Incoming, Local Port 1024-65535, Allow

• If DCC rules are used, it is recommended that you keep them disabled until needed. If you then wish to send or receive a file, enable the appropriate rule only for the time needed and disable it afterwards;
• With DCC, the receiver has to initiate the connection - therefore to send a file, your system must receive a request. If you are using a NAT router, you will need to configure it to pass on any such request - check the router's documentation for details;
• Since DCC selects a random port (this range can be reduced with some clients), these cannot be greatly restricted. Instead, try to find the IP address of the other client (either via chat or by checking Outpost's log for previous failed attempts) and add it as a Remote Address to the rules;
• DCC transfers occur between your system and that of the other participant, the IRC server is not used - therefore Outpost's Stateful Packet Inspection option cannot be used.

E3 - Components Control

It is suggested that this be set to MAXIMUM - however this will result in periodic popups. If these appear to happen too frequently without good cause, try deleting the modules.ini and modules.0 files from the Outpost folder to force a component rescan.

Lowering the level to NORMAL will reduce the number of popups, but may cause Outpost to fail some leaktests.

[Paranoid2000]

F - Outpost Policy Settings (under Options/Policy)

Only Rules Wizard or Block Most policies should be used. In most cases, Rules Wizard is preferable since it will prompt for any undefined traffic, allowing for a new rule to be created immediately.

However, if the ruleset is complete and no further changes are wanted, then Block Most should be used. This policy should also be used when carrying out on-line scans to avoid the inconvenience of repeated rules prompts.

G - Outpost Plugin Settings (under Options/Plug-Ins Setup)

G1 - Active Content

Unless other software is being used to filter web content, it is recommended that all entries should be set to Disable and only Enabled for specific websites. The exceptions to this are Referers (which can cause hard-to-track problems with some websites) and, for Outpost 2.1, Animated GIFs (unimportant from a security perspective). Doing so will prevent websites from changing browser configuration (e.g. altering the homepage or favourites/bookmarks) or attempting to install unnecessary (or even malicious) software without user consent (this is known as a drive-by download). Such tactics are generally restricted to pornography and gambling (and some cracker) websites but occasionally an unscrupulous company attempts to take these into the mainstream. Please refer to Adware and Under-Wear - The Definitive Guide for more details.

Not all websites will like such treatment however, and settings may need to be relaxed if problems arise. This is best done by creating a specific entry for the website concerned and Enabling the options there - Enabling options globally would allow third-party sites, notably advertisers, to run undesirable Active Content. Depending on the symptoms and the details of the Active Content log, Enable the following and reload the web page (note that you may need to clear your browser's cache before reloading - alternatively many browsers allow you to do a "forced reload" by holding down the Shift key while clicking the Reload button).

Benefits: Improves security by preventing websites from installing software or changing settings surreptitiously, improves privacy by stopping user tracking via cookies.
Costs: Many websites will not function fully, others may not function at all. While most active content is optional (animated menus, button mouseovers), some sites will require their own settings. Finding these can be time consuming.

Cookies
If the site appears to "forget" information that you supply it - such as an account name, a login or if the basket (on shopping websites) stays empty when you select goods to purchase.

Javascript
If buttons do nothing when clicked, or cause the current page to be reloaded rather than going to a separate page.

Popup Windows (Outpost 2.0 only)
VB Script/Popup Windows (Outpost 2.1 and later)
If a button still does nothing when clicked, despite Javascript being enabled and an appropriate Blocked entry appears in the logs.

External Content (Outpost 2.1 and later)
If necessary webpage elements are being replaced with [EXT].

G2 - Ads

It is highly recommended that Eric Howes' AGNIS list be included in the Ad Filter. This list includes known spyware and malware-pushing websites as well as well as third-party advertisers and can, even in the absence of Active Content control, provide good protection from known abusers.

Due to the comprehensiveness of this list, it is possible that desirable content is filtered. If so, the Ads log should be checked to identify the keyword (or size) used. This can then either be removed from the filter list or (in Outpost 2.1) the website can be added to the Exclusions list - which will stop all ad filtering for that site.

Those having persistent issues should consider the Lite version of the AGNIS list.

Benefits: Removing ads will speed up page downloads and give a less cluttered webpage. Known malware-installing websites will be blocked.
Costs: desirable content may be blocked also. Many websites rely on advertising income and may not survive if everyone blocked their ads.

Instructions:

• Download the AGNIS list from the link given above - if the compressed .zip version is downloaded then use an appropriate utility (e.g. Winzip) to decompress it;
• If you wish to add custom entries, use Notepad to place these at the end of the ag-ads.ctl file (or ag-lite.ctl if you are using the Lite version). It is suggested that custom entries be stored in a separate file to make AGNIS updates easier;
• Right click on the Ads heading in the Outpost window left-hand pane and select Properties;
• Click on the icon under the "Show Ad Trashcan..." option (with orange and purple lines on it) - this should bring up an Open dialog box;
• Select the ag-ads.ctl/ag-lite.ctl file and click Open.

G3 - Attachments Filter

Aside from keeping this plugin enabled (to prevent the automatic execution of any email enclosures), there are no further recommendations to make, aside from scanning any flagged files for viruses and trojans.

G4 - Attack Detection

The recommended settings here will depend on whether another firewall (such as that of an external router) is in use. With another firewall, a lot of the "background noise" of scans and automated attacks will be filtered - and those that do reach Outpost should then be noted.

Alert Level:

• Maximum

Report Detected Attacks (Outpost 2.1 and later):

• Enable if another firewall is in use.
• Disable otherwise to avoid frequent popups.

Block Intruders:

• Enable if persistent attack reports are received. Use this setting with caution however since it can cause legitimate traffic to be blocked also.

Denial of Service Attacks:

• Enable only if on a LAN.

Ignoring Attacks from Trusted Hosts
It is possible for the Attack Detection plugin to misinterpret repeated connection attempts as an attack. This can happen with Browse Master and Domain Controller hosts on a Windows LAN which periodically connect to all other machines. To prevent this, either Disable the Attack Detection plugin or disconnect from the network, shutdown Outpost and edit the protect.lst file in the Outpost program folder.

Benefits: Avoids routine network connections from being treated as an attack and blocked.
Costs: Real attacks from these machines will no longer be detected or reported. Extra care should be taken to keep them secure.

Instructions: At the end of the protect.lst file should be an <IgnoreHosts> section - add the IP addresses of trusted hosts there as follows (example given for addresses 192.168.0.3 and 192.168.0.10). Backup the modified file to another folder in the event of it being overwritten by an Outpost upgrade (it is advised to disable the Tools/Automatically Check for Updates setting and do upgrades manually instead).

# <IgnoreHosts>
#
# 192.168.3.0/255.255.255.0 #Local Network
#
# </IgnoreHosts>

<IgnoreHosts>
#
192.168.0.3/255.255.255.255
192.168.0.10/255.255.255.255
</IgnoreHosts>

G5 - Content

No recommendations here.

G6 - DNS Cache

No recommendations here.

[Paranoid2000]

G7 - Blockpost

Blockpost is a third-party plugin available from the Outpostfirewall forum (at Dmut's Blockpost Plug-In forum). It blocks any and all communication with specified IP addresses, regardless of any other Outpost settings. This can be used in two ways:

• To block any communication with known spyware/adware sites using a list like blocklist_2004_03_06.txt;
• To prevent any access by known malicious addresses (which can be especially important to those using peer-to-peer programs like KaZaA, eMule, Gnutella, etc). Those using such programs should visit the Bluetack forums for a regularly updated blocklist and related utilities.

Note that since Blockpost works by IP address only, its list needs to be kept updated to be effective. It does not provide complete protection or anonymity since a determined attacker could acquire a new (and therefore unlisted) IP address, but will block any TCP, UDP or ICMP-based scan otherwise.

Note that if you use a proxy for Internet access, Blockpost will not filter traffic through that proxy (since all such traffic will have the proxy's IP address rather than that of the destination site) - if you wish to block access to suspect sites, configure your browser (if possible) not to use the proxy for them. Any attempted access will then include the site's IP address which may then be filtered by Blockpost.

G8 - HTTPLog

HTTPLog is another third-party plugin available from the Outpostfirewall forum (at Muchod's HTTPLog Plug-In forum). It logs details of any web page accessed and therefore can be useful for checking the effectiveness of filters as well as monitoring the activity of any program using HTTP to communicate.

G9 - SuperStealth

SuperStealth is another third-party plugin available from the Outpostfirewall forum (at Dmut's Super Stealth Plug-In forum). It filters ARP (Address Resolution Protocol) traffic, only allowing requests to and responses from specific addresses.

SuperStealth has no effect on security with regards to Internet access but instead provides control over Ethernet traffic on a Local Area Network. It is a specialised tool and should only be installed by those familar with ARP and Ethernet.


Document History

Version 1.01

• Section added for Outpost Free.
• Terminology changed - "DNS Heavy" now described as "Application DNS", "DNS Lite" as "Global DNS".
• Recommendation for ICMP Destination Unreachable packets altered.
• Global DNS section includes reference to application rules for services.exe/svchost.exe.
• Application DNS section now mentions DNShell leaktest.
• Added HTTP block rule to Email Client (to stop images being downloaded for spam emails).
• Sections G7-9 added for Blockpost, HTTPLog and SuperStealth plugins.
• Document History section added.

Version 1.00

First publicly released version.