Hi all,
I just installed Fedora 20 on my desktop and I'm playing with firewalld for the first time. I read the docs and with the new rich-rules I think I'm a happy camper so far. I have some questions & observations:
# firewall-config (GUI app)
I opened a bugzilla because every time you start the app it starts maximized:
https://bugzilla.redhat.com/show_bug.cgi?id=1046811
# Target for a Zone
When using firewall-config and you switch to permanent configuration, in order to edit one of the zone properties, there's a Target drop-down list there. When I changed ACCEPT to DROP for the public zone (my default) I noticed only the FORWARD chain was changed. I did an "iptables -L -n -v" in order to confirm this. The actual chain affected is FWDI_public (where the last REJECT rule is replaced by a DROP). Shouldn't the IN_public (for public zone) have a DROP statement as well? Since it doesn't have it, a REJECT from the default INPUT chain is what gets applied. Is this a bug?
Also, when I do this I loose all my connections (can't browse the web, anything..). I have dissected the resulting iptable rules and I only see the change in the FWDI_public chain. Nothing else. I can't find the culprit. I have to change the target back to ALLOW for things to get normal again.
In a nutshell, I would like all packets to be dropped for all services that are not allowed. How can I do this via firewall-cmd/firewall-config? I know there's a drop zone but still would like to learn how to change the default target for a given zone.
# Immutable
What does it mean for a zone to be immutable? Is it that, once loaded, you can't change it? (add/remove rules)? When I change my default zone to the drop zone, I still can add/remove services from it.
# Best Practices
If I'm going to add/remove services for a given zone, is it better to just clone one zone and have one of my own? Should I leave all the stock zones as they are?
Thanks in advance.
Best regards, Jorge
On 12/29/2013 07:28 PM, Jorge Fábregas wrote:
Hi all,
I just installed Fedora 20 on my desktop and I'm playing with firewalld for the first time. I read the docs and with the new rich-rules I think I'm a happy camper so far. I have some questions & observations:
# firewall-config (GUI app)
I opened a bugzilla because every time you start the app it starts maximized:
https://bugzilla.redhat.com/show_bug.cgi?id=1046811
# Target for a Zone
When using firewall-config and you switch to permanent configuration, in order to edit one of the zone properties, there's a Target drop-down list there. When I changed ACCEPT to DROP for the public zone (my default) I noticed only the FORWARD chain was changed. I did an "iptables -L -n -v" in order to confirm this. The actual chain affected is FWDI_public (where the last REJECT rule is replaced by a DROP). Shouldn't the IN_public (for public zone) have a DROP statement as well? Since it doesn't have it, a REJECT from the default INPUT chain is what gets applied. Is this a bug?
Also, when I do this I loose all my connections (can't browse the web, anything..). I have dissected the resulting iptable rules and I only see the change in the FWDI_public chain. Nothing else. I can't find the culprit. I have to change the target back to ALLOW for things to get normal again.
In a nutshell, I would like all packets to be dropped for all services that are not allowed. How can I do this via firewall-cmd/firewall-config? I know there's a drop zone but still would like to learn how to change the default target for a given zone.
This is a bug while loading a customized zone where the target is not identical to the original. The resulting rules are partly still from the original zone with the default zone target in your case. I am working on this.
# Immutable
What does it mean for a zone to be immutable? Is it that, once loaded, you can't change it? (add/remove rules)? When I change my default zone to the drop zone, I still can add/remove services from it.
Immutable is deprecated and does not have an effect anymore. It was used in the past to have zones that can not get modified by the user/admin (was used for block, drop and trusted).
# Best Practices
If I'm going to add/remove services for a given zone, is it better to just clone one zone and have one of my own? Should I leave all the stock zones as they are?
You can always modify zones (since we do not have iummutable anymore). Also it is always possible to load the defaults of a zone again ("Load Zone Defaults").
Thanks in advance.
Best regards, Jorge
firewalld-users mailing list firewalld-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/firewalld-users
Regards, Thomas
On 01/08/2014 01:25 PM, Thomas Woerner wrote:
On 12/29/2013 07:28 PM, Jorge Fábregas wrote:
Hi all,
I just installed Fedora 20 on my desktop and I'm playing with firewalld for the first time. I read the docs and with the new rich-rules I think I'm a happy camper so far. I have some questions & observations:
# firewall-config (GUI app)
I opened a bugzilla because every time you start the app it starts maximized:
https://bugzilla.redhat.com/show_bug.cgi?id=1046811
# Target for a Zone
When using firewall-config and you switch to permanent configuration, in order to edit one of the zone properties, there's a Target drop-down list there. When I changed ACCEPT to DROP for the public zone (my default) I noticed only the FORWARD chain was changed. I did an "iptables -L -n -v" in order to confirm this. The actual chain affected is FWDI_public (where the last REJECT rule is replaced by a DROP). Shouldn't the IN_public (for public zone) have a DROP statement as well? Since it doesn't have it, a REJECT from the default INPUT chain is what gets applied. Is this a bug?
Also, when I do this I loose all my connections (can't browse the web, anything..). I have dissected the resulting iptable rules and I only see the change in the FWDI_public chain. Nothing else. I can't find the culprit. I have to change the target back to ALLOW for things to get normal again.
In a nutshell, I would like all packets to be dropped for all services that are not allowed. How can I do this via firewall-cmd/firewall-config? I know there's a drop zone but still would like to learn how to change the default target for a given zone.
This is a bug while loading a customized zone where the target is not identical to the original. The resulting rules are partly still from the original zone with the default zone target in your case. I am working on this.
This has been fixed with firewalld-0.3.9.
Additionally zones are now only created in kernel space when they are used for the first time.
# Immutable
What does it mean for a zone to be immutable? Is it that, once loaded, you can't change it? (add/remove rules)? When I change my default zone to the drop zone, I still can add/remove services from it.
Immutable is deprecated and does not have an effect anymore. It was used in the past to have zones that can not get modified by the user/admin (was used for block, drop and trusted).
# Best Practices
If I'm going to add/remove services for a given zone, is it better to just clone one zone and have one of my own? Should I leave all the stock zones as they are?
You can always modify zones (since we do not have iummutable anymore). Also it is always possible to load the defaults of a zone again ("Load Zone Defaults").
Thanks in advance.
Best regards, Jorge
firewalld-users mailing list firewalld-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/firewalld-users
Regards, Thomas
On 01/10/2014 12:33 PM, Jiri Popelka wrote:
Where do you actually see it ? I've thought we removed all the visible references to it.
I saw it here:
https://fedoraproject.org/wiki/FirewallD
That's where I first found out about them :)
On 01/11/2014 12:42 AM, Jorge Fábregas wrote:
On 01/10/2014 12:33 PM, Jiri Popelka wrote:
Where do you actually see it ? I've thought we removed all the visible references to it.
I saw it here:
Removed, thanks.
-- Jiri
On 01/14/2014 12:15 PM, Jiri Popelka wrote:
Removed, thanks.
There are also references to "immutable" zones in the RHEL 7 Beta Security Guide:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/...
Regards, Jorge
firewalld-users@lists.stg.fedorahosted.org