Bug 1370963
| Summary: | RFE: better ingress filtering | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Stephen Satchell <redhat> | ||||||||||
| Component: | firewalld | Assignee: | Eric Garver <egarver> | ||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-daemons | ||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | medium | ||||||||||||
| Version: | 7.2 | CC: | anrussel, atragler, cww, egarver, haskett.5, herrold, ptalbert, rkhan, sferguso, sukulkar, todoleza | ||||||||||
| Target Milestone: | rc | Keywords: | FutureFeature | ||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | |||||||||||||
| : | 1492722 (view as bug list) | Environment: | |||||||||||
| Last Closed: | 2018-12-01 14:25:49 UTC | Type: | Bug | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Bug Depends On: | |||||||||||||
| Bug Blocks: | 1420851 | ||||||||||||
| Attachments: |
|
||||||||||||
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.
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.
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.) 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.)
This request was very late for 7.3. I am proposing it for 7.4. 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? (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. There is also an upstream issue about filtering output traffic: https://github.com/t-woerner/firewalld/issues/32 *** Bug 1379109 has been marked as a duplicate of this bug. *** *** Bug 1440899 has been marked as a duplicate of this bug. *** I split this bug into two. Using this one for "better ingress filtering" and the clone to implement "egress filtering" (bug 1492722). 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. |
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.