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.

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

One such approach is to point nmap at the target in question for an all ports scan while the firewall is down.  Then you will have a manageable set of ports to investigate and chose to allow.

Of course, it could just be port 443 since so many things use it.

I see that in at least one instance of SMT, it has an 'Open port in Firewall' setting to select.

And at least in an older instance, it is all through apache, so 443 might still be it.

Good day,

Were you referring to this application, nmap - https://nmap.org/download.html#windows and scanning the Target Server (SMT Client Machine) and then the SMT Sever itself? I did also browse that TID, https://www.suse.com/support/kb/doc/?id=000019870 and yes it would seem that changing the SMT server port from 443 to 8443 might be something that I can try as well, since that does make sense if I wanted to double up the activities on the SMT server.

Thank you,

-DS

Good day,

Were you referring to this application, nmap - https://nmap.org/download.html#windows and scanning the Target Server (SMT Client Machine) and then the SMT Sever itself? I did also browse that TID, https://www.suse.com/support/kb/doc/?id=000019870 and yes it would seem that changing the SMT server port from 443 to 8443 might be something that I can try as well, since that does make sense if I wanted to double up the activities on the SMT server.

Thank you,

-DS

Yes,  that is the nmap I refer to.  A very powerful and useful tool when working at this level.
the CLI version comes with OES already installed, though to start learning, the Windows GUI version helps you see sample commands to help you get going.

Just make sure you have wetware level permissions to do stuff on/to a system. Some nmap scans can push a box.  It can get you in trouble to scan systems you don't have such permissions to do so on, not that it is normally noticed enough to track you down.

Good day, 

Okay I was able to get the nmap installed and yes it's a very helpful tool. I do see the ports that are opened currently on the SMT server, and I also saw this documentation link, https://firewalld.org/documentation/zone/predefined-zones.html so it looks like the first step is to change the NIC card from Public to Internal so that I can set up those networks that I want to connect too, is that correct? Allowing (or Trusting) the access that I want to allow. 

-DS

You don't strictly need to change that zone, as they are structurally the same, just the differing names labelling them.  It just helps in anyone (including future you) to have an idea of what is set.    You look well on your way with what you've articulated.  

Some people spend their entire careers at this level, so just try to keep it simple as you go.

The many scripts for nmap can be a rabbit hole of interesting explorations, just so you've been warned  ;)