Bug 221828 - RFE: Make iptables default FORWARD rule REJECT (except for bridging)
RFE: Make iptables default FORWARD rule REJECT (except for bridging)
Product: Fedora
Classification: Fedora
Component: system-config-firewall (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
: FutureFeature, Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-01-08 07:51 EST by Mark McLoughlin
Modified: 2014-03-16 23:36 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-09 14:19:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
system-config-securitylevel-1.6.31-default-forward-rule.patch (734 bytes, patch)
2007-01-08 07:51 EST, Mark McLoughlin
no flags Details | Diff
allow-bridging-by-default.patch (730 bytes, patch)
2007-01-19 08:50 EST, Mark McLoughlin
no flags Details | Diff
system-config-firewall-allow-briding-by-default.patch (803 bytes, patch)
2008-01-03 11:52 EST, Mark McLoughlin
no flags Details | Diff

  None (edit)
Description Mark McLoughlin 2007-01-08 07:51:30 EST
In bug #84975, we made our firewall tool apply its rules to both the INPUT and
FORWARD chains.

The rationale was that if you enable /proc/sys/net/ipv4/ip_forward, then you
should not have a default whereby all traffic is allowed to be forwarded.

However, I don't think our input rules make a good default:

  1) It may be a good default to allow e.g. SSH traffic to be forwarded
     from an "external" interface to an "internal" one but it is not a 
     a good default to *only* allow SSH traffic be forwarded from
     internal to external.

  2) The default creates a confusing situation where some traffic is
     forwarded from internal to external and some isn't. It probably isn't 
     obvious to people that this has anything to do with their firewall

I think a better default would be make REJECT the default rule on the FORWARD
chain. It makes it a lot more explicit to people setting up a gateway that they
need to modify their iptables FORWARD configuration.
Comment 1 Mark McLoughlin 2007-01-08 07:51:30 EST
Created attachment 145049 [details]
Comment 4 Chris Lumens 2007-01-09 11:32:04 EST
Okay, I'm reworking some stuff in s-c-securitylevel right now that makes
applying this patch impossible at the moment but I will apply it before the next
release.  Thanks.
Comment 5 Chris Lumens 2007-01-09 14:19:52 EST
Nevermind, I've changed priorities and can commit this right now.  Thanks for
the patch.
Comment 6 Mark McLoughlin 2007-01-12 13:36:36 EST
So, if you set up a bridge (br0) with two members (eth0 and eth1) you want rules

  -I FORWARD -m physdev --physdev-in eth0 -j ACCEPT
  -I FORWARD -m physdev --physdev-in eth1 -j ACCEPT

We were talking about how e.g. initscripts and xen could make sure that these
rules get added automatically even across iptables restarts or users configuring
the firewall etc.

I suggested having the iptables init script run scripts from
/etc/sysconfig/iptables.d and have initscripts and xen install scripts there.

An example Xen script might be:


[ "$1" = "start" ] || exit 0

if ! grep '^[^#]*(network-script .*network-bridge' $XEND_CONFIG > /dev/null
2>&1; then
    exit 0

bridge=$(awk '/^[^#]*\(network-script.*bridge=/ { print gensub(".*bridge=([^
'"'"']+).*", "\\1", "g") }' < $XEND_CONFIG)

[ "$bridge" ] || bridge="xenbr0"

for i in $(brctl show | awk -v bridge=$bridge \
                            'BEGIN {f=1;b="";} \
                            /^[^[:space:]]/ { if (f==1) {f=0; next;} b=$1; } \
                            { if (b==bridge) { if (NF==4||NF==1) { print $NF
}}}'); do
    iptables -I FORWARD -m physdev --physdev-in $i -j ACCEPT

One reason this sucks is if you e.g. do service iptables save, then you get
multiple copies of these rules.
Comment 7 Mark McLoughlin 2007-01-12 13:42:17 EST
What eventually occurred to me, though, was that although the default rule for
IP forwarding (e.g. in a gateway) should be REJECT, the default rule for
bridging should be ACCEPT.

Who ever heard of a real ethernet bridge where you have to configure a firewall
to  allow frames from individual ports?

If you add a bridge and enslave devices to that bridge, you expect all frames to
be bridged between ports.

So, can we change the default forward rule to:

  -A FORWARD -m physdev ! --physdev-is-bridged -j REJECT --reject-with
Comment 8 Mark McLoughlin 2007-01-19 08:50:34 EST
Created attachment 145980 [details]

Any thoughts on this?
Comment 9 Jeroen van Meeuwen 2007-08-26 05:38:53 EDT
Setting the default rule to REJECT in the FORWARD chain of the filter table this
way is going to break NAT setups unless you also properly specify that NATted
traffic is allowed through the FORWARD chain of the filter table. I suppose you

Check if the incoming interface (lan-side) is trusted, the traffic is accepted
Allow ESTABLISHED,RELATED to pass the FORWARD chain from any incoming interface
towards the outgoing (trusted) interface.
Comment 10 Thomas Woerner 2007-10-04 06:16:02 EDT
system-config-firewall in devel provides the ability to load custom rules.
Please have a look at "lokkit --help". You can add a file with your rules by
using "lokkit --custom-rules=ipv4:filter:/etc/sysconfig/my_rules_file".
lokkit also got an new option "--update" which regenerates the firewall rules
for ipv4 and ipv6. Use this if you are udating custom rules and want that the
changes are persistent.
The enhancements in lokkit does not require a change in the firewall handling
for iptables; it does not know anything about the includes. This solution is
transparent in use especially for updaters.

Please have a look at this solution and report problems if you have any.

Comment 11 Mark McLoughlin 2008-01-03 11:52:07 EST
twoerner: the request is that the default for the forward chain should be that
all IP level forwarding is rejected, but link level bridging should be accepted.

See comment #7
Comment 12 Mark McLoughlin 2008-01-03 11:52:40 EST
Created attachment 290742 [details]
Comment 13 Jon Stanley 2008-04-23 16:28:29 EDT
Adding FutureFeature keyword to RFE's.

Note You need to log in before you can comment on or make changes to this bug.