How to replace openSUSE firewall with a custom script of rules?

English Network/Internet
#21

Without looking at your situation closely,

I’d guess that instead of invoking SuSEfirewall2, you should instead invoke iptables directly and apply your rules.

I assume timing and application of the firewall and firewall rules should be satisfied by the original SuSEfirewall2 configuration (so may need to retain the original Unit file name).

In general this is how any use of a template works… When you base your revised on a working original you expect to retain all untouched functionality in the original while inserting your wanted changes.

TSU

#22

Yes and no. As I mentioned I tried to combine both .service files by using the following logic:

SuSEfirewall2.service wants SuSEfirewall2_init.service which contains:

Before=network.service                                                                                                                                      
Before=basic.service

OTOH SuSEfirewall2.service should run:

After=network.target ypbind.service nfs.service nfsserver.service rpcbind.service SuSEfirewall2_init.service

which means that combined in one single condition this would means my script should run between the same Before and After. So I have combined all these 3 lines from above and removed the trailing “SuSEfirewall2_init.service” in the After as it will not be used.

BTW I think it might be relevant to add in the Unit also:

Conflicts=SuSEfirewall2.service SuSEfirewall2_init.service

to ensure both firewalls cannot be started at simultaneously.

Looking at network.target 2 lines catch my attention:

Documentation=http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget
After=network-pre.target

Following the doc link I read:

network-pre.target is a target that may be used to order services before any network interface is configured. It’s primary purpose is for usage with firewall services that want to establish a firewall before any network interface is up. It’s a passive unit: you cannot start it directly and it is not pulled in by the the network management service, but by the service that wants to run before it. Network management services hence should set After=network-pre.target, but avoid any Wants=network-pre.target or even Requires=network-pre.target. Services that want to be run before the network is configured should place Before=network-pre.target and also set Wants=network-pre.target to pull it in. This way, unless there’s actually a service that needs to be ordered before the network is up the target is not pulled in, hence avoiding any unnecessary synchronization point.

If I understand correctly this means the firewall service must be set before the network.

Also because network.target is run after network-pre.target and network.service is a link to /usr/lib/systemd/system/wicked.service which in turn:

**Wants=network.target** wickedd.service wickedd-nanny.service

means that any attempt to have a “Requires=network.service” will also make the system Want network.target which is against the docs.

(the following is just my personal speculation)

I imagine the following scenario: At boot time there is no network for some reason (wicked failed to connect or something not configured etc). The mandatory “Requires=network.service” makes the firewall service fail = no protection, no masquerade etc. Later on the system administrator fixes the network and starts the network.service but the firewall remains off = security problem. I suppose that’s why they make the firewall to be started Before network.service and not fail because of its mandatory requirements.

Please correct me if I am wrong. I am not an expert, still learning.

#23

No guess work needed. That is exactly what I explained earlier :slight_smile:

(so may need to retain the original Unit file name).

I don’t see why that should be needed. I actually see it as an easy way to mess up things.

In general this is how any use of a template works… When you base your revised on a working original you expect to retain all untouched functionality in the original while inserting your wanted changes.

The theory is clear. I am actually asking for the practical side here.

#24

As I said, SuSEfirewall2 is split in 2 unit files.

The first one is executed before network interfaces are configured, it sets the default policy for INPUT/FORWARD to DROP and for OUTPUT to ACCEPT. It also ensures that connections from the loopback interface are not blocked (-A INPUT -i lo -j ACCEPT). It also ACCEPTs connections that are RELATED or ESTABLISHED.

This ensures that the system is protected from the moment the network interfaces are brought up.

The second unit file is executed after network interfaces are up and it loads the real SuSEfirewall2 iptables rules.

So, the point is you can’t combine the 2 unit files.

Use SuSEfirewall2.service as a template for a service to launch your iptables script.

Use SuSEfirewall2_init.service as a template for a service to set some basic iptables rules that protect the system during boot-up and don’t need the network interfaces to be already up.

#25

That is exactly what my script does too as I explained in post #3 in the thread and…

This ensures that the system is protected from the moment the network interfaces are brought up.

… exactly what I want.

So, the point is you can’t combine the 2 unit files.

Why? Are you saying that my own iptables rules will fail if loaded before network.service and basic.service but at the same time iptables rules which drop all input and forward will not? If that strangeness is mandatory I might indeed split the script in two parts but first of all I am trying to understand why, so I hope you could explain.

#26

You can’t combine those 2 unit files because they are designed to be executed at 2 different times during the boot chain. Randomly mixing them will only cause problems.

Just to be clear:


Before=network.service
Before=basic.service
After=network.target ypbind.service nfs.service nfsserver.service rpcbind.service

“Before network.service” contradicts “After network.target ypbind.service nfs.service nfsserver.service rpcbind.service”.

If you read “/usr/lib/systemd/system/wicked.service” (which provides network.service), you’ll see network.service is designed to be executed before network.target. Hence “before network.service” AND “after network.target” is a nonsense.

#27

Thanks for clarifying. I think I understand what you mean now.

What would you suggest for ExecStop actions in that case?

Also - can you recommend some documentation which explains the order of all these systemd services and all the rest of it? You really got my interest to learn more about how the system boots and loads all stuff.

#28

On 11/09/2015 05:06 PM, heyjoe wrote:
> Also - can you recommend some documentation which explains the order of
> all these systemd services and all the rest of it? You really got my
> interest to learn more about how the system boots and loads all stuff.


systemd-analyze plot > plot.svg

That will give you a nice visualization. Just open it with some program
that can read svg files (use svg because the text will come out
unreadable if you use png).

I found http://linoxide.com/linux-how-to/systemd-boot-process/ gave a
quick overview of the boot process. Its not too in depth but I think it
gives a good jumping off point with systemd.

–
openSUSE Leap (42.1) 64 bit
Plasma 5

#29

Thank you alanbortu.