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): system-config-securitylevel-tui-1.6.27-1 How reproducible: Always 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 default anyway) 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' Actual results: 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 RH-Firewall-1-INPUT Expected results: Conneection to www.kame.net is established over IPv6 Additional info: 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 established connections. 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 outgoing connections. This seems to have been fixed in RHEL-5 under the bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217514
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.