if you have any error in /etc/sysconfig/ip*tables and start the service, the output is always succeed. You can only see it failed in the logs. Systemd states, everthing is ok. The bad thing is, on error, the network is open to everything. We should add iptables-restore --test previous start/restart
(In reply to Marc Krämer from comment #0) > if you have any error in /etc/sysconfig/ip*tables > and start the service, the output is always succeed. You can only see it > failed in the logs. > Systemd states, everthing is ok. > The bad thing is, on error, the network is open to everything. There is no registered maintainer for iptables. I'll CC Luigi12 and daviddavid, who were the last two to update the package. I changed the component of this report to security > > > We should add iptables-restore --test previous start/restart Would that still need manual intervention from a user who might not at all be aware of this issue?
CC: (none) => geiger.david68210, luigiwalser, marja11QA Contact: (none) => securityComponent: RPM Packages => Security
>> We should add iptables-restore --test previous start/restart > Would that still need manual intervention from a user who might not at all be aware of this issue? The user would/should see the unit iptables failed - which is a good first sign sth. is wrong. Atm the unit is shown good, even if the rules failed and no firewall was assigned. The user can then look in journal or status of the unit and will have the output of the check which will state sth like "Error in line XXX yyy not valid". The error case can e.g. arise by uninstalling xtables-addons or error in loading the modules, so the good rules do not work anymore.
btw. at the moment iptables.service is just a wrapper around the old init scripts. Since we only use the start/stop part, I guess this can be rewritten by setting the Environment, running ExecStartPre to test the rules and then run iptables-restore. For the stop part, maybe we can just provide "a default file" and restore that file to the "stop" settings. If we put this at some user location, the user may decide what "stop" means: e.g. ACCEPT or DENY to the default policy. Comments?
Depends on: (none) => 25367
I am looking into ipset as well. It looks like the same is true for this script. I think I can change these scripts and push an update.
btw. ipset does not work as expected: systemd[1]: Stopped ipset.service. systemd[1]: ipset.service: Failed with result 'exit-code'. systemd[1]: ipset.service: Control process exited, code=exited, status=1/FAILURE ipset.init[282537]: Current iptables configuration requires ipsets systemd[1]: Stopping ipset.service... since it is required by iptables, it does not stop In ipset.service these directives are set: Environment=IPSET_SAVE_ON_STOP=no IPSET_SAVE_ON_RESTART=no This is different from iptables where the config is saved in /etc/sysconfig and the default in iptables is to save the set rules. Here we drop them - is this default wise?
(In reply to Marc Krämer from comment #5) > btw. ipset does not work as expected: > systemd[1]: Stopped ipset.service. > systemd[1]: ipset.service: Failed with result 'exit-code'. > systemd[1]: ipset.service: Control process exited, code=exited, > status=1/FAILURE > ipset.init[282537]: Current iptables configuration requires ipsets > systemd[1]: Stopping ipset.service... > > since it is required by iptables, it does not stop > > > In ipset.service these directives are set: > Environment=IPSET_SAVE_ON_STOP=no IPSET_SAVE_ON_RESTART=no > > This is different from iptables where the config is saved in /etc/sysconfig > and the default in iptables is to save the set rules. Here we drop them - is > this default wise? CC'ing all packagers now, to increase the chance someone replies. Btw, ipset doesn't have a registered maintainer, either. (In reply to Marc Krämer from comment #4) > I am looking into ipset as well. It looks like the same is true for this > script. > > I think I can change these scripts and push an update. Thanks! Assigning to you, then. Please reassign to pkg-bugs@ml.mageia.org if you disagree.
Version: 9 => CauldronAssignee: bugsquad => mageiaWhiteboard: (none) => MGA9TOOSource RPM: iptables => iptables-1.8.9-2.mga9, ipset-7.15-2.mga9
(In reply to Marja Van Waes from comment #6) > (In reply to Marc Krämer from comment #5) > > btw. ipset does not work as expected: > > systemd[1]: Stopped ipset.service. > > systemd[1]: ipset.service: Failed with result 'exit-code'. > > systemd[1]: ipset.service: Control process exited, code=exited, > > status=1/FAILURE > > ipset.init[282537]: Current iptables configuration requires ipsets > > systemd[1]: Stopping ipset.service... > > > > since it is required by iptables, it does not stop > > > > > > In ipset.service these directives are set: > > Environment=IPSET_SAVE_ON_STOP=no IPSET_SAVE_ON_RESTART=no > > > > This is different from iptables where the config is saved in /etc/sysconfig > > and the default in iptables is to save the set rules. Here we drop them - is > > this default wise? > > > CC'ing all packagers now, to increase the chance someone replies. > Really CC'ing them now
CC: (none) => pkg-bugs
*** Bug 25367 has been marked as a duplicate of this bug. ***
CC: (none) => dvgevers
Updated iptables package: This update makes iptables and ip6tables service fail, in case the defined rules cannot be restored. Additionally it adds a rule file which controls the default rules applied on stopping the service. Updated packages in core/updates_testing: ======================== lib64ip4tc2-1.8.9-2.1.mga9 lib64ipq0-debuginfo-1.8.9-2.1.mga9 lib64iptables-devel-1.8.9-2.1.mga9 lib64iptables12-1.8.9-2.1.mga9 lib64ip6tc2-debuginfo-1.8.9-2.1.mga9 lib64ip6tc2-1.8.9-2.1.mga9 lib64ip4tc2-debuginfo-1.8.9-2.1.mga9 lib64ipq0-1.8.9-2.1.mga9 lib64ip4tc-devel-1.8.9-2.1.mga9 iptables-nft-1.8.9-2.1.mga9 lib64ipq-devel-1.8.9-2.1.mga9 lib64ip6tc-devel-1.8.9-2.1.mga9 lib64iptables12-debuginfo-1.8.9-2.1.mga9 lib64iptc-devel-1.8.9-2.1.mga9 iptables-1.8.9-2.1.mga9 iptables-debugsource-1.8.9-2.1.mga9 iptables-debuginfo-1.8.9-2.1.mga9 SRPM: iptables-1.8.9-2.1.mga9.src.rpm
Assignee: mageia => qa-bugs
Advisory from comment 9 added to SVN. Please remove the "advisory" keyword if it needs to be changed. It also helps when obsolete advisories are tagged as "obsolete"
Keywords: (none) => advisoryVersion: Cauldron => 9Whiteboard: MGA9TOO => (none)Source RPM: iptables-1.8.9-2.mga9, ipset-7.15-2.mga9 => iptables-1.8.9-2.mga9,
MGA9-64 Xfce on Acer Aspire 5253 No installation issues Trying to find some way to test this, found bug 1892 (prehistoric almost), but not exactly my cup of tea. Using grc.com here is not usefull as this tests my router rather than the machines behind it (Fritzbox modem/router) Devized some small test to see the effect of the firewall. This laptop has echo request (ping) allowed. Ping command from desktop PC gets results Reset the ping in the laptop's MCC. Now all ping tests from the desktop PC fail. Setting the laptop's echo request (ping) allowed again, makes the ping command from the desktop PC getting again 100% answers. If this test is not sufficent, plse remove the OK.
CC: (none) => herman.viaeneWhiteboard: (none) => MGA9-64-OK
With iptables-1.8.9-2.1.mga9 it fails to start with ... /usr/lib/systemd/system/iptables.service:7: Neither a valid executable name nor an absolute path: LIBDIR@/iptables.init The actual service file has ... [Unit] Description=iptables Firewall for IPv4 [Service] Type=oneshot RemainAfterExit=yes ExecStart=@LIBDIR@/iptables.init start ExecStop=@LIBDIR@/iptables.init stop ExecReload=@LIBDIR@/iptables.init reload Environment=BOOTUP=serial Environment=CONSOLETYPE=serial [Install] WantedBy=basic.target All occurrences of @LIBDIR@ need to be replaced with /usr/libexec
CC: (none) => davidwhodgins
@Dave: Thanks a lot. The iptables.service is old. Forget to copy that one from cauldron where I've tested :( Bad mistake. New build is running "iptables-1.8.9-2.2.mga9" - sorry for that.
Removing the OK and the advisory keyword. Marja, does the existing advisory need to be deleted from SVN, too?
Whiteboard: MGA9-64-OK => (none)Keywords: advisory => (none)CC: (none) => andrewsfarm
It just needs to be updated. You should let her remove the keyword if need be.
Just following her request from comment 10.
(In reply to Thomas Andrews from comment #14) > Removing the OK and the advisory keyword. Marja, does the existing advisory > need to be deleted from SVN, too? Thanks for removing it (else I would have missed that it was no longer good). David is right that it only needs to be updated. Done so now : - - iptables-1.8.9-2.1.mga9 + - iptables-1.8.9-2.2.mga9 Btw, I uploaded it as bugfix advisory, because I wasn't sure a security advisory can have no CVE.
Keywords: (none) => advisory
Security advisories often don't have CVEs, but I agree with this one being a bugfix.
(In reply to Marc Krämer from comment #13) > @Dave: Thanks a lot. The iptables.service is old. Forget to copy that one > from cauldron where I've tested :( > Bad mistake. > > New build is running "iptables-1.8.9-2.2.mga9" - sorry for that. That's fixed. It still won't start as /etc/sysconfig/iptables is empty, but at least it doesn't generate an error message in the journal. I have no idea what to put in it to allow it to run, so will leave it to others to test that it works/fixes the error. If no one can, validate it as it installs cleanly over the prior version with no obvious regressions. (The @LIBDIR@ was a regression. I'd left the prior version installed and enabled from testing at some point in the past. Just happened to notice it in the journal) Marja, there are security updates without a cve, though it's unusual. Just delete the lines for the "CVE:" section.
(In reply to Dave Hodgins from comment #19) > (In reply to Marc Krämer from comment #13) > > @Dave: Thanks a lot. The iptables.service is old. Forget to copy that one > > from cauldron where I've tested :( > > Bad mistake. > > > > New build is running "iptables-1.8.9-2.2.mga9" - sorry for that. > > That's fixed. It still won't start as /etc/sysconfig/iptables is empty, > but at least it doesn't generate an error message in the journal. that is intentional. if the file is empty, there is nothing to be done, so the "service" should not start. if you want to "test" it, e.g write (make sure no othe firewall is running, as they may interfere) iptables -A INPUT -i lo -j ACCEPT (will allow all loopback trafic, since everything else should be allowed, this does not do any harm) iptables-save -f /etc/sysconfig/iptables if you start the iptables, everthing is restored (which is the current state). If you stop it, the output of iptable -L -n should only contain 3 Chains, no rules after starting there should appear a new rule just echo "test" >>/etc/sysconfig/iptables then try to start it again. Now it should fail (which it does not before) > I have no idea what to put in it to allow it to run, so will leave it to > others to test that it works/fixes the error. If no one can, validate it > as it installs cleanly over the prior version with no obvious regressions. > (The @LIBDIR@ was a regression. I'd left the prior version installed and > enabled from testing at some point in the past. Just happened to notice > it in the journal) > > Marja, there are security updates without a cve, though it's unusual. > Just delete the lines for the "CVE:" section.
MGA9-64 Xfce on Acer Aspire 5253 No installation issues. To be sure nothing would interfere, I set the MCC firewall open. Then tried to follow instructions of Comment 20 as far as I understand these. To start with: there is no file iptables present in /etc/sysconfig, a iptables.default exists. # systemctl -l status iptables ○ iptables.service - iptables Firewall for IPv4. Restores previous saved rules from /etc/sysconfig/iptables and restores rules fro> Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled; preset: disabled) Active: inactive (dead) # iptables -A INPUT -i lo -j ACCEPT [root@mach7 ~]# systemctl -l status iptables ○ iptables.service - iptables Firewall for IPv4. Restores previous saved rules from /etc/sysconfig/iptables and restores rules fro> Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled; preset: disabled) Active: inactive (dead) That was to make sure this command did not start the service # iptables-save -f /etc/sysconfig/iptables # systemctl -l status iptables ○ iptables.service - iptables Firewall for IPv4. Restores previous saved rules from /etc/sysconfig/iptables and restores rules fro> Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled; preset: disabled) Active: inactive (dead) Still not running, that's OK as far as I understand [root@mach7 ~]# systemctl start iptables [root@mach7 ~]# systemctl -l status iptables ● iptables.service - iptables Firewall for IPv4. Restores previous saved rules from /etc/sysconfig/iptables and restores rules fro> Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled; preset: disabled) Active: active (exited) since Tue 2023-11-14 14:53:51 CET; 2s ago Process: 19336 ExecStartPre=/usr/sbin/iptables-restore ${IPTABLES_CONFIG}.default (code=exited, status=0/SUCCESS) Process: 19337 ExecStartPre=/usr/sbin/iptables-restore -t ${IPTABLES_CONFIG} (code=exited, status=0/SUCCESS) Process: 19338 ExecStart=/usr/sbin/iptables-restore -c ${IPTABLES_CONFIG} (code=exited, status=0/SUCCESS) Main PID: 19338 (code=exited, status=0/SUCCESS) CPU: 27ms Nov 14 14:53:51 mach7.hviaene.thuis systemd[1]: Starting iptables.service... Nov 14 14:53:51 mach7.hviaene.thuis systemd[1]: Finished iptables.service. # systemctl stop iptables # iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root@mach7 ~]# systemctl start iptables [root@mach7 ~]# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Comment 20 seems to suggest that a new rule should have appeared, which is the case [root@mach7 ~]# systemctl -l status iptables ● iptables.service - iptables Firewall for IPv4. Restores previous saved rules from /etc/sysconfig/iptables and restores rules fro> Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled; preset: disabled) Active: active (exited) since Tue 2023-11-14 14:55:48 CET; 23s ago Process: 19440 ExecStartPre=/usr/sbin/iptables-restore ${IPTABLES_CONFIG}.default (code=exited, status=0/SUCCESS) Process: 19441 ExecStartPre=/usr/sbin/iptables-restore -t ${IPTABLES_CONFIG} (code=exited, status=0/SUCCESS) Process: 19442 ExecStart=/usr/sbin/iptables-restore -c ${IPTABLES_CONFIG} (code=exited, status=0/SUCCESS) Main PID: 19442 (code=exited, status=0/SUCCESS) CPU: 27ms Nov 14 14:55:48 mach7.hviaene.thuis systemd[1]: Starting iptables.service... Nov 14 14:55:48 mach7.hviaene.thuis systemd[1]: Finished iptables.service. # systemctl stop iptables # echo "test" >>/etc/sysconfig/iptables # systemctl start iptables Job for iptables.service failed because the control process exited with error code. See "systemctl status iptables.service" and "journalctl -xeu iptables.service" for details. That seems to demonstratte that the problem has been corrected by this update. Good enough for me , unless someone else decides otherwise.
Whiteboard: (none) => MGA9-64-OK
@Herman: Thanks for testing
Validating.
CC: (none) => sysadmin-bugsKeywords: (none) => validated_update
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2023-0121.html
Status: NEW => RESOLVEDResolution: (none) => FIXED