shorewall vs iptables


Shorewall to iptables

On startup, shorewall translates its configuration into a set of iptables rules and loads them. You can see the contents of /var/lib/shorewall/.reload for the nitty-gritty details of how this done. This article tries to provide a basic overview of how shorewall configuration results in iptables chains and rules. In a follow up, we'll try to discover how you can mix a shorewall configuration with dynamicly added iptables rules.

The translation is governed by some basic principles. For instance, a separate chain is created for every transition of traffic from one zone to another or to all. By conventions, these chains are called "{zone_name}2{zone_name}", where {zone_name} may be one of the zones or "all". For instance, the chain that contains the rules for the transition from "net" to "fw" will be called "net2fw".

To show the translation from shorewall zones into iptables chains we'll use the configuration from the standalone firewall example.

A view from shorewall

Zones and interfaces

/etc/shorewall/zones
#ZONE   TYPE
fw      firewall
net     ipv4
/etc/shorewall/interfaces
#ZONE   INTERFACE       BROADCAST       OPTIONS
net     eth0            detect          dhcp,routefilter,tcpflags
This will result in a number of chains to be branched off from the standard iptables chains:
  • "eth0_in" chain will be branched off from INPUT for any incoming traffic on eth0
  • "eth0_fwd" chain will be branched off from FORWARD for any eth0 traffic
  • "fw2all" chain will branched from OUTPUT for any eth0 traffic
The options provided for the "eth0" interface will also cause additional chains to be branched off at the start of the "eth0_in" chain:
  • "dynamic" chain for dynamic blacklisting
  • "tcpflags" chain for dropping incorrect tcp packets
  • an ACCEPT rule for dhcp-specific packets
Policy and rules

/etc/shorewall/policy
#SOURCE         DEST            POLICY          LOG
fw              all             ACCEPT          $LOG
net             all             DROP            $LOG
all             all             REJECT          $LOG
/etc/shorewall/rules
#ACTION   SOURCE            DESTINATION     PROTO        DEST PORT(S)
ACCEPT    net               fw              tcp          80
ACCEPT    net               fw              tcp          443
ACCEPT    net:86.17.10.162  fw              udp
ACCEPT    net:myserver.org  fw              udp          3306
...
Each policy will result in a separate chain, branched off from its source chain, of which the last rule makes sure that the policy is enforced.
  • "fw2all" chain -> last line accepts all outgoing traffic
  • "net2all" chain -> last line drops all incoming traffic
  • "all2all" chain -> last line rejects all traffic
The rules are exceptions to these policies that are set in the first part of these chains. In case the rule contains a combination of source and destination for which no policy exists, a new chain is branched off at the right place.

In this example, the rules will result in a "net2fw" chain (source = net, destination = fw) to be branched off directly from "eth0_in" (= last rule of "eth0_in"). The last rule of "net2fw" will then pass control to the "net2all" chain that enforces the general policy for incoming traffic that doesn't match any of the rules in "net2fw" (see below).

Resulting iptables

Default iptables chains
Chain INPUT (policy DROP)
target     prot opt in   out  source               destination
ACCEPT     0    --  lo   any  anywhere             anywhere
eth0_in    0    --  eth0 any  anywhere             anywhere
...
Before handing control to the "eth0_in" chain, a rule is included to allow all loopback traffic. The rules after "eth0_in" will have no baring on incoming traffic via eth0, since the default policy for the "net" zone is set to DROP; this causes all incoming eth0 traffic that doesn't comply with one of the rules to be dropped at the end of the "net2all" (see below).
Chain FORWARD (policy DROP)
target     prot opt in   out  source               destination
eth0_fwd   0    --  eth0 any  anywhere             anywhere
...
Chain OUTPUT (policy DROP)
target     prot opt in   out   source               destination
ACCEPT     0    --  any  lo    anywhere             anywhere
ACCEPT     udp  --  any  eth0  anywhere             anywhere            udp dpts:bootps:bootpc
fw2all     0    --  any  eth0  anywhere             anywhere            policy match dir out pol none
...
Shorewall chains for incoming traffic
Chain eth0_in (1 references)
target     prot opt source               destination
dynamic    0    --  anywhere             anywhere            state INVALID,NEW
ACCEPT     udp  --  anywhere             anywhere            udp dpts:bootps:bootpc
tcpflags   tcp  --  anywhere             anywhere            policy match dir in pol none
net2fw     0    --  anywhere             anywhere            policy match dir in pol none
The "eth0_in" chain branches off to the "dynamic" (= for dynamic blacklisting) and tcpflags (= drop tcp packet with incorrect combination of flags), before passing control to "net2fw".
Chain net2fw (1 references)
target     prot opt source               destination
ACCEPT     0    --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere            multiport dports ssh,2233
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www
ACCEPT     udp  --  86.17.10.162         anywhere    
ACCEPT     udp  --  myserver.org         anywhere            udp dpt:mysql
...
net2all    0    --  anywhere             anywhere
The "net2fw" chain governs the traffic from the "net" zone to the "fw" zone (= local machine), so this is the chain that contains all the exception rules for your configuration. After the last of these rules, it passes control to the "net2all" chain.
Chain net2all (1 references)
target     prot opt source               destination  
ACCEPT     0    --  anywhere             anywhere            state RELATED,ESTABLISHED
Drop       0    --  anywhere             anywhere     
...
The "net2all" chain makes sure the default policy (DROP) is enforced for all packets that haven't already been accepted.

Comments

Post a Comment

Popular posts from this blog

Handling control characters (escaping) in python for json and mysql

JSON loads() and dumps(): how control characters are handled The json lib escapes control characters when you dump(s) a python object into a json string. import json aa = "String with\ttab and\nnewline" print "1. Py string with control chars, unescaped: '%s'" % aa aa = json.dumps(aa, indent = 2, encoding="utf8") # dumping py-obj into json-string will cause control chars to be escaped print "\n2. JSON Encoded String with control chars, escaped: '%s'" % aa aa = json.loads(aa) # loading json-string into py-obj will leave control chars unescaped print "\n3. Py object (= string) with control chars, unescaped: '%s'" % aa Output: 1. Py string with control chars, unescaped: 'String with tab and newline' 2. JSON Encoded String with control chars, escaped: '"String with\ttab and\nnewline"' 3. Py object (= string) with control chars, unescaped: 'String with tab and newline' Note that json.l...
Read more

python port sniffer with pcapy and impacket

The code below will sniff all network traffic (use a filter to limit the sniffer to only certain packets) during 1000 milliseconds and print some info about it. It requires 2 python modules: pcapy for capturing the packets impacket for analyzing the packet content Note that this sample uses pcapy's dispatch() method and relies on its ability to return automatically after a timeout expires. This functionality is not available on all platforms (e.g. not on linux). import os, logging, socket import pcapy, impacket, impacket.ImpactDecoder ETHERNET_MAX_FRAME_SIZE = 1518 PROMISC_MODE = 0 class Packet(object): def __init__(self, bytes, sniffed_bytes, timestamp, proto_id, src_ip, tgt_ip, src_port, tgt_port, msgs): """ @brief Initialize data. """ super(Packet, self).__init__() self.bytes = bytes self.sniffed_bytes = sniffed_bytes self.src_ip = src_ip self.tgt_ip = tgt_ip self.src_port = src_port self.tgt_port = tgt_port ...
Read more

Django field, form and model validation process

Django's form and field validation process can be best understood by looking at the code in django's BaseForm class (in django.forms.forms) - see below. See also this blog post for a graphic overview. The form.full_clean() method is called by django at the start of the validation process (by form.is_valid(), usually immediately after the view receives the posted data). full_clean() performs a 3 phase validation , with each phase corresponding to a call of one of the protected methods below: self._clean_fields() : Field validation This method iterates over the form fields: For each field, it calls the Widget's value_from_datadict() method, passing the complete post data in a QueryDict. The Widget's task is to retrieve its own value from this QueryDict and return it. The returned value is then passed to the Field's own clean() method. This method does the initial validation (e.g. checking if the value is not empty), without touching the db. If the Field's...
Read more