Re: firewalld / iptables.service past F17
I've updated the feature page. -- Jiri On 04/30/2012 10:24 PM, Kévin Raymond wrote: Does that imply that new installs will be easily switched from firewalld to static iptables? I always do new install but I want to keep my firewall static, with my current iptables script. Once we actually go to firewalld by default, then yes, at least as long as lokkit and s-c-f are maintained. The procedure is, more or less: systemctl disable firewalld.service systemctl stop firewalld.service systemctl enable iptables.service systemctl start iptables.service lokkit --enabled Hi, from last week FESCo meeting, firewalld has been marked as postponned to F18. If so, could you please update the wiki page? http://fedoraproject.org/wiki/Features/firewalld-default In the docs team, we assume that firewalld is still the default in the Release Notes… Cheers, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
On Thu, 2012-04-26 at 11:22 +0200, Reindl Harald wrote: Am 26.04.2012 11:18, schrieb Adam Williamson: Does that imply that new installs will be easily switched from firewalld to static iptables? I always do new install but I want to keep my firewall static, with my current iptables script. Once we actually go to firewalld by default, then yes, at least as long as lokkit and s-c-f are maintained the machines where iptables.service is needed do not have any GUI installed and so system-config-firewall does not matter There's a TUI version of it too, still. the really important things are only iptables.service and /etc/sysconfig/iptables-config, the rest is done with shellscripts Yeah, you can always do it that way too. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
Does that imply that new installs will be easily switched from firewalld to static iptables? I always do new install but I want to keep my firewall static, with my current iptables script. Once we actually go to firewalld by default, then yes, at least as long as lokkit and s-c-f are maintained. The procedure is, more or less: systemctl disable firewalld.service systemctl stop firewalld.service systemctl enable iptables.service systemctl start iptables.service lokkit --enabled Hi, from last week FESCo meeting, firewalld has been marked as postponned to F18. If so, could you please update the wiki page? http://fedoraproject.org/wiki/Features/firewalld-default In the docs team, we assume that firewalld is still the default in the Release Notes… Cheers, -- Kévin Raymond (Shaiton) pgpcQ5C0fraId.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
Is anyone else seeing on F17 TC1 startup a systemd message that iptables failed? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
On Wed, 2012-04-25 at 17:27 -0600, Dariusz J. Garbowski wrote: On 25/04/12 10:55 AM, Adam Williamson wrote: On Tue, 2012-04-24 at 09:30 -0500, Jon Ciesla wrote: Nothing is being taken away, the default is being changed. If you're using Fedora in production, I presume you're installing with Kickstart. It's worth noting that if the question is how does firewalld handle upgrades, I think it may be somewhat irrelevant because AFAIK even when firewalld was going to be the F17 default, we never implemented anything to cause upgraded systems to switch to it. It was only new installs which were getting firewalld. Upgraded ones stuck with the static iptables/s-c-f/lokkit system. Does that imply that new installs will be easily switched from firewalld to static iptables? I always do new install but I want to keep my firewall static, with my current iptables script. Once we actually go to firewalld by default, then yes, at least as long as lokkit and s-c-f are maintained. The procedure is, more or less: systemctl disable firewalld.service systemctl stop firewalld.service systemctl enable iptables.service systemctl start iptables.service lokkit --enabled -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
Am 26.04.2012 11:18, schrieb Adam Williamson: Does that imply that new installs will be easily switched from firewalld to static iptables? I always do new install but I want to keep my firewall static, with my current iptables script. Once we actually go to firewalld by default, then yes, at least as long as lokkit and s-c-f are maintained the machines where iptables.service is needed do not have any GUI installed and so system-config-firewall does not matter the really important things are only iptables.service and /etc/sysconfig/iptables-config, the rest is done with shellscripts signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
On 26/04/12 03:18 AM, Adam Williamson wrote: On Wed, 2012-04-25 at 17:27 -0600, Dariusz J. Garbowski wrote: Does that imply that new installs will be easily switched from firewalld to static iptables? I always do new install but I want to keep my firewall static, with my current iptables script. Once we actually go to firewalld by default, then yes, at least as long as lokkit and s-c-f are maintained. The procedure is, more or less: systemctl disable firewalld.service systemctl stop firewalld.service systemctl enable iptables.service systemctl start iptables.service lokkit --enabled Thumbs up for this. Please keep it in working condition! Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
On Tue, 2012-04-24 at 09:30 -0500, Jon Ciesla wrote: Nothing is being taken away, the default is being changed. If you're using Fedora in production, I presume you're installing with Kickstart. It's worth noting that if the question is how does firewalld handle upgrades, I think it may be somewhat irrelevant because AFAIK even when firewalld was going to be the F17 default, we never implemented anything to cause upgraded systems to switch to it. It was only new installs which were getting firewalld. Upgraded ones stuck with the static iptables/s-c-f/lokkit system. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
On 25/04/12 10:55 AM, Adam Williamson wrote: On Tue, 2012-04-24 at 09:30 -0500, Jon Ciesla wrote: Nothing is being taken away, the default is being changed. If you're using Fedora in production, I presume you're installing with Kickstart. It's worth noting that if the question is how does firewalld handle upgrades, I think it may be somewhat irrelevant because AFAIK even when firewalld was going to be the F17 default, we never implemented anything to cause upgraded systems to switch to it. It was only new installs which were getting firewalld. Upgraded ones stuck with the static iptables/s-c-f/lokkit system. Does that imply that new installs will be easily switched from firewalld to static iptables? I always do new install but I want to keep my firewall static, with my current iptables script. Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
Am 24.04.2012 02:08, schrieb Oron Peled: Looks like this transition (as is currently planned) is going to break many setups. I want to show the three following use-cases which may be severely broken by this transition. exactly this is the problem i have attached my ip-tables script making at home a software-router with forwarding of two different networks from my LAN via openvpn and a static route i only stripped the config-block and comments but as you can see there are many useful decisions by $HOSTNAME and this is only one of my scripts for two machines __- another one is built the same way and serves 20 machines while partly rules are for all machines, others depeding as in my example on the hostname and there are a lot of really useful and well thought specific drop/forward/reject rules based on hostname and source/destination networks this script has about 50 KB and a handful of bash-includes well, one may say unmaintainable - but it is, it has a good documentation and structure and we are using it as reference for each iptables.sh needed where ever it is practically impossible to convert this stuff because nobody did write it down in one day, it is grown and maintained over years with the whole infrastructure - yes you MAYBE CAN try to re-implement all this rules in firewalld but would you do this really in a production environment in a security layer and how do you test from scratch? please do not come now why fedora in prodction because it just works if things are not careless removed from the distribution - so please do not take away power featureswhich are not really hurt to maintain firewalld is at least another interface for netfilter why want anybody take away perfectly working ones? #! /bin/bash strippd block with var-definitions if [ $HOSTNAME == $HOSTNAME_HOME ]; then PUBLIC_PORTS=21,80,,$SSH_PORT LAN_PORTS=25 143 443 465 587 993 $VMWARE_PORTS 2000 $RDP_PORTS $SMB_PORTS $AVAHI_PORT else PUBLIC_PORTS=80,$SSH_PORT LAN_PORTS=25 143 443 465 587 993 2000 $SMB_PORTS $AVAHI_PORT fi $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -F $IPTABLES -X CHAINS=`cat /proc/net/ip_tables_names 2/dev/null` for i in $CHAINS; do $IPTABLES -t $i -F; done echo Flush OK || echo Flush FAILED for i in $CHAINS; do $IPTABLES -t $i -X; done echo Clear OK || echo Clear FAILED for i in $CHAINS; do $IPTABLES -t $i -Z; done $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -A INPUT ! -i lo -m state --state INVALID -j DROP $IPTABLES -A INPUT ! -i lo -p tcp -m state --state NEW --dport 0 -j DROP $IPTABLES -A INPUT ! -i lo -p udp -m state --state NEW --dport 0 -j DROP $IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP $IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ALL FIN -j DROP $IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP $IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ALL ALL -j DROP $IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP $IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ALL NONE -j DROP $IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP $IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags SYN,RST SYN,RST -j DROP $IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags FIN,RST FIN,RST -j DROP $IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ACK,FIN FIN -j DROP $IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ACK,PSH PSH -j DROP $IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ACK,URG URG -j DROP $IPTABLES -A INPUT ! -i lo -p tcp ! --syn -m state --state NEW -j DROP $IPTABLES -A INPUT ! -i lo -f -j DROP $IPTABLES -A INPUT ! -i lo -s 127.0.0.0/8 -j DROP $IPTABLES -A INPUT -p all -s 10.0.0.253 -m state --state NEW -j DROP # --- if [ $HOSTNAME == $HOSTNAME_HOME ]; then RATE_WHITELIST_RANGE=$LAN_RHSOFT else RATE_WHITELIST_RANGE=$LAN_LOUNGE fi $IPTABLES -A INPUT ! -s 127.0.0.1 -p tcp -m multiport --destination-port $BLOCKED_PORTS -m state --state NEW -j REJECT --reject-with tcp-reset PORTSCAN_TRIGGERS_1=19,24,52,79,109,142,442,464,548,586,631,992,994,3305 PORTSCAN_TRIGGERS_2=23,3389,5900,5920,5922,5930,5931,5950 $IPTABLES -A INPUT ! -i lo ! -s $RATE_WHITELIST_RANGE -p tcp -m recent --name portscan1 --rcheck --seconds 2 -j REJECT --reject-with tcp-reset $IPTABLES -A INPUT ! -i lo ! -s $RATE_WHITELIST_RANGE -p tcp -m recent --name portscan1 --remove $IPTABLES -A INPUT ! -i lo ! -s $RATE_WHITELIST_RANGE -p tcp -m multiport --destination-port $PORTSCAN_TRIGGERS_1 -m limit --limit 10/h -j LOG --log-prefix Portscan: $IPTABLES -A INPUT ! -i lo ! -s $RATE_WHITELIST_RANGE -p tcp -m multiport --destination-port $PORTSCAN_TRIGGERS_1 -m tcp -m recent --name portscan1 --set -j REJECT --reject-with tcp-reset $IPTABLES -A INPUT ! -i lo ! -s $RATE_WHITELIST_RANGE -p tcp -m recent --name portscan2 --rcheck --seconds 2 -j REJECT --reject-with tcp-reset
Re: firewalld / iptables.service past F17
On Mon, Apr 23, 2012 at 7:32 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 24.04.2012 02:08, schrieb Oron Peled: Looks like this transition (as is currently planned) is going to break many setups. I want to show the three following use-cases which may be severely broken by this transition. exactly this is the problem i have attached my ip-tables script making at home a software-router with forwarding of two different networks from my LAN via openvpn and a static route i only stripped the config-block and comments but as you can see there are many useful decisions by $HOSTNAME and this is only one of my scripts for two machines __- another one is built the same way and serves 20 machines while partly rules are for all machines, others depeding as in my example on the hostname and there are a lot of really useful and well thought specific drop/forward/reject rules based on hostname and source/destination networks this script has about 50 KB and a handful of bash-includes well, one may say unmaintainable - but it is, it has a good documentation and structure and we are using it as reference for each iptables.sh needed where ever it is practically impossible to convert this stuff because nobody did write it down in one day, it is grown and maintained over years with the whole infrastructure - yes you MAYBE CAN try to re-implement all this rules in firewalld but would you do this really in a production environment in a security layer and how do you test from scratch? please do not come now why fedora in prodction because it just works if things are not careless removed from the distribution - so please do not take away power featureswhich are not really hurt to maintain firewalld is at least another interface for netfilter why want anybody take away perfectly working ones? Nothing is being taken away, the default is being changed. If you're using Fedora in production, I presume you're installing with Kickstart. You can set up anything you like in Kickstart, including not using firewalld if you so desire. -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
Am 24.04.2012 16:30, schrieb Jon Ciesla: Nothing is being taken away, the default is being changed. If you're using Fedora in production, I presume you're installing with Kickstart. You can set up anything you like in Kickstart, including not using firewalld if you so desire. thank you for your feedback exactly this was my question i liked to get sure that iptables.service is not planned to get removed in future releases and my intention here was to explain why it can not be replaced in many perfectly working environments before future decisions are made to get not offended again why i come up after things are done installation and default does not matter for me, i usually install my servers once and upgrade them, currently F16, installed with F8 i repeat my original question to have the full context here http://fedoraproject.org/wiki/Features/firewalld-default An explicit transition is planned after Fedora 18 with dropping support for the static firewall with system-config-firewal/lokkit. A migration from the static firewall model will be needed then. are there only the ui-interfaces meant or do someone consider drop iptbales.service at all? if so please re-consider this! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
On Tue, Apr 24, 2012 at 9:38 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 24.04.2012 16:30, schrieb Jon Ciesla: Nothing is being taken away, the default is being changed. If you're using Fedora in production, I presume you're installing with Kickstart. You can set up anything you like in Kickstart, including not using firewalld if you so desire. thank you for your feedback exactly this was my question i liked to get sure that iptables.service is not planned to get removed in future releases and my intention here was to explain why it can not be replaced in many perfectly working environments before future decisions are made to get not offended again why i come up after things are done That I'm not sure about. Disabled, yes. Removed, I don't believe so. installation and default does not matter for me, i usually install my servers once and upgrade them, currently F16, installed with F8 i repeat my original question to have the full context here http://fedoraproject.org/wiki/Features/firewalld-default An explicit transition is planned after Fedora 18 with dropping support for the static firewall with system-config-firewal/lokkit. A migration from the static firewall model will be needed then. are there only the ui-interfaces meant or do someone consider drop iptbales.service at all? if so please re-consider this! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
On Tue, Apr 17, 2012 at 10:40 PM, Reindl Harald h.rei...@thelounge.net wrote: Hi one question before decisions are nailed down http://fedoraproject.org/wiki/Features/firewalld-default An explicit transition is planned after Fedora 18 with dropping support for the static firewall with system-config-firewal/lokkit. A migration from the static firewall model will be needed then. are there only the ui-interfaces meant or do someone consider drop iptbales.service at all? if so please re-consider this! I was pushing for the deprecation to avoid a NetworkManager-like duplication for the long term. AFAICS you can s/iptables/firewall-cmd --direct --passthrough ipv4/, and things should continue to work (perhaps with minor modifications to avoid collisions with firewalld's default rule chains). Or, if you insist, disable firewalld (... which might break some applications), and turn your shell script into a systemd service; but --direct --passthrough should be the preferred route. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
Am 23.04.2012 17:32, schrieb Miloslav Trmač: On Tue, Apr 17, 2012 at 10:40 PM, Reindl Harald h.rei...@thelounge.net wrote: http://fedoraproject.org/wiki/Features/firewalld-default An explicit transition is planned after Fedora 18 with dropping support for the static firewall with system-config-firewal/lokkit. A migration from the static firewall model will be needed then. are there only the ui-interfaces meant or do someone consider drop iptbales.service at all? if so please re-consider this! I was pushing for the deprecation to avoid a NetworkManager-like duplication for the long term. i really, really like the idea of firewalld for many setups! it is a really nice improvement for desktops over the long but please consider that network-manager and desktop is not all and on servers with vpn-gateways, routings and such things you do not really like it please do not start seeing linux as desktop-only OS, it is not cool that it works for desktops and servers and this should be considered in big changes AFAICS you can s/iptables/firewall-cmd --direct --passthrough ipv4/, and things should continue to work (perhaps with minor modifications to avoid collisions with firewalld's default rule chains). i simply do not need want any default chains the first in a iptables-script is reset them the iptables.sh for the environment where i work is currently 50 KB large, distributed and for all machines in the network the same Or, if you insist, disable firewalld (... which might break some applications), and turn your shell script into a systemd service; but --direct --passthrough should be the preferred route. how to replace such things? cat /etc/sysconfig/iptables-config IPTABLES_MODULES=ip_nat_sip ip_nat_ftp nf_conntrack_ftp nf_nat_ftp cat /etc/sysconfig/iptables-config IPTABLES_MODULES=nf_conntrack_ftp nf_nat_ftp cat /etc/modprobe.d/local.conf options nf_conntrack_ftp ports=21,4559 options ipt_recent ip_list_tot=5000 ip_pkt_list_tot=200 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
On Monday, 23 בApril 2012 18:56:23 Reindl Harald wrote: Am 23.04.2012 17:32, schrieb Miloslav Trmač: On Tue, Apr 17, 2012 at 10:40 PM, Reindl Harald h.rei...@thelounge.net wrote: http://fedoraproject.org/wiki/Features/firewalld-default An explicit transition is planned after Fedora 18 with dropping support for the static firewall with system-config-firewal/lokkit. A migration from the static firewall model will be needed then. Looks like this transition (as is currently planned) is going to break many setups. I want to show the three following use-cases which may be severely broken by this transition. 1. The simplest desktop case (firewalld is designed for such users). This is what I personally use on most of my desktops/laptops: * The user previously only used system-config-firewall (without custom rules -- we talk about simplest case) * The firewalld package does not even try to convert existing rules (just looked at the .spec file for the post*/pre*/trans*) * Results: - The user looses all her existing firewall settings without a warning (security). - If they had NAT (masquarading) -- pooof, no more Internet for you... - Almost all record of their previous settings is lost (sans .rpmsave) - If the poor user make another mistake (e.g: tries to re-install system-config-firewall), it may even clobber the .rpmsave [this is DATA-LOSS!] 2. Custom made firewall (e.g: hand-written script. I personally use this in rare/complex cases): * It obviously cannot be migrated automatically. * That's OK, as someone that can maintain the custom script, can migrate it manually. * But: - Just like item 1. above, we cannot take the risk that old data (e.g: existing /etc/sysconfig/iptables) would be somehow clobbered by install/upgrade/re-install of firewalld/system-config-firewall. [although the customization user is more likely to have backup of said script, unlike the naive user from item 1.] - As others mentioned before, this use-case may contain features not (yet/ever?) in firewalld. So they need a (long-term) way to keep using their custom scripts (yes, even in F-21 unless by that time firewalld can have the full power of raw iptables script). [note: however, this use-case does *not* need system-config-firewall] 3. Complex firewall made by external tools (similar to 2.) My personal example is fwbuilder (packaged in Fedora): * I use it to centrally manage several firewalls * If firewalld becomes default after some upgrade, then: - Poof, some of these cannot be accessed (NAT...) - ... and alternative access (physical) is Hmmm problematic - I would call this super uncool (just a bit less uncool than the potential data-loss I mentioned before...) Summary: * Regretfully, I think it's clear that firewalld as *default* is a complete show-stopper (for now). * One (not hard) improvement is to preserve old data. E.g: - During firewalld postinst (in install, upgrade is not the problem here), save a copy of all previous iptables config in a well defined location -- e.g: /etc/firewalld/old-iptables-data - Make this data time-stamped to prevent overwriting in repeated (maybe mistaken) install/remove attempts. E.g: /etc/firewalld/.../2012-04-24_02-28/iptables /etc/firewalld/.../2012-04-24_02-28/iptables-config - Also echo a message about it to stderr (I know its against the policy, but critical data-loss is more important IMO). * Try to migrate system-config-firewall data: - That is harder, but even doing only the no-custom-rules case would prevent tons of problems for most (normal/naive) users. - This would help even without/before firwalld is default. * Make installation/activate of firewalld optional even after it is good enough to be default: - Custom/complex setups will not be migrated (surely not before firewalld cannot cover the flexibility of raw iptables) - So when people install servers, they may not want firewalld at all (regardless of system-config-firewall existance) - Don't assume a live-cd is only used only for desktop installs. Many people (me included) install servers from a live-cd and add the rest later. Why? Because many times these are isolated servers (not on my kickstart-configured network), the live-cd image is smaller to download than a DVD, its already in my pocket on a DOK, etc, etc. - So I think that even when firewalld is (eventually) good enough for a *default* install and even when system-config-firewall will already be a relic from the past -- we should allow power-users not to install it in the first place. I.e: it should be a *suggested* option. From a (future) UI
