IP Rules/Policies - Best Practice

How to's for older versions of CorePlus
Post Reply
Tomas
Posts: 34
Joined: 15 Sep 2008, 15:57
Location: Clavister HQ - Örnsköldsvik

IP Rules/Policies - Best Practice

Post by Tomas » 03 Apr 2013, 11:50

This How-to applies to:
  • Clavister cOS Core Security Gateway 10.x
  • Clavister CorePlus Security Gateway 9.x
  • Clavister CorePlus Security Gateway 8.x
Pre-requisities
Clavister Security Gateway

Topics covered in this document
  • Background
  • IP Rules
  • IP Policies
  • Best practices
  • IP Rule Order
  • Combining IP Rules with IDP
  • Combining IP Rules with Application Control
  • Start kit of IP Rules that all should implement
  • Screen shot and a configuration file with the recommended IP Rules
Background

IP Rules 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 rules is therefore extremely important.

We will try to describe the available tools you have to secure your firewall installation, and give you a "start kit" of IP Rules that you should incorporate in all your firewall installations.

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

IP Rules

The format of the IP Rules described in this document is the following:

Action, Source Interface, Source Network, Destination Interface, Destination Network, Service

Action = Allow, NAT, Forward Fast(=Stateless), Drop, etc. It describes how the traffic should be forwarded.

Source and Destination interfaces have been determined by the Routing process before the IP Rules are consulted.

Service is a property of the traffic, such as TCP destination port or IP Protocol type.

IP Policies

IP Policies are a simplification of IP Rules, and they will actually create one or several IP Rules per IP Policy. This can be seen in the CLI by typing "rules".

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.

We will only use IP Rules in this document.

Best Practices
  • Avoid using “any” on the Destination interface, unless you really understand the consequences.

    A bad example:
    • NAT lan lan_net any all-nets all_tcpudpicmp
    You will NAT traffic even to your DMZs and all other accessible interfaces (=networks), when you most likely only wanted to NAT the traffic to the Internet (Wan).

    A better example :
    • NAT lan lan_net wan all-nets all_tcpudpicmp
    A really bad example:
    • NAT any all-nets any all-nets All_services
    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 ALGs wherever possible
    - They only allow the ALG 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 Rule Order

Guideline for the ordering of your IP Rules
  • Avoids IP Rule collisions
  • Avoids forwarding traffic you want to block
  • Easier to find the rule you are looking for
  • Each group (where it applies) should end by Drop rules
  • Drop all traffic FROM the source
  • Drop all traffic TO the source
  • The ordering also applies to multiple IP Rulesets
  • 1. Reject and Drop rules
    -- Usually Goto Rules are placed here, so the following rules might be in an alternate IP Ruleset --
    2. Internal Bounce rules
    3. Allow rules for traffic inside IPsec tunnels
    4. Drop NetBIOS rule
    5. SAT-Allow-NAT rules
    6. NAT/Allow rules
    7. Drop All rule
Explanation:

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. Fwdfast lan lan_net lan lan_net All
- A client has mask 255.255.255.255
- There is an internal router to another network

3. Allow or NAT rules for traffic inside IPsec tunnels

4. Drop all Windows File sharing traffic

5. Servers accessible from in- and outside

6. NAT and Allow rules
- Between local networks
- To the Internet
- Multicast traffic

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

Combining IP Rules 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 Rules with Application Control

Different from IDP, the Application Control is applied directly on the IP Rules, 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 Rules in a second ruleset just to apply the Application Control. A drawback is in a scenario with many IP rules (hundreds or more) and you want to apply Application Control in e.g. Audit mode, you must add it to all the IP Rules, 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 Rules that all should implement

This is the grand finale of this Howto document. We will try to give you a good foundation of IP Rules 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.

Objects needed:
  • Internal
    - An Interface Group that contains all your "internal" networks, such as your Lan interface and any other interface where you have machines that should reach the Internet.
  • Outbound_services
    - A Service Group that contains the minimum amount of services that you can use for general "Internet access". Most likely this will contain a service for HTTP with an HTTP ALG (important for additional security). Any additional services are added "on your own risk". E.g. HTTPS is most likely needed, but then you should at least use our URL filtering for HTTPS and Application Control to find applications using this port, as they normally encrypt the traffic. See below for detailed suggestions how to configure this
  • Proto-41
    - A Service for IP Protocol 41
  • Teredo
    - A Service for UDP destination port 3544
  • HTTPS_WCF_out
    - A Service with TCP destination port 80, with an HTTPS ALG with Web Content Filtering enabled
  • HTTP_AV_WCF_out
    - A Service with TCP destination port 80, with an HTTP ALG with Antivirus and Web Content Filtering enabled
  • HTTP_AV
    - A Service with TCP destination port 80, with an HTTP ALG with Antivirus enabled
  • AC_Audit
    - An Application Control Ruleset which allows all applications but will audit (log) all applications



IP Ruleset Main

1. Reject and Drop rules
  • Reject wan all-nets any all-nets Ident
--- These will drop most tunnels that are used for IPv6 access via an IPv4 tunnel ---
  • Drop any all-nets any all-nets Proto-41
  • Drop any all-nets any all-nets Teredo
  • Drop Internal all-nets any 192.88.99.1 all_services
-- Usually Goto Rules are placed here, so the following rules might be in an alternate IP Ruleset --

2. Internal Bounce rules
  • FwdFast lan all-nets lan all-nets all_tcpudpicmp
3. Allow rules for traffic inside IPsec tunnels
  • Allow lan lan_net IPsec_Tunnel11 Tunnel1_net HTTP_AV
  • Allow IPsec_Tunnel11 Tunnel1_net lan Server_ip HTTP_AV
4. Drop NetBIOS rule
  • Drop any all-nets any all-nets NetBIOS
5. SAT-Allow-NAT rules
  • SAT any all-nets core wan_ip HTTP_AV SetDestination=Server_ip
  • Allow wan all-nets core wan_ip HTTP_AV AC_Audit
  • NAT Internal all-nets core wan_ip HTTP_AV AC_Audit
6. NAT/Allow rules
  • NAT Internal all-nets core all-nets ping-inbound
  • NAT Internal all-nets WAN 141.1.1.1 DNS-UDP AC:Filter:DNS_Only
  • NAT Internal all-nets WAN all-nets Outbound_services AC_Audit
  • Allow Internal all-nets6 WAN all-nets6 Outbound_services AC_Audit (yes, AC also works for IPv6!)

7. Drop All rules
  • DropAll-main_ruleset any all-nets any all-nets all_services
  • DropAll-main_ruleset any all-nets6 any all-nets6 all_services
Screen shot and a configuration file with the recommended IP Rules
Default_IPRuleset.zip
Backup File from a V3 VSG with the default Rules
(6.44 KiB) Downloaded 503 times
Default_IPRules.zip
A script with the complete configuration backup. This can be modified and used on any cOS Core model.
(4.14 KiB) Downloaded 500 times
Default_IPRuleset.png
Default IP Rules
Default_IPRuleset.png (77.35 KiB) Viewed 12350 times

Post Reply