Description of problem:
The ip6tables/iptables rules added by system-config-securitylevel-tui have a
default policy of ACCEPT for the OUTPUT chain. This is obviously intended to
allow establishment of outgoing connections. The rules added to the INPUT chain
for iptables incoming a match on 'state RELATED,ESTABLISHED' to allow return
traffic from outbound connections. THe ip6tables rules have no such match. The
result is that although the OUTPUT chain allows the SYN packet to go out to the
remote site, the return packets are always blocked. So with the default
ip6tables ruleset it is impossible to view any websites over IPv6
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Config the host with a global IPv6 address
2. Run 'system-config-securitylevel-tui'
3. Select customize
4. For 'Allow incoming' ensure HTTP checkbox is *unselected* (this should be
5. Press OK
6. Press OK again
7. Run 'host -t aaaa www.kame.net' and make a note of the IPv6 address
8. Run 'telnet [IPv6 address from step 7] http'
The telnet sesion hangs & times out. Looking at the output of 'ip6tables -L -n
-v' will show increated packet count against the final REJECT rule in
Conneection to www.kame.net is established over IPv6
For ipv4 the iptables rules make use of the conntrack module to add a match on
state = RELATED,ESTABLISHED. This does not appear to be available for IPv6 - and
the source code to system-config-securitylevel-tui has the rule matching state =
RELATED,ESTABLISHED commented out, with not replacement rule to match
Looking at the ip6tables man pages the closest equivalent rule for IPv6 is to
allow any traffic on the INPUT rule which is *not* a SYN packet. eg something like
ip6tables -I RH-Firewall-INPUT-1 1 -p tcp ! --syn -j ACCEPT
According to the changelogs this issue was fixed in
system-config-securitylevel-tui-1.6.27-1, however, doing a diff between 1.6.26 &
1.6.26 shows that the change merely removed all the conntrack state matching
parameters to the ip6tables due to broken kernel support. For some reason, in
their place was added rules matching on --sport. So if you enable port '22' to
provide an SSH server, then not only does it open up --dport 22, but it also
adds a --sport 22 match. This is a huge security hole, because a malicious
program on a remote machine can trivially bind to port 22 and then make an
outgoing connection to the Fedora server, and thanks to the --sport 22 match
will effectively bypass all the firewall rules. This also did nothing to fix the
This seems to have been fixed in RHEL-5 under the bug
system-config-securitylevel-1.7.0-3.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
The "accept from any source port" security hole (and a big one it is too!) is
still present in FC6 (also see bug 236035, ignored for 3 months! I guess none of
the security team use IPv6?!?)
system-config-securitylevel-1.7.0-3.fc7 seems to remove the hole for F7 - please
could an update be pushed out for FC6, which is still vulnerable?
Meanwhile, ipv6 connection tracking became available in 2.6.21, so there would
seem to be no reason not to use it in F7. See bug 244729.
Fixed in updates in package system-config-securitylevel-1.6.27-2.