Bug 29368

Looking at the Fedora SPEC, shorewall-init is an optional additional Source file that can be added to the package.  It probably should be added to the package, but it's up to the base system maintainers as to whether it should be enabled by default.  It's a new feature, so this would just be added in Cauldron.

Priority: High => Normal
Assignee: bugsquad => basesystem
Version: 8 => Cauldron
Severity: critical => enhancement

Thanks David

Any chance it will be backported into MGA8 as well?

/Christian

christian, Just to clarify, if you stop shorewall from starting with
# systemctl stop shorewall.service
# systemctl disable shorewall.service
# systemctl reboot
then check from another system on your lan, you'll find that all ipv4 ports are
now closed on the system with no firewall. You can do the same with shorewall6
for ipv6 ports.

Unlike windows where a firewall is used to close ports, in linux it's used
to open ports. Without a firewall (or manually run commands) all ports
are closed. That's why this is not a security issue.

CC: (none) => davidwhodgins

Thanks Dave. I learned something today. 
What we have on our MGA wiki for firewall might be misleading then.
It is written:  “ If you do decide you want to run a firewall on your Linux computer then you should be aware that unless you open some ports on the firewall then you may have difficulty with functions such as printing or browsing other computers.”

I interpret it as the firewall function closes all ports. Then, wrongly based on your info, I extrapolate it as all ports are opened if I don’t run a firewall. 

What do you think? Should the wiki be reviewed?

Yes. Which wiki page?

In linux, the kernel does the ip packet filtering. Shorewall, like other
firewall applications are used to create the IP packet filter rules used
to control the filtering.

If you uninstall or stop shorewall, all ports are closed. No incoming packets
that are not responses to outgoing packets will be dropped. If you want to
open all ports (for example in a local area network with only trusted other
systems), then with shorewall running, issue the command "shorewall clear"
or set up the rules to open all ports.

See https://doc.mageia.org/mcc/8/en/content/mcc-security.html#drakfirewall

Hi
I meant this wiki:
https://wiki.mageia.org/en/Firewall#Is_the_Firewall_Actually_Needed.3F

I will make a proposal.

All ports are closed only if you're actually running a firewall.  If you don't have one at all, they're all potentially accessible (they're only actually accessible if something is listening on them).  The purpose of shorewall-init is to address a small amount of time between when the network interface comes up and shorewall starts where any running network services that started before the network would be accessible.  It's more a theoretical issue than a practical one in most cases.  Where it can really make a difference is if shorewall fails to start, for instance if you have a syntax error in one of your shorewall configuration files.  In that case, shorewall-init causes it to "fail closed" as opposed to the "fail open" behavior we have currently.  For less experienced users, this can be problematic as it shuts down your network, which could make it more difficult to figure out how to fix it, so that's why it's not usually a default behavior, but again, we'll leave it to our base system maintainers how they want to handle that.

Thanks for clarifying the issue.

> if you have a syntax error in one of your shorewall configuration files. In that case, shorewall-init causes it to "fail closed" as opposed to the "fail open" behavior we have currently. 
I'm not sure about it. I remember this practical problem :
Using KDEConnect and using a long wifi issd. There was a bug in Mageia with issd longer than 15 chars (IZNAME>15) which prevent shorewall to start. No error was shown, the symptoms were mostly a non-working KDEConnect. One has to restart manually 'shorewall restart' to see the error. In this case, all port are closed.

CC: (none) => j.biernacki+mga

Hi
I had to do some tests to be sure I understand the status.

What I have done:

TEST 1-
shorewall enabled and started at boot. ping not allowed. shh not allowed.
ping -> no answer
ssh user@192.168.x.y -> ssh: connect to host 192.168.x.y port 22: Connection timed out
(ssh request is dropped in the journal)

TEST 2-
shorewall enabled and started at boot. ping allowed. shh allowed.
ping -> OK
ssh user@192.168.x.y -> access granted

TEST 3-
shorewall enabled and started at boot. ping allowed. shh allowed. shorewall manually stopped after logging in.
ping -> no asnwer
ssh user@192.168.x.y -> ssh: connect to host 192.168.x.y port 22: Connection timed out
(no log in the journal)

TEST 4-
shorewall enabled and started at boot. ping allowed. shh allowed. shorewall with failed status generated by error in shorewall.conf and service restart: 
ping -> no asnwer
ssh user@192.168.x.y -> ssh: connect to host 192.168.x.y port 22: Connection timed out
(no log in the journal)

TEST 5-
shorewall disabled, hence not started at boot:
ping -> OK
ssh user@192.168.1.140 -> access granted

TEST 6-
shorewall enabled and try to start at boot, but crashes because of error in shorewall.conf.
ping -> OK
ssh user@192.168.1.140 -> access granted

I'd like then to confirm my conclusions with you:
* If shorewall is enabled and started at boot, then stopped manually or crashed, ports remain closed. Fallback is safe. No need of shorewall-init.
* If shorewall is enabled but fails to start at boot, all ports are opened.
* Without shorewall enables and started at boot, ports are opened. It confirms that without shorewall-init, there will be an elapsed time with all ports opened, pending for shorewall to start. Then, the probability and easiness of the exploit can of course be discussed (is it easier to exploit than spectre or meltdown vulnerabilities?); I am not competent enough for that.

Hi
What do we do then? We close without action?