IP Policies - Best Practise

Security Gateway Articles and How to's
Post Reply
Posts: 41
Joined: 24 Oct 2016, 08:23

IP Policies - Best Practise

Post by mape » 08 Sep 2017, 11:01

This How-To applies to:
  • Clavister cOS Core Version 12.x
  • Clavister cOS Core Version 11.x

Claivster Next Generation Firewall

Topics covered in this How-To
  • Background
  • IP Policies
  • Best Practice
  • IP Policy order
  • Combining IP Polices with IDP
  • Combining IP Polices with Application Control
  • Starting kit with basic IP Polices
  • Screenshot and configuration backup of IP Polices that you might need.

IP Polices are the “Last line of defence" in your network. They control which traffic is passing through your firewall, how it is forwarded and also which traffic is dropped. Writing safe and correct IP Polices is therefore extremely important.

We will try to describe the available tools you have to secure your firewall installation, and give you a "starting kit" of IP Polices that could be smart to incorporate to all your firewall installations.

To create your IP Polices, you might also need to create some additional services or service groups.

IP Polices
IP Policies is basically the next generation of "IP Rules". IP polices will create one or several IP Rules per IP Policy in the background. This can be seen in the CLI by typing "rules". Please note that cOS Core will move more and more towards the use of IP policies instead of IP rules, meaning that future features will only be possible to configure using IP policies. It is therefore recommended to only use IP polices whenever possible.

The following format will be used for the IP Polices in this How-To:
SourceInterface, SourceNetwork, DestinationInterface, DestinationNetwork, Service, Action, Application Control, SrcAddressTranslation, DestAddressTranslation, Profiles(Anti Virus, WCF etc.)

The two best features with IP Policies is the simplification of Port Forwarding (the three SAT + Allow + NAT IP rules are created with a single IP Policy) and the automatic functionality to select NAT or Allow as action, depending on if the source and destination are public IP addresses or private (RFC 1918) addresses.

If you want to know more about IP Rules and how to best use them, please see the following link:

Best Practice
Some tips that could be good to remember when creating IP Policies.
  • Avoid using “any” on the Destination interface, unless you really understand the consequences.

    A bad example:
    • Lan Lan_Net Any all-nets all_tcpudpicmp Allow NAT
    You will NAT traffic even to your DMZs and all other accessible destination interfaces (and networks), when you most likely only wanted to NAT the traffic to the Internet (Wan).

    A better example :
    • Lan Lan_Net Wan all-nets all_tcpudpicmp Allow NAT
    You will only NAT traffic from you local interface and Network to the Internet (Wan)

    A really bad example:
    • Any all-nets Any all-nets All_services Allow NAT
    This is really nasty. This bypasses the whole firewall functionality more or less.
  • Allow/NAT only the minimum amount of services and protocols/ports
    - Inbound
    -- Only to servers on separate DMZ(s)
    -- Only the necessary destination ports
    - Outbound
    -- As few destination ports and IP protocols as possible.
  • Use Profiles wherever possible
    - They only allow the Web protocol to pass through.
    - Avoids "port tunnelling” e.g. when backdoors use TCP/80 to contact "the mothership”.
  • Use IDP signatures to detect and block suspicious traffic
    - Backdoor traffic which is "smart" and e.g. uses proper HTTP commands for its malicious deeds can be detected and blocked.
  • Use Application Control
    - To further control the type of traffic being forwarded

IP Policy Order
Guideline for the order your IP Polices should be created, from top to bottom. Which rule types that should be placed in what order (suggestion).

1. Reject and Drop policy
-- Usually Goto Rules are placed here, so the following rules might be in an alternate IP Ruleset --
2. Allow/Nat policies for traffic inside IPsec tunnels
3. Drop NetBIOS policy
4. SAT-Allow-NAT policies
5. NAT/Allow policies
6. Drop All policy[/list]


1. Reject incoming traffic and immediately drop known bad traffic
- Reject Ident (TCP/113) Unix systems will give up immediately and your SMTP traffic will be delivered immediately
- Drop e.g. protocols that can be abused, such as IP Protocol 41 or Teredo tunnels, and known bad hosts.

2. Allow or NAT rules for traffic inside IPsec tunnels

3. Drop all Windows File sharing traffic

4. Servers accessible from in- and outside

5. NAT and Allow policies
- Between local networks
- To the Internet
- Multicast traffic

6. Drop all other traffic
- There is a "Default Rule" that will drop it anyway, but if you have multiple IP Rulesets, it is convenient to see in which Ruleset the trafic was dropped.

The reason why we want to place them in the above order is because rules are read/triggered from the top to the bottom. As an example we would like to drop the Windows file sharing between interfaces even though we allow it further down in the ruleset. By placing such a drop rule high up we make sure there is no rule "leakage" and allow the traffic by accident by a less restrictive rule. When having thousands of rules it can easily become saturated.

Combining IP Policies with IDP
IDP, or Intrusion Detection and Prevention, is handled in a separate ruleset which is consulted after the IP Ruleset. You create your rules there, selecting the suitable IDP signatures for your network.
Remember to scan inbound traffic to your servers, as well as outgoing traffic from your clients to the internet and any internal servers.

Combining IP Polices with Application Control

Different from IDP, the Application Control is directly applied on the IP Policy, either as a "manual" entry, or as a separate "profile", which is a rule set of its own.

This has some advantages and some drawbacks. Advantages are e.g. that you do not have to "duplicate" your IP Policies in a second ruleset just to apply the Application Control. A drawback is in a scenario with many IP Policies (hundreds or more) and you want to apply Application Control in e.g. Audit mode, you must add it to all the IP Polices, which may be time consuming, or requires some scripting.

That said, the additional information and control you get over the traffic by using Application Control, is well worth any such effort! It is no understatement that the term "Next Generation Firewalls" was coined for firewalls with this technology, as it opens up features that regular firewalls (generations 1, 2 and 3) simply does not have.

Start kit of IP Polices that Is a good start for new Installations

This is the grand finale of this Howto document. We will try to give you a good foundation of IP Policies to use, to limit the possible problems you may encounter.
You must also read this recommendation with a grain of salt. Some items will not apply to your installation, and some need modification to be usable. We will of course use our rule ordering that we recommended above.

IP Ruleset Main

1. Drop this traffic as early as possible.
Wan all-nets any all-nets Ident drop

--- The below Policies will drop most tunnels that are used for IPv6 access via an IPv4 tunnel ---
(The reason why we want to drop this is because IPv6 traffic going to a tunnel won't be picked up by any rules, causing the user to be able to access things on the internet that we don't want them to access)

any all-nets any all-nets Proto-41 Drop
any all-nets any all-nets Teredo Drop
Internal all-nets any all_services Drop

-- Usually Goto Rules are placed here, so the following rules might be in an alternate IP Ruleset --

2. Policies for allowing traffic inside IPsec tunnels.
Lan Lan_Net Roaming IPsec_net all_services Auto
Roaming IPsec_Net Lan Lan_Net all_services Auto

3. Drop Windows Fileshare traffic.
any all-nets any all-nets smb-all Drop

4. SAT and NAT to an internal server.
Wan all-nets core Wan_IP http AC_Audit Allow NAT SAT_ Server_IP AV
Internal Internal_Net DMZ Server_IP http Allow Nat AV

AV means that a Anti Virus Profile has been enabled.

5. Outbound Policies for Internet traffic. Use Policies and Application Control to limit.
Internal Internal_Nets core all-nets ping-inbound Allow Auto
Internal Internal_Nets WAN all-nets DNS-UDP AC_Audit NAT
Internal Internal_Nets WAN all-nets http AC_Audit NAT AV Web
Internal Internal_Nets WAN all-nets https AC_Audit NAT Web

AV means that a Anti Virus Profile has been enabled.
Web means that A Web Profile(Web Content Filtering/Black-White lists) has been enabled.

6. Drop All.
any all-nets any all-nets all_services Drop
any all-nets6 any all-nets6 all_services Drop

Screen shot and a configuration file with the recommended IP Rules
Backup File from a E20 with the default Polices
(7.04 KiB) Downloaded 433 times
A script with the complete configuration backup. This can be modified and used on any cOS Core model.
(1.85 KiB) Downloaded 436 times
Default IP Policies
Default IP Policies
Default_IPRuleset.jpg (218.31 KiB) Viewed 8389 times

Post Reply