your approach to complex iptables rulesets

Question

i'm interested how do you write your complex packet-filtering rulesets on linux router acting as firewall. one with default-drop policy.

i usually go with such approach [ just an artificial example ]:

iptables -F ; iptables -X; iptables -P FORWARD DROP
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -N FORWARD_machineA
iptables -A FORWARD_machineA -d $machineA -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD_machineA -d $machineA -s $machineB -p tcp --dport 3306 -j ACCEPT
iptables -A FORWARD_machineA -d $machineA -j DROP
iptables -A FORWARD_machineA -s $machineA -d $machineC -p tcp --dport 2 -j ACCEPT
iptables -A FORWARD_machineA -s $machineA -j REJECT

iptables -N FORWARD_machineB
iptables -A FORWARD_machineB -d $machineB -s $machineA -p tcp --dport 3306 -j ACCEPT
iptables -A FORWARD_machineB -d $machineB -j DROP
iptables -A FORWARD_machineB -s $machineB -d $machineC -p tcp --dport 2 -j ACCEPT
iptables -A FORWARD_machineB -s $machineB -j REJECT

iptables -N FORWARD_machineC
iptables -A FORWARD_machineC -d $machineC -s $machineA -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD_machineC -d $machineC -s $machineB -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD_machineC -d $machineC -j DROP
iptables -A FORWARD_machineC -s $machineC -j REJECT

iptables -A FORWARD -s $machineA -j FORWARD_machineA
iptables -A FORWARD -d $machineA -j FORWARD_machineA

iptables -A FORWARD -s $machineB -j FORWARD_machineB
iptables -A FORWARD -d $machineB -j FORWARD_machineB

iptables -A FORWARD -s $machineC -j FORWARD_machineC
iptables -A FORWARD -d $machineC -j FORWARD_machineC

this works fine, but is far from perfect: for instance if i add two servers in different subnets that need to communicate - rules need to be added both in chains for machineA and machineB.

in this case i'm mostly interested in manageability / readability - so there is no need for special performance optimization [ eg minimising average number of rule-lookups ].

ps: similar question, but that's not answers i'm looking for.

thanks!

Answer 1

You can change

iptables -A FORWARD -s $machineA -j FORWARD_machineA
iptables -A FORWARD -d $machineA -j FORWARD_machineA

to

iptables -A FORWARD -g FORWARD_machineA

that way you can have three rules like this

iptables -A FORWARD -g FORWARD_machineA
iptables -A FORWARD -g FORWARD_machineB
iptables -A FORWARD -g FORWARD_machineC

and after this three rules just put one

iptables -A FORWARD -j REJECT

This way if you allow a communication just once either in chain FORWARD_machineA or chian FORWARD_machineB for communication between machine A and machine B, it might work.

At least it reduces six lines of -j chain to three lines of -g chain. It also removes need of putting -j REJECT at end of each chain. Infact, you must remove -j REJECT from end of each chain to make above method works.

This is the simple improvement that can be generalized based on your example. Other improvements might require more detail on what you want to allow and what you want to block.

Answer 2

You could use pfSense instead. it has many features:

• Firewall

  • Filtering by source and destination IP, IP protocol, source and destination port for TCP and UDP traffic
  • Able to limit simultaneous connections on a per-rule basis
  • pfSense utilizes p0f, an advanced passive OS/network fingerprinting utility to allow you to filter by the Operating System initiating the connection. Want to allow FreeBSD and Linux machines to the Internet, but block Windows machines? pfSense can do so (amongst many other possibilities) by passively detecting the Operating System in use.
  • Option to log or not log traffic matching each rule.
  • Highly flexible policy routing possible by selecting gateway on a per-rule basis (for load balancing, failover, multiple WAN, etc.)
  • Aliases allow grouping and naming of IPs, networks and ports. This helps keep your firewall ruleset clean and easy to understand, especially in environments with multiple public IPs and numerous servers.
  • Transparent layer 2 firewalling capable - can bridge interfaces and filter traffic between them, even allowing for an IP-less firewall (though you probably want an IP for management purposes).
  • Packet normalization - Description from the pf scrub documentation - "'Scrubbing' is the normalization of packets so there are no ambiguities in interpretation by the ultimate destination of the packet. The scrub directive also reassembles fragmented packets, protecting some operating systems from some forms of attack, and drops TCP packets that have invalid flag combinations."
    • Enabled in pfSense by default
    • Can disable if necessary. This option causes problems for some NFS implementations, but is safe and should be left enabled on most installations.
  • Disable filter - you can turn off the firewall filter entirely if you wish to turn pfSense into a pure router.
    
    
• Network Address Translation (NAT)
• Redundancy
• Load Balancing Reporting and Monitoring

• RRD Graphs

  The RRD graphs in pfSense maintain historical information on the following.

  • CPU utilization
  • Total throughput
  • Firewall states
  • Individual throughput for all interfaces
  • Packets per second rates for all interfaces
  • WAN interface gateway(s) ping response times
  • Traffic shaper queues on systems with traffic shaping enable
• VPN
  • IPsec
  • PPTP
  • OpenVPN

• Dynamic DNS

  Through:

  • DynDNS
  • DHS
  • DyNS
  • easyDNS
  • No-IP
  • ODS.org
  • ZoneEdit
• Captive Portal
• DHCP Server and Relay

It has a nice, easy to use web-based configuration, just look at the screen-shots.

Best of all you can build it yourself with commodity hardware, and it's Open Source.