Bug 214117

Summary: ipv6 firewall does not allow tcp sessions
Product: [Fedora] Fedora Reporter: Serge Droz <serge>
Component: system-config-securitylevelAssignee: Thomas Woerner <twoerner>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 6CC: cra, dboyter, eric-bugs, jean-luc.richier, pb, redhat-bugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-09-21 09:06:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch to correct ip6table configurator none

Description Serge Droz 2006-11-05 20:48:45 UTC
Description of problem:
The ip6tables firewall misses a line to allow packets from established
connections back.

This is noted by visiting a ipv6 aware webserver.

Solution: 
Add the line 

-A RH-Firewall-1-INPUT -p tcp ! --syn -j ACCEPT

to /etc/sysconfig/ip6tables

Note: -m state ... does not seem to work with ipv6

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Jean-Luc Richier 2006-12-13 18:47:31 UTC
The bug is in the lokkit program, and caused by the fact that iptables and
ip6tables are different (as CONNTRACK in IPv6 is experimental, we can't keep states)
So the solution is as proposed to allow all tcp outgoing connexions (using
!--syn) but also to suppress the check on sport. Cf the attached patch for lokkit.c
There is also an other bug in lokkit: if you desactivate the firewall, the ipv6
tables are not flushed, some the firewall problem stays till next boot.

Attached : the needed lookit.c patch

Comment 2 Jean-Luc Richier 2006-12-13 18:49:13 UTC
Created attachment 143543 [details]
patch to correct ip6table configurator

Comment 3 Serge Droz 2006-12-13 20:20:47 UTC
I did apply the patch and things seem to work fine now. Thanks a lot.
I'd consider this bug fixed. 

As to IPv6 and CONNTRACK: The real problem is than enabling conntrack for ipv6
throws NAT/PAT for IPv4 over board. And that's often needed in a home setting,
especially if you have a firewall and tunnel IPv6 through the (nated) IPv4 session.
But that fix takes a lot of work ...




Comment 4 Chuck Ebbert 2007-02-05 20:13:44 UTC
*** Bug 222446 has been marked as a duplicate of this bug. ***

Comment 5 Peter Bieringer 2007-02-28 20:43:18 UTC
This bug hits me also now.

BTW: the generated rules are also IMHO sometimes too simple and can be improved
a lot. But such problem is not new and therefore I've created some time ago a
bash library named "firewall-lib" which does some abstraction right now (e.g.
transparent generation of rules for IPv4 and IPv6!).

See current package for more, if interested:
ftp://ftp.aerasec.de/pub/linux/repository/public/redhat/enterprise/4/i386/ip-firewalling-0.1.3-1.RHEL4.AERAsec.1.noarch.rpm

It's sure just another iptables rule generator framework...



Comment 6 Peter Bieringer 2007-03-18 14:42:46 UTC
It looks like that at least the new kernel 2.6.20-1.2925.fc6 supports proper
working IPv6 connection tracking (waiting for long time...).

I've proper adjusted now the firewall ruleset to:

# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmpv6 -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d ff02::fb -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp6-adm-prohibited
COMMIT

And it's working:
# ip6tables -vnL RH-Firewall-1-INPUT
Chain RH-Firewall-1-INPUT (2 references)
 pkts bytes target     prot opt in     out     source               destination
        
    0     0 ACCEPT     all      lo     *       ::/0                 ::/0       
       
    3   240 ACCEPT     icmpv6    *      *       ::/0                 ::/0      
        
    0     0 ACCEPT     esp      *      *       ::/0                 ::/0       
       
    0     0 ACCEPT     ah       *      *       ::/0                 ::/0       
       
    0     0 ACCEPT     udp      *      *       ::/0                 ff02::fb/128
      udp dpt:5353 
    0     0 ACCEPT     udp      *      *       ::/0                 ::/0       
       udp dpt:631 
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0       
       tcp dpt:631 
   47 29289 ACCEPT     all      *      *       ::/0                 ::/0       
       state RELATED,ESTABLISHED 
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0       
       state NEW tcp dpt:22 
    0     0 REJECT     all      *      *       ::/0                 ::/0       
       reject-with icmp6-adm-prohibited 


Note that I've fixed also the ICMPv6 error message and sync it to the one
defined in IPv4:
Old: icmp6-port-unreachable
New: icmp6-adm-prohibited


Comment 7 Peter Bieringer 2007-07-16 09:55:49 UTC
current version of system-config-securitylevel-tui (1.7.0-1.fc7) still produces
an improper set of IPv6 rules:

# ip6tables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
        
  312 87944 RH-Firewall-1-INPUT  0        *      *       ::/0                
::/0               

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
        
    0     0 REJECT     0        *      *       ::/0                 ::/0       
       reject-with icmp6-port-unreachable 

Chain OUTPUT (policy ACCEPT 264 packets, 24180 bytes)
 pkts bytes target     prot opt in     out     source               destination
        

Chain RH-Firewall-1-INPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination
        
    0     0 ACCEPT     0        lo     *       ::/0                 ::/0       
       
  117 11136 ACCEPT     icmpv6    *      *       ::/0                 ::/0      
        
    0     0 ACCEPT     esp      *      *       ::/0                 ::/0       
       
    0     0 ACCEPT     ah       *      *       ::/0                 ::/0       
       
    0     0 ACCEPT     udp      *      *       ::/0                 ff02::fb/128
      udp dpt:5353 
    0     0 ACCEPT     udp      *      *       ::/0                 ::/0       
       udp dpt:631 
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0       
       tcp dpt:631 
    0     0 ACCEPT     udp      *      *       ::/0                 ::/0       
       udp dpts:32768:61000 
  195 76808 ACCEPT     tcp      *      *       ::/0                 ::/0       
       tcp dpts:32768:61000 
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0       
       tcp dpt:22 
    0     0 REJECT     0        *      *       ::/0                 ::/0       
       reject-with icmp6-port-unreachable 


This one is very insecure, possible to access part of high ports:

  195 76808 ACCEPT     tcp      *      *       ::/0                 ::/0       
       tcp dpts:32768:61000 

Suggestion:
 - add ! --syn (FC6 with older kernels)
 - use connection tracking, if available (F7, FC6 with newer kernels)

See also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244729

BTW: component should be changed to system-config-securitylevel (which contains
"lokkit", which is responsible for the improper rule generation).

Comment 8 Thomas Woerner 2007-08-02 09:13:06 UTC
Assigning to system-cconfig-securitylevel

Comment 9 Thomas Woerner 2007-09-21 09:06:58 UTC
Fixe din updates in package system-config-securitylevel-1.6.27-2.