Introduction

IP Polices are probably the most important line of defense in a NetWall firewall. They control which traffic can pass through the firewall, how it is forwarded and also which traffic is dropped. Writing secure and correct IP Polices is therefore extremely important. We will try to describe the tools available in order to secure a firewall installation, and also describe a “starting kit” of IP Polices that could be useful to incorporate in a new firewall installation.

For our IP Polices, we may also need to create some additional services or service groups.

IP Polices

IP Policies are an improved method of configuring the older cOS Core”IP Rules”. An IP Policy may represent one or several IP Rules in the background. These background IP rules can be viewed in the CLI by entering the “rules” command. Note that cOS Core will move more and more towards the use of IP policies instead of IP rules, meaning that future features may only be possible to configure using IP policies. It is recommended anyway to only use IP polices whenever possible, especially on a new cOS Core installations.

The following format will be used for the IP Policy rule set entries in this guide:

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

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.
  
  • An example of how not to use Any.

In this example we would NAT traffic even to your DMZs and all other accessible destination interfaces (and networks), when we most likely only wanted to NAT the traffic to the Internet (Wan). This also means that any new/added interfaces in the future would also be automatically be included.

A better format of this IP policy would be:

Now we will only NAT traffic from our local interface and network when the destination interface is Wan (towards the Internet).

Another example of an IP policy that should never be used:

This type of IP policy is really bad, this basically bypasses the whole firewall functionality more or less as it allows communication to/from all interfaces and all networks in any direction. The only reason a rule such as this would ever be created and used would be for testing or lab purposes.

Some things to keep in mind

• 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.
• Activate IP reputation. This is a great low resource requirement feature that can easily be turned on/off under the Threat Prevention section in the WebUI.

IP Policy Order

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

Note: IP Policies/Rules are read from the top to the bottom, once a matching rule has been found the rule lookup stops.

1. Reject and Drop policies
   1. 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.

Explanation

1. Reject incoming traffic and immediately drop known bad traffic.
   1. Reject Ident (TCP/113) Unix systems will give up immediately and your SMTP traffic will be delivered immediately.
   2. Drop e.g. protocols that can be abused, such as IP Protocol 41 or Teredo tunnels, and known bad hosts. Some more information about IP protocol 41. Denying IP protocol 41 by default is generally a good idea, as it is a protocol that is commonly associated with tunneling protocols such as 6in4, 6to4, and Teredo. These tunneling protocols are used to encapsulate IPv6 packets within IPv4 packets to enable communication between IPv6 networks over an IPv4 infrastructure. However, while tunneling protocols can be useful for certain types of traffic, they can also be used by attackers to bypass network security controls and launch attacks. By denying IP protocol 41 by default, we can prevent attackers from using these tunneling protocols to evade network security controls and launch attacks. That being said, if we have a specific business need for tunneling protocols, such as for enabling remote access to an IPv6 network, we may need to allow IP protocol 41 through our firewall. In such cases, it is important to carefully evaluate the risks and implement appropriate security controls to minimize the risk of attacks.
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:
   1. Between local networks.
   2. To the Internet.
   3. 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 in, it can also be useful to call the drop rule something unique to make it stand out a bit in case the criterias for it "should" never happen, like calling the final drop rule "ARGH_DROP_IT" or similar.

The reason why we want to place them in the above order is to again highlight that 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. We create our rules there, selecting the suitable IDP signatures for our network.
Remember to scan inbound traffic to internal servers, as well as outgoing traffic from your clients to the internet. The signatures to use for incoming and outgoing should not be the same though.

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 we do not have to duplicate our 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 we want to apply Application Control in e.g. Audit mode, we must add it to all the IP Polices, which may be time consuming, or requires some scripting.

That said, the additional information and control we 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.

Starter kit of IP Polices

This is the finale of this guide. We will try provide a good foundation of IP Policies to use, to limit the possible problems that may be encountered. Also please be aware to take this recommendation with a grain of salt. Some items will not apply to all installations as each customer setup/network/requirements are unique, and some need modification to be usable. We will of course use our rule ordering that we recommended above, also take note that the rule order and index is very important.

Creating the policies

1. Drop this traffic as early as possible.

   1. Rule index	Action	Source Interface	Source Network	Destination Interface	Destination Network	Service	Application	Address Translation	Options
      1	Drop	Wan	All-nets	Any	All-nets	Ident

2. 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.

   1. Rule index	Action	Source Interface	Source Network	Destination Interface	Destination Network	Service	Application	Address Translation	Options
      2	Drop	Any	All-nets	Any	All-nets	Proto-41
      3	Drop	Any	All-nets	Any	All-nets	Teredo
      4	Drop	Internal	All-nets	Any	192.88.99.1	All_Services

3. Usually Goto Rules are placed here, so the following policies could be in an alternate IP Ruleset depending on preference.
4. Policies for allowing communication to/from IPsec tunnels (traffic inside the tunnel(s)). Roaming in this case is a client-type IPsec tunnel that usually only requires one rule that allows communication from the tunnel to the local network, but if this was a Lan2Lan tunnel between two endpoints, two IP policies would be needed if traffic is to be allowed to be initiated from either direction. Rule index #5 in case of a roaming client tunnel would not be needed if we have determined that there would never be any connections initiated from the Lan back to the connected client(s).
   

   1. Rule index	Action	Source Interface	Source Network	Destination Interface	Destination Network	Service	Application	Address Translation	Options
      5	Allow	Lan	Lan_Net	Roaming	IPsec_net	All_services		Auto
      6	Allow	Roaming	IPsec_net	Lan	Lan_Net	All_services		Auto

5. Drop Windows fireshare traffic.

   1. Rule index	Action	Source Interface	Source Network	Destination Interface	Destination Network	Service	Application	Address Translation	Options
      7	Drop	Any	All-nets	Any	All-nets	smb-all

6. 4. SAT and NAT traffic to an internal server.
   

   1. Rule index	Action	Source Interface	Source Network	Destination Interface	Destination Network	Service	Application	Address Translation	Options
      8	Allow	Wan	All-nets	Core	Wan_IP	http	AC_Audit	NAT, SAT(Dest=Server_IP)	AV
      9	Allow	Internal	Internal_Net	DMZ	Server_IP	http	AC_Audit	NAT	AV

   2. Rule index #8 does not really need any source translation (NAT), this can be changed to <auto> as we would like to see the source IP of clients in the web server logs when they arrive from the internet.
      1. Same with index #9 but when connections arrive to the server IP directly from the Internal (e.g. Lan) interfaces.
   3. AV means that a Anti Virus Profile has been enabled.
7. Outbound Policies for Internet traffic. Use Policies and Application Control to limit which applications that are allowed.
   

   1. Rule index	Action	Source Interface	Source Network	Destination Interface	Destination Network	Service	Application	Address Translation	Options
      10	Allow	Internal	Internal_Nets	Core	All-nets	ping-inbound		Auto
      11	Allow	Internal	Internal_Nets	Wan	All-nets	DNS-UDP	AC_Audit	NAT
      12	Allow	Internal	Internal_Nets	Wan	All-nets	http	AC_Audit	NAT	AV Web
      13	Allow	Internal	Internal_Nets	Wan	All-nets	https	AC_Audit	NAT	Web

   2. Application Control is configured to run in Audit mode initially to first get an overview of what applications is identified/used in the network. The next step after that would be to determine what should be allowed or not.
   3. AV means that a Anti Virus Profile has been enabled.
   4. Web means that A Web Profile(Web Content Filtering/Black-White lists) has been enabled.
8. Drop everything that does not match any of the above rules.

   1. Rule index	Action	Source Interface	Source Network	Destination Interface	Destination Network	Service	Application	Address Translation	Options
      14	Drop	Any	All-nets	Any	All-nets	All_services
      15	Drop	Any	All-nets6	Any	All-nets6	All_services

Screen shot of finished configuration with comment groups

Below is the finished rule set of the above example along with some color coded comment groups/rows to make it easier to read.

Sample configuration file

Lastly the sample configuration is available below in a backup format as well as a script.

config-Device-20170810-v003.zip

Default_IPPolicies.zip

Note-1: If we want to look at the configuration, unpack the zip file called “config-Device-20170810-v003.zip” and connect to the firewall WebUI, then go to Status→Maintenance→Backup & Restore and select the configuration file and click “Restore Configuration”. But at the next step do not click “Activate configuration” as it will will due to the configuration will not match your target hardware or environment. But when we are at this stage we can now click around the configuration and look at it, once we are done looking simply select “discard changes” (or use the CLI command “Reject -all”) in order to revert the configuration stored in memory to what is actively deployed (the previous state basically).
Note-2: The script file is not possible to restore as it tries to add various interfaces, objects etc. that will not match the destination hardware or environment. It’s mainly intended to view and perhaps copy some relevant parts from.

Related articles

No related articles found.