3

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!

Community
  • 1
pQd
  • 29,981
  • 6
  • 66
  • 109
  • It might help to know why you need the rules set up like they are. – Brad Gilbert Jul 19 '09 at 19:14
  • Hmm, increased complexity is probably not what you want. More rules = more processing = slower network. Is there anyway you can reduce the rule set? Maintaining complex firewall rules is a pain, and if you make an error, well we all know what can happen. – The Unix Janitor Mar 20 '10 at 15:08
  • @user37899 well - in that case i can afford losing performance. – pQd Mar 20 '10 at 16:19

2 Answers2

3

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.

Saurabh Barjatiya
  • 4,703
  • 2
  • 30
  • 34
  • thanks, but notice that i distinguish between DROP and REJECT. also this will make it slightly harder to determine what traffic exactly can reach hostX since you have to check FORWARD_machineX and all previous.. – pQd Jul 18 '09 at 18:49
  • You still put DROP rules in individual chains and just put one reject at the end. From my usage point of view your rules are more complicated because if I want to analyze packet from machine a to machine b I have to be careful that rules in chain a will get applied and rules in chain b wont. Having all chains scanned gives me flexibility of putting rules from A to B in any chain and they would get called. It is matter of opinion which is easier. If you are really looking for fine grained control then I do not think there is more simplification possible using only FORWARD table of filter table. – Saurabh Barjatiya Jul 18 '09 at 19:10
  • Try using FORWARD table of nat or mangle tables as well. That way you can split the rules in three tables. Again opinion will differ which is more easy to handle one long table or three different short FORWARD tables. – Saurabh Barjatiya Jul 18 '09 at 19:11
0

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.

Brad Gilbert
  • 2,503
  • 2
  • 21
  • 19
  • thanks, but at least for now i prefer to stick to well-known grounds: netfilter / iproute2 – pQd Jul 19 '09 at 18:21
  • You may still want to look at the screen shots, if for nothing else than to compare to other options. – Brad Gilbert Jul 19 '09 at 19:12
  • @Brad: actually i did after reading your post. to answer your question - i'd like to have rules as readable as possible [ so i can easily tell which host can talk to which without trial&error. preferably firewall script with comments should be readable as traffic filtering policy ]. to tell more about deployment: edge router, multiple vlans - dozens subnets + some vpns. – pQd Jul 19 '09 at 19:35