RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1370963 - RFE: better ingress filtering
Summary: RFE: better ingress filtering
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: firewalld
Version: 7.2
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Eric Garver
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
: 1379109 1440899 (view as bug list)
Depends On:
Blocks: 1420851
TreeView+ depends on / blocked
 
Reported: 2016-08-29 02:02 UTC by Stephen Satchell
Modified: 2021-06-10 11:29 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1492722 (view as bug list)
Environment:
Last Closed: 2018-12-01 14:25:49 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
White paper on firewalld ingress/egress filtering suggestion (54.71 KB, application/pdf)
2016-08-29 02:02 UTC, Stephen Satchell 		no flags Details
Updated proposal white paper (65.22 KB, application/pdf)
2016-08-29 09:46 UTC, Stephen Satchell 		no flags Details
My IPTABLES rules running on CentOS 4 (85.52 KB, text/plain)
2016-08-30 01:38 UTC, Stephen Satchell 		no flags Details
DNS attack mitigation proposal (1.04 KB, text/plain)
2016-08-31 04:18 UTC, Stephen Satchell 		no flags Details
Show Obsolete (1) View All


Links
System ID Private Priority Status Summary Last Updated
CentOS 0011385 0 None None None 2016-08-29 02:02:30 UTC

Description Stephen Satchell 2016-08-29 02:02:31 UTC 
Created attachment 1195119 [details]
White paper on firewalld ingress/egress filtering suggestion

Description of problem:
Firewalld does not allow for the creation of Best Practices filtering

Version-Release number of selected component (if applicable):
0.3.9-14.el1.noarch

How reproducible:
Always

Steps to Reproduce:
1. Use either the CLI or the GUI firewall
2. Try to define any egress filtering, define bogon ingress filtering
3.

Actual results:
No filters available

Expected results:
IPTABLES rules to protect against spoofed source addresses, forwarded packets to inappropriate destinations, protect against broadcast storms

Additional info:
The existing firewalld implementation lacks robust ingress filtering, and any egress filtering capability. This means that you can't implement Internet Best Practices regarding packet filtering (BCP 72) when using CentOS as an Internet edge firewall. The attached PDF describes a proposal for augmenting firewalld in a manner that will make far more robust, avoid sending/receiving nasty packets, and yet not add that much more complexity for the sysadmin.

The proposal is taken from a IPTABLES firewall I've been using for years. Because of the nature of my firewall and service, it's very IPv4 centric.  Similar rules can be created for IPv6.

On request, I can provide the current IPTABLE rules I have defined on the system that protects my home. (Running CentOS 4, which badly needs to be updated to something more current.) A shell script builds it from a configuration file.
Comment 2 Stephen Satchell 2016-08-29 09:46:21 UTC 
Created attachment 1195287 [details]
Updated proposal white paper

Updated proposal, which also touches on issues for systems with more than two interfaces, bound to more than two zones.
Comment 3 Stephen Satchell 2016-08-30 01:38:21 UTC 
Created attachment 1195583 [details]
My IPTABLES rules running on CentOS 4

I've attached a dump of my existing firewall rules that incorporates my proposed ingress and egress filtering.  The generator I wrote includes a lot more, such as blacklisted ports, blacklisted networks, and highly-customized forwarding rules.
Comment 4 Stephen Satchell 2016-08-30 14:04:40 UTC 
In talking to a colleague about my bug submission, she pointed out that in my firewall I treat the local computer as a zone by itself, so that for some services incoming packets on the trusted network are NOT forwarded to the public network, but are only valid on the local computer.  In my white paper, I talk about indirect control of forwarding by not allowing the external zone to inherit certain services, such as DHCP.  My system makes this distinction sharper by not forwarding the DHCP service.  (I fear that any solution to this delta would not be backward-compatible with the existing implementation of firewalld.)
Comment 5 Stephen Satchell 2016-08-31 04:18:26 UTC 
Created attachment 1196161 [details]
DNS attack mitigation proposal

While we are at it, how about some prepackaged DoS migitation filters?  Here's one I cooked up for an ISP who was the intermediary to a DNS amplification attack.  When I applied these filters, their 100 megabit/s upstream was no longer nailed up solid for hours at a time.  (I'm sure that someone can take this and make it better.)
Comment 6 Thomas Woerner 2016-09-30 12:02:34 UTC 
This request was very late for 7.3. I am proposing it for 7.4.
Comment 7 Stephen Satchell 2016-09-30 15:48:30 UTC 
The request was very late because I didn't realize that firewalld wasn't BCP38 compliant until it was time to update my edge router from a Red Hat Enterprise 4 implementation.  The North American Network Operators' Group is very concerned (as am I) that implementation of BCP38 is so limited, less so than IPv6 right now.  So we continue to have DDoS attacks that use reflection (spoofing) and amplification, and Red Hat servers can participate in the fun, even if they don't become botnet victims.

That's why I made it a feature request.

One of the issues with BCP38 is there is very little outside of the RFCs about it, and those RFCs are barely readable if you want to spend a weekend with them and a new legal pad.  http://big38.info is still a work in progress.

Interested in some help?
Comment 9 Thomas Woerner 2017-05-03 16:11:28 UTC 
(In reply to Stephen Satchell from comment #7)
> The request was very late because I didn't realize that firewalld wasn't
> BCP38 compliant until it was time to update my edge router from a Red Hat
> Enterprise 4 implementation.  The North American Network Operators' Group is
> very concerned (as am I) that implementation of BCP38 is so limited, less so
> than IPv6 right now.  So we continue to have DDoS attacks that use
> reflection (spoofing) and amplification, and Red Hat servers can participate
> in the fun, even if they don't become botnet victims.
> 
> That's why I made it a feature request.
> 
> One of the issues with BCP38 is there is very little outside of the RFCs
> about it, and those RFCs are barely readable if you want to spend a weekend
> with them and a new legal pad.  http://big38.info is still a work in
> progress.
> 
> Interested in some help?

Yes, I am interested in help.
Comment 10 Thomas Woerner 2017-05-03 16:22:05 UTC 
There is also an upstream issue about filtering output traffic: https://github.com/t-woerner/firewalld/issues/32
Comment 12 Chris Williams 2017-06-21 19:02:51 UTC 
*** Bug 1379109 has been marked as a duplicate of this bug. ***
Comment 13 Chris Williams 2017-06-21 21:49:14 UTC 
*** Bug 1440899 has been marked as a duplicate of this bug. ***
Comment 17 Eric Garver 2017-09-18 14:25:15 UTC 
I split this bug into two. Using this one for "better ingress filtering" and the clone to implement "egress filtering" (bug 1492722).
Comment 19 Eric Garver 2018-12-01 14:25:49 UTC 
This is an extremely broad RFE and has been open for a long time with no action. I think it's clear no work will be done, as such closing as WONTFIX.

If you'd like to see ingress filtering improvements it would be better to open separate RFEs with smaller work items. If the improvements could be done with existing firewalld primitives then perhaps it would be better to implement a new zone with these filters added by default.
Note You need to log in before you can comment on or make changes to this bug.