Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 87585 - RH firewall tools should use stateful tracking
Summary: RH firewall tools should use stateful tracking
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gnome-lokkit
Version: 9
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks: CambridgeBlocker
TreeView+ depends on / blocked
 
Reported: 2003-03-29 09:06 UTC by Dax Kelson
Modified: 2014-03-17 02:35 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-08-04 21:05:05 UTC
Embargoed:


Attachments (Terms of Use)
Patch to src/writer-linux-iptables.c to use stateful rules (deleted)
2003-08-01 21:13 UTC, Dax Kelson
no flags Details | Diff
Patch to /etc/sysconfig/network-scripts/ifup-post (deleted)
2003-08-01 21:53 UTC, Dax Kelson
no flags Details | Diff
Patch to /sbin/ifup -- no need to mess with FW rules with stateful lokkit (deleted)
2003-08-01 21:58 UTC, Dax Kelson
no flags Details | Diff

Description Dax Kelson 2003-03-29 09:06:48 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
RHL 8.0 and 9 now use iptables with the firewall built by anaconda or
redhat-config-securitylevel or lokkit.

The rules produced by the above are basic in nature and cause real world
problems. The problems are documented in the installer and in the Red Hat Linux
x86 Installation Guide chapter 3.

The main issue is that although announced purpose of the High and Medium
firewalls are tasked to filter connections accepted by your host's daemons (ie,
incoming connections), because of the rule implementation, many fundamental
outbound client connections are blocked as well.

The default Medium firewall makes your system unusable as a NFS, NIS, and LDAP
client. This blocking of outbound client connections is NOT a feature, but a
bug. Fortunately, it is easily solved.

The current rules are simply a straight port from the stateless IP Chains rules
previously used in RHL7.1 to 7.3.  This is the heart of the problem.

The whole idea of High and Medium are a 'hack/workaround' because of the
stateless rules currently being created.  With stateful firewalling you either
have a firewall or you don't. The firewall allows inbound connections TO
specific daemons chosen by the sys admin.

The anaconda/lokkit/redhat-config-securitylevel firewall should use the stateful
abilities in IP Tables.

I would start the firewall with these simple rules:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j REJECT

With these 3 rules, NO externally initiated connections connections are allowed
TO the host.  However, ALL locally initiated connections will automatically work
fine. Of course "ALL" includes RPC, NFS, NIS and LDAP that are broken with
current non-stateful rules.  

Also, with these three rules all the current special cases that are allowed such
as DNS, DHCP and NTP will just automatically work.

If a user chooses a 'trusted' interface, then BEFORE the REJECT line, add the rule:

-A INPUT -m state --state NEW -i ethXYZ -j ACCEPT

If the user chooses 'allow incoming' service such as SMTP and HTTP, then add
rule for each before the REJECT line:

-A INPUT -m state --state NEW -p tcp --dport 25 -j ACCEPT
-A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT

As you can see, with stateful firewalling, the whole concept of High versus
Medium just goes away, it's just 'proper' firewalling.

BTW, there are larger issues that need thought here. Currently there is
ambiguity this firewalling code is trying to accomplish and the low level
details. For example:


1. The distinction between a "connection/conversation" initiated TO the host
versus FROM the host. My personal preference would be to ALLOW any
connections/conversations initiated BY the host.

2. Firewall design is quite different for rules meant to be on a single host
firewalling itself, versus a multi-network interface router+firewall with
clients behind it, an outside interface and zero or more DMZ interfaces.

Now, if you have a DMZ interface with a server(s) in the DMZ, I would have the
firewall only allow the DMZ server to initiate connection to defined services on
defined hosts (NTP, DNS, RHN, etc).  Allow external clients to initiate
connections to the daemons on the DMZ servers that are meant to be externally
accessible.  Allow all ESTABLISHED and RELATED packets and then REJECT
everything else. With such a setup, if a server gets compromised via a worm, it
CAN NOT spread the worm to other internet hosts. If everyone used such rules,
when firewalling their internet servers, there would be NO worms.

An example of some DMZ rules, would to create two rules in the FORWARD chain
that catch traffic going to and from a given DMZ and have it jump to a user
defined chain for that DMZ. In that userdefined chain, have stateful rules, for
example:

-A WWW-DMZ-INET -m state --state ESTABLISHED,RELATED -j ACCEPT
-A WWW-DMZ-INET -m state --state NEW -i eth0 -p tcp -d 10.2.0.80/32 --dport 80
-j ACCEPT # Apache
-A WWW-DMZ-INET -m state --state NEW -i eth0 -p tcp -d 10.2.0.80/32 --dport 443
-j ACCEPT # Apache SSL
-A WWW-DMZ-INET -m state --state NEW -o eth0 -p tcp -d 216.148.218.0/24 -j
ACCEPT # RHN up2date
-A WWW-DMZ-INET -m state --state NEW -o eth0 -p tcp -d 66.187.232.0/24 -j ACCEPT
# RHN up2date
-A WWW-DMZ-INET -j REJECT

If Red Hat made a GUI this rule creation easy, it would be a nice feature to
brag about.  The Internet Worm Killer (tm). :)

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


How reproducible:
Always

Steps to Reproduce:
1. Install RHL 8.0 or 9
2. Use default firewall settings
3. Watch NFS break
    

Actual Results:  n/a

Expected Results:  n/a

Additional info:

n/a

Comment 1 Brent Fox 2003-04-03 20:34:12 UTC
redhat-config-securitylevel calls lokkit to actually set the rules.  Changing
component to gnome-lokkit.



Comment 2 Dax Kelson 2003-08-01 21:11:05 UTC
I'm attaching a new  patch implements a stateful rule set.

The UI should be updated slightly, BUT it works right NOW with the
existing UI (ie, there is no difference between medium and high).

This SIMPLIFIES RHL quite a bit:

ifup-post no longer needs to "punch holes"
FIREWALLS_MODS in /etc/sysconfig files can be ditched
RPC apps ala NIS/NFS "just work"
Connections initiated by self "just work"

I teach 2 or 3 Red Hat Linux classes each month and you would not believe the
carnage that results from the current "default" medium that stops NFS and NIS
from working.

TODO:

Change UI from: High/Medium/Off to On/Off
Update anaconda
Update initscripts

Comment 3 Dax Kelson 2003-08-01 21:13:08 UTC
Created attachment 93344 [details]
Patch to src/writer-linux-iptables.c to use stateful rules

I used rpmbuild -bc from gnome-lokkit-0.50-22.src.rpm to create a tree to patch
against.

Comment 4 Dax Kelson 2003-08-01 21:17:43 UTC
Note on what the new rules accomplish:

1) Gives better security than "HIGH" before
2) No breakage on connections *initiated* by host

(ie, all connections initated by host "just work" now)

Comment 5 Dax Kelson 2003-08-01 21:53:38 UTC
Created attachment 93348 [details]
Patch to /etc/sysconfig/network-scripts/ifup-post

ifup-post no longer needs to mess with the firewall

Comment 6 Dax Kelson 2003-08-01 21:58:12 UTC
Created attachment 93349 [details]
Patch to /sbin/ifup -- no need to mess with FW rules with stateful lokkit

Comment 7 Bill Nottingham 2003-08-04 16:07:09 UTC
Note the initscripts bits have to stay; migrating FW configs on upgrades is a
risky business.

Comment 8 Bill Nottingham 2003-08-04 21:05:05 UTC
Fixed in redhat-config-securitylevel-1.2.0-1.


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