Good day, 

I've seen this behavior as well, I have disabled the firewall, and ensured that the service wouldn't restart, and yet there are a number of times during the day(s) that the firewalld.service is running again. Honestly, it's frustrating as SMT clients won't update properly, if they cannot contact/connect with the SMT 2.0 server, I also never saw this behavior with SMT 1.0, and would like to find some type of remediation. I don't if there would be anything in the SLES15-Sp4 forums, I've never actually logged into that service, but happy to try if that becomes needed. Much like you mentioned, in my internal arrangement, I rarely if ever bother with friewalls, certainly for outside connections I would do so, but again internally it seems to be another layer that isn't really needed. 

That being said I've only been running SMT 2.0 to match/mimic my customer arrangement, and might just return to SLES12-SP5 and SMT 1.0 if I cannot figure out the firewall.d.service issue. 

Again I've tried to disable, manually start up, but it seems that it's changing on it's own volition. 

Thank you, 

-DS 

Those 3 commands should help :

# systemctl stop firewalld

# systemctl disable firewalld

# systemctl mask firewalld

3d one is the best one ;-)

Good day, 

I used this command as well (for now) systemctl mask firewalld and we'll see how things do moving forward. I can usually tell if the firewall service has turned back on because unable to SSH to the server in question. I guess as you had mentioned as well might not be a bad idea to start digging into this and seeing what it would take to keep the firewall up in the future. 

There is this whole 'zero trust' thing that is pounding through the industry, and firewalls everywhere is just one part of it. 

As the bad actors keep getting better, with increasing automation and now ML to do their nastiness, it has become an InfoSec standard to assume breaches will happen.  Basically make it hard for the bad actors to get around without setting off alarms, with good backup and logging systems. Firewalls are just one form of speed bump and obstacles to add into the soft underbelly of our systems.

There is this whole 'zero trust' thing that is pounding through the industry, and firewalls everywhere is just one part of it. 

As the bad actors keep getting better, with increasing automation and now ML to do their nastiness, it has become an InfoSec standard to assume breaches will happen.  Basically make it hard for the bad actors to get around without setting off alarms, with good backup and logging systems. Firewalls are just one form of speed bump and obstacles to add into the soft underbelly of our systems.

Good day, 

I'm happy to start working with the Firewall, but I just need to know what ports would need to be made available for the SMT server to function?

Port 22 for SSH is the first 

But what does SMT need to have available so that the clients can update to the SMT server, and the patches be provided back to the Clients? 

Sadly, the documentation seemed a bit lacking in that realm. 

Thank you, 

-DS