Feature request for FOG 1.6.x - Add firwall support to FOG installer on FOG Server

[george1421]

To help strengthen security and to support auditing compliance the Linux firewall should be enabled on the FOG server. This native firewall support should be available on any supported linux release that is -1n from current (i.e. at the time of writing ubuntu is at 20.04 so -1n would be 19.04. For Centos that would CentOS8 and CentOS7 and so on)

I see little value in supporting the firewall configuration on FOS Linux.

[Sebastian Roth]

@george1421 While I really do like iptables and firewalling I am wondering how much of security a host firewall adds to a FOG server. We install and use several services and need to open those ports or FOG won’t work. So the added host firewall rules can only prevent from access to services a FOG admin might add to his/her server.

What I mean is that a host firewall only adds security if exposed to a network where you need to separate from good (internal) and bad (Most external) traffic. If you cannot distinguish between good and bad in terms of source address there is not much a firewall can prevent from.

[Wayne Workman]

We have working firewall rules documented here:
https://wiki.fogproject.org/wiki/index.php?title=FOG_security

[george1421]

@Sebastian-Roth Well if you look at it from an audit / compliance standpoint, its a check box item.

Firewall installed? Yes/No

Note it doesn’t ask if the firewall is effective or not. The efficacy of the rules rely on the underlying services, that is true.

By moving to nfsv4 we can reduce the number of ports needed for imaging to 1 clearly defined port using the tcp protocol.

In the end FOG can elect to enable the firewall or not. But reducing the number of open ports and shipping a “secure” product is something that the FOG Project should strive towards. IMO.

[Sebastian Roth]

@george1421 said in Feature request for FOG 1.6.x - Add firwall support to FOG installer on FOG Server:

But reducing the number of open ports and shipping a “secure” product is something that the FOG Project should strive towards.

That is the main point and I totally agree on that.

Well if you look at it from an audit / compliance standpoint, its a check box item.

Is there an audit / compliance that has a simple “Is firewall installed?” question without asking for further details? I wouldn’t care about such an audit really.

Firewall setups/rules need to be very specific for each particular environment to be effective and I don’t see us coming up with a questionnaire on network setups to try to install a good set of rules.

Sure we can just inject the same set of basic rules (allow outgoing, block forward, block incoming - except certain ports) for everyone but for people who have not installed other services on the same server it’s not adding any security and for the ones who have custom services it’s messing things up.

On top of that we have different firewall abstraction layers on top of iptables nowadays. There is ufw on Ubuntu and then firewalld on many systems. I think it would cost us a lot of time to get this bullet proof for the full set of supported distros without adding security.

Therefore I still vote against adding this feature - not because I think host firewalls are ineffective and not worth it but because it’s way to complex to “get right for everyone”.

What about this? When we ask about disabling the firewall in the installer, we could provide a link to the new documentation/wiki for information about setting up the firewall manually?

[Tom Elliott]

@Sebastian-Roth et al,

There is another option. And it’s one our users may or may not like.

We focus on the stuff fog needs to do, and needs to do consistently.

We let admins manage their security/audit needs.

I know fog has strived to make installing fog as easy as possible for any user who may be installing it. But isn’t this a detriment as well?

The admins should know what they’re getting themselves into.

For that, it think we need to install the necessary pieces to make things operation, or provide a guide on the steps to do.

Then we move away from installing packages, configuring things, setup of the server. If we can provide solid documentation then we can be truly OS agnostic and we can manage what fog is actually meant to do and worry only about that.

Wayne’s fog testing installer is great and all, but instead of us worrying about what will break when a new distro version is released, if the documentation is strong enough it will allow the admin to worry about what is broken. Of course they can still ask for our help, but we wouldn’t have to focus on a bash script.

Just my thoughts.

[george1421]

Let me see if I can bring all of this back together because in a way Sebastian and Tom are saying the same thing, and I agree to a certain degree with both.

Basically “do what you do well and leave other to worry about what concerns them”. is the basic of this specific thread. This isn’t meant with a harsh meaning only that the FOG Project can’t be all things to everyone.

I think from the FOG Project perspective the FOG server, and specifically the FOG application must be kept as secure as possible from vulnerabilities. I understand that the FOG Project can’t control a security vulnerability in say the FTP server or PHP libraries, but the FOG Project can setup the server in a way to minimize the security risk. How can that be done? By using secure protocols, minimizing the number of protocols used and minimizing the number of network ports needed to support imaging. I think moving from nfsv3 to nfsv4 is a good choice here because it eliminates the portmapper service and all of its open port requirements. Also if possible the FOG Project should also look into using passwords for nfsv4 (still researching that statement) to prevent just an open file share.

On the context of this thread, I think Sebastian has it spot on. The FOG Project to supply a secure imaging platform and then direct the user to a wiki page that gives instructions on setting up firewalld, ufw, and iptables firewalls, then let the FOG admin enable them if needed. That way the developers don’t have to change the flavor of the month linux distros.

[Tom Elliott]

@george1421 I agree about the elements we require use of such as nfs or switch to some other method that would be more secure.

What I mean with what I’m saying is instead of having the installer try install and configure everything we produce documentation on what to install along with suggested configurations.

[Wayne Workman]

@Tom-Elliott Good thoughts about not focusing on bash scripts. My thoughts on this…

At work, if you can point your peers to documentation saying “this project only supports this distribution” Generally your peers accept it.

It’s been a topic that has come up before: Dropping installer support down to one or two distributions. CentOS and/or Debian. This probably deserves another forums topic.

At this point, I think supporting one distribution is best. I don’t care which one it is, though Debian probably has the best shot at longevity. I fear CentOS will slowly become irrelevant to many as Red Hat focuses on supporting IBM (their parent company), giving less focus to everything else.