Building a fault-tolerant firewall system with virtual machines: Writing a firewall ruleset

Posted by: Tuyen Pham Thanh 1 year, 1 month ago

(0 comments)

Rules are the building material of the firewall. A firewall without a rule set is an empty firewall, like an air wall. Meaning it allows all including unwanted packets.

It's called rule-writing because rule-setting is flexible. There are no hard rules and for the same purpose we can write in many ways. For example, for the conntrack state we can rely on the internal state, the status of conntrack; or rely on external state, ctinfo. ctinfo is conntrack's state information but is updated according to the context. They are not completely identical. ctinfo shows the direction of the flow, status does not. Conversely, status indicates that a conntrack is expected while ctinfo no longer holds this information once the connection has been established in the conntrack semantics. However, in some situations they mean the same thing. For example ct state established is equivalent to ct status seen-reply. ct state related is equivalent to ct status expected tcp flags syn. ct state established ct direction original is equivalent to ct status assured.
So how to write it depends on the person building the firewall. You can use goto or jump to break down the rule set to make it brighter.
Not a requirement, but you can create a flow table (flowtable) to accelerate packet forwarding and offload flow. Once conntrack is established, you can choose to place the flow entry into the table using flow add rule. Each entry is represented by a seven-element tuple: source address, destination address, source port, destination port, layer 3 protocol, layer 4 protocol, and input interface. In addition, it also caches the output interface. At the ingress hook, if the flow entry is found in the table, the packet will bypass the classic forwarding path i.e. not go through the netfilter hooks behind ingress but go directly to the output interface via the neigh_xmit() function in the hook nf_flow_offload_inet_hook().

In our example the firewall allows only the following services:

     1. DNS (UDP, port 53)
     2. www (TCP, port 80, 443)
     3. File Transfer (TCP, port 21 with helper)
     4. Secure remote login - ssh (TCP, port 22)
     5. ping (ICMP, echo-request and echo-reply types)


The simple ruleset is as follows:

table inet ftfw {
    ct helper ftp-std {
        type "ftp" protocol tcp
        l3proto inet
    }

    counter counter_exp {
        packets 0 bytes 0
    }

    flowtable flow_exp {
        hook ingress priority filter
        devices = { eth0 }
    }

    chain prerouting {
        type filter hook prerouting priority filter; policy accept;
        tcp dport 21 ip daddr 192.168.0.3 ct state new \
            ct helper set "ftp-std"
    }

    chain forward_reply {
        ct status expected flow add @flow_exp \
            counter name "counter_exp" accept
        accept
    }

    chain forward {
        type filter hook forward priority filter; policy drop;
        iifname "eth0" ct state established ct direction reply \
            goto forward_reply
        iifname "eth1" tcp dport { 21, 22, 80, 443 } tcp flags syn \
            ct state new accept
        iifname "eth1" udp dport 53 ct state new accept
        iifname "eth1" ct state related ct helper "ftp" accept
        iifname "eth1" ct state established ct direction original accept
        icmp type echo-request limit rate 1/second accept
        ct state invalid log prefix "FORWARD-INVALID: "
    }
}
table inet nat {
    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;
        oifname "eth0" ip saddr 192.168.2.3 snat ip to 192.168.0.100
    }
}

We create flowtable flow_exp with input interface eth0 to offload large file download flow from file server. Offload only applies to the expected connections. The packets then bypass the classic forwarding path and go straight to the eth1 interface. We also add counter counter_exp to check the offload effect. After downloading a large file the counter_exp counter shows that the traffic going through the classic forwarding path is only the first packet with 60 bytes, all the remaining traffic has gone through the forwarding fastpath

• ← Building a fault-tolerant firewall system with virtual machines: expectation: part 3: diagram
• Kernel patch due to loss of helper →