• All linux versions of NetMAX
• Discussion of ipchains only applies to NetMAX version 2.0 - 3.2
• NetMAX 4.0x uses iptables

This tutorial assumes basic networking knowledge.

The NetMAX firewall is a packet filtering firewall. This means that as each IP packet is processed by the kernel, only the IP characteristics are examined without state or content examination. The IP characteristics include one or more of the following:

• Source IP Address and netmask
• Destination IP Address and netmask
• Protocol (i.e., TCP, UDP, esp)
• Port (if applicable)

Under Linux, firewalls rules are broken into three categories:

• Input
• Forward
• Output

Technically, a command-line user can create more categories, but this functionality is not supported.

Each category of firewall rules contain a separate list of characteristics which are used to determine if an action should be taken on the IP packet. Actions include:

• Allow
• Deny
• Masquerade (only for the forward category)

The list of characteristics are applied in the order that they are defined within the kernel (therefore giving the first rule the highest priority, the second the next priority, and so on). When the kernel examines the IP characteristics of an IP packet, the list of characteristics is examined until there is a match. If there is no match, no rule is applied. For the following examples, let us define three input rules with the following priorities, characteristics, and actions:

1. Source: 192.168.0.0/24, Destination: anywhere, Action: allow
2. Source: 10.1.1.0/24, Destination: 10.2.2.0/24, Action allow
3. Source: anywhere, Destination: anywhere, Action: deny

Example 1:

Incoming packet with Source: 192.168.0.1, Destination: 192.245.33.1

RESULT: Input Rule #1 applies, therefore the IP packet is ALLOWED.

Example 2:

Incoming packet with Source: 192.168.199.1, Destination: 192.245.33.1

RESULT: Input Rule #3 applies, therefore the IP packet is DENIED. This is because neither #1 nor #2 apply to this packet.

Example 3:

Incoming packet with Source: 10.1.1.1, Destination: 192.245.33.1

RESULT: Input Rule #3 applies, therefore the IP packet is DENIED.

Example 4:

Incoming packet with Source: 10.1.1.45, Destination: 10.2.2.99

RESULT: Input Rule #2 applies, therefore the IP packet is ALLOWED.

We can get more specific by including more IP characteristics. For the following examples, let us define input rules are follows:

1. Source: 192.168.0.0/24, Destination: anywhere, Protocol: TCP, Port: 23, Action: deny (block TCP traffic for telnet)
2. Source: 10.1.1.0/24, Destination: 10.2.2.0/24, Protocol: ddp, Action deny (ddp is for AppleTalk)
3. Source: anywhere, Destination: anywhere, Action: allow

Example 1:

Incoming packet with Source: 192.168.0.1, Destination: 192.245.33.1, Protocol: UDP

RESULT: Input Rule #3 applies, therefore the IP packet is ALLOWED. #1 does not apply because the protocol is not TCP.

Example 2:

Incoming packet with Source: 192.168.0.1, Destination: 192.245.33.1, Protocol: TCP, Port: 23

RESULT: Input Rule #1 applies, therefore the IP packet is DENIED.

Example 3:

Incoming packet with Source: 99.99.99.1, Destination: 88.88.88.2, Protocol: TCP, Port: 23

RESULT: Input Rule #3 applies, therefore the IP packet is ALLOWED.

Rule #3 is necessary with L22Pv3.0x because the default action (no rules apply) is to DENY the packet.

----

Rules of order

The next thing to understand about Linux firewalls is the order that categories are processed: Input, Forward, and then Output. Therefore, as a packet is received by the kernel, input rules are checked first, forward rules second, and output rules last.

From the IPCHAINS-HOWTO http://metalab.unc.edu/pub/Linux/docs/HOWTO/IPCHAINS-HOWTO

          ----------------------------------------------------------------
          |            ACCEPT/                              lo interface |
          v           REDIRECT                  _______                  |
  --> C --> S --> ______ --> D --> ~~~~~~~~ -->|forward|----> _______ -->
      h     a    |input |    e    {Routing }   |Chain  |     |output |ACCEPT
      e     n    |Chain |    m    {Decision}   |_______| --->|Chain  |
      c     i    |______|    a     ~~~~~~~~        |     | ->|_______|
      k     t       |        s       |             |     | |     |
      s     y       |        q       |             v     | |     |
      u     |       v        e       v            DENY/  | |     v
      m     |     DENY/      r   Local Process   REJECT  | |   DENY/
      |     v    REJECT      a       |                   | |  REJECT
      |   DENY               d       --------------------- |
      v                      e -----------------------------
     DENY

This makes it possible to receive a packet with a particular set of characteristics but not send one with the same.

----

Forwarding rules

Assuming the input rules are such that the input rules allow a packet to continue to be checked for its characteristics, the forwarding list of rules will be applied. Forwarding rules have two mode: plain and masquerade. For a "plain" forward rule, the source IP address remains unchanged and for a "masquerade" forward rule, the srouce IP address is changed to that of the network interface which is receiving the packet.

The most commonly used forwarding rule is the basic masquerading, referred to at NAT within the NetMAX interface (this is a legecy term from the original FreeBSD version which has a "true" NAT). This rule says to forward with masquerade any UDP or TCP traffic from any address to any address. By selecting the NAT option within a network interface's interface (Home|Network|Interfaces), a forward masquerading rule is created for all traffic THROUGH the selected interface. NAT is usually enabled on the network interface which connects to the Internet so that traffic bound to an IP address not within the LAN is made to appear as if it comes from the IP address of the NetMAX on the Internet.

• If NAT is enabled, it will always be the last forward rule so that the user's manually entered forward and/or masquerade rules take precedence.

• If NAT is enabled, it become critical that appropriate rules are enabled to prevent undesired access - the NAT rule works IN BOTH DIRECTIONS (i.e., traffic from the Internet can appear as if it comes from the NetMAX firewall).

----

When are manually entered forwarding rules necessary? (Some examples)

A. You are connected to a complex network an do not want all traffic to be NAT'ted. Take this network as an example:

[10.1.1.1]     [10.254.1.1]        [192.1.1.1]
[Machine 1] <--> [Router 1  ] <--> [Router 2 ] <--> Internet
                   [192.1.1.2 ]

Machine 1: a completely internal machine
Router 1: this machine has two IP addresses, one on the completely internal network and a second on the routable 192.* address.
Router 2: this machine has only an Internet accessable address and is connected to the Internet

If Router 1 is set up with the generic masquerade rule (from anywhere to anywhere) on the 192.1.1.2 interface, then traffic from 10.* to 192.* will always appear to originate from 192.1.1.2 because its traffic will be masqueraded. In addition, traffic from 192.* (sort of excluding Router 1) to 10.* will appear to have a source address of 192.1.1.2.

It might be desirabled (for file sharing purposes, for example) to NOT masquerade the traffic to 192.* from the 10.* network. Therefore, forwarding rules can be added with the following properties:

ACCEPT FORWARD from 10.0.0.0/8 to 192.1.1.0/24 ACCEPT FORWARD from 192.1.1.0/24 to 10.0.0.0/8

Therefore, the 192 and the 10 networks can communicate without having IP addresses translated.

o Router 2 should have firewall rules which prevent access to the 10.* network. Most ISPs will not route 10.* traffic, but one can never be too careful. The NetMAX rules for "Block IP address spoofing attacks (external traffic with internal IP addresses)" automatically includes rules to block several categories of traffic which ISPs should never route.

B. You have a hybrid public/private IP network:

       Internet
          |
          |
      [192.2.2.1]
      [Router 2 ]
[192.1.1.1] [10.1.1.1]
    |            |
    |            |
[Machine 2] [Machine 1]
[192.1.1.2] [10.1.1.2 ]

In this example, the 192.* addresses are public and the 10.* addresses are private. Enabling NAT on the 192.2.2.1 interface is probably not desired because the 10.* AND the 192.1.1.* machines will be masqueraded. Therefore, we should set up manual masquerading and forwarding rules.

1. ACCEPT FORWARD from any to 192.1.1.0/24
2. ACCEPT FORWARD from 192.1.1.0/24 to any

   (these rules allow Internet access to the 192.1.1.* network

3. ACCEPT FORWARD from 10.0.0.0/8 to 192.1.1.0/24
4. ACCEPT FORWARD from 192.1.1.0/24 to 10.0.0.0/8

   (these rules allow, for example, Machine 1 and Machine 2 to communicate directly)

5. MASQUERADE FORWARD from 10.0.0.0/8 to any

(traffic destined for the Internet IS masqueraded, there should also be a rule to block traffic from 10.0.0.0/8 on the input of the 192.2.2.1 interface)

----

Interesting command-line uses of the IPCHAINS command

1. To list the current set of active rules:

   ipchains -L -n

2. To list the current input rules, output rules, and forwarding rules, respectively:

   ipchains -L input -n
   ipchains -L output -n
   ipchains -L forward -n

3. Since masquerading tracks NAT'ted connection, we can see the list of these"

   ipchains -M -L -n

----

Adding firewalls rules which cannot be defined within the NetMAX interface

Starting with L22Pv3.0, the /etc/rc.firewall script now checks for an executable file in /etc/rc.firewall.local and runs the program (probably users will want to use a "shell" script).

Example script (remember to chmod +x /etc/rc.firewall.local):

#!/bin/sh
/sbin/ipchains -M -S 3600 0 0

This sets the timeout value for TCP connections to 1 hour (60*60), the FIN and UDP connections are unchanged because of the zeros. The default is 15 minutes such that telnet sessions without traffic for 15 minutes are disconnected.
address-suppressed