Thoughts on Nethserver 8 gateway & IDS modules

Hi all,

first of all:
@alefattorini Thank you very much for sharing the video of the community meeting last saturday. Also a big thank you to every speaker there, you all held very informative and interesting talks!

The very first presentation on the future of Nethserver 8 by @robb made me think, especially the part on moving to a type of a… well „containerised Nethserver 8“ (please correct me if I got that wrong)

Moving towards more flexibilty as well as more recent versions but having less of headaches on dependencies sounds quite nice as the future of Nethserver. However, I was quite puzzled that to achive this the gateway as well as the IDS module might vanish completely - did I got this right @ambassadors_group ?

I fully understand that a containerised approach will not allow for a „gateway mode“ (at least in terms of security) as well as an IDS will cause (even more ) trouble in such an environment.

I also know, there are (very) specialised distribution explicitely focussing on being a (fully-fledged security aka UTM) gateway.

However, the beauty of being able to achive both, UTM gateway and e.g. a Mailserver, by simple deploying nethserver as needed is what I was searching for: Not having to deal with two (of more) different managing/templating/GUI systems. Although I obey the principle „one tool for one job“ for me nethserver is the toolbox I can fill with what I need to get the job done a la best-effort.

There are quite a few topics on current changes and decisions which have to be taken:

But unfortunately I was not able to find a promising answer in those topics, so finally here comes my question:
Might ist be desireable to have two „flavours“ of Nethserver 8, e.g. called „gateway“ and „standard“?
Or is this way too far away from what Nethserver is and will be (as well as wants to be) in the future?

1 Like

Why not Both NethServer and OPNSense or PFSense as VM in Proxmox PVE instead of 2 NS. Create Vlan in Proxmox, as per requirement.

We’re still working on this idea.
My project is to have a single user interface to configure all the containers: one (or more, if necessary) container will have the gateway features, one the IPS, etc.

2 Likes

You are totally right, that would be possible, however you will still have to make yourself comfortable with - in this case - three different WebGUIs (Proxmox, OPNSense and Nethserver). Of course, each surely perfectly fitting for the system it has to administer. However, there are situation where you simply do not have hardware capable of virtualisation thus one have to run the systems physically separated.

That sounds quite well, thanks for sharing this. If you’re later on in need of testers I’d be happy to help. :slightly_smiling_face:

So in summary, the gateway as well as IDS module will survive if possible as container an hopefully be administered from a single interface. That’s a relief as I just migrated a home network to use nethserver in gateway mode.

However, are there also plans on “hardening” the basesystem running all those containers (especially if also usable as gateway) or will this be in the administrator’s scope on OS level? (assuming from the talk that Nethserver later on might run on different based operting systems ?)

1 Like

I know that from a pure system load footprint subsequent options are bigger… but why i should pickup NethServer 8 instead of ESX or Proxmox? Or CentOS Stream, with Podman support?
Precooked recipes as click-to-install? Well, it seems the base for containers, with a bit of struggle due to network configuration. With the disadvantage to anyway do everything manually if not available from the NethServer repository the “module as container”.

And compared to full fledged virtualization, without the advantage to use the same box for run something else that Linux “the choosen one” for NethServer 8. Or a podman container.

Also… will users be allowed to have “more containers of the same software” into this way to figure out NethServer 8? Obviously with different user bases…

Being bold and aim to the Moon is a wonderful way to behave. But before wear the jump suit, please, be ready to do the whole trip, not most of.

The main reason for NethServer has always been that all modules are knitted together and fully integrated with the accountmanager of choice. IMO this is the major difference with solutions like webmin that also provides a centralized admin interface, but lack the safety measures and integration.

You can always create something similar like NethServer by collecting all services, from docker repo’s or Turnkey. Then still you need to knit them together.

But let’s look at it a bit more pragmatically: Now, when you go to cockpit server manager and add a module, let’s say “Nextcloud” you press a button and magically nextcloud is installed and configured. At the moment it uses RPM to get there. What if you press that same buttun but instead of RPM, it puls a container image that is automagically activated and configured: endresult: the same. Only the techniques behind it are different, but the enduser will not notice any difference.

By adopting containers, I think we can attract a lot more users and developers, giving the project a lot more potential.

Finally, if you don’t like CentOS (stream) it shouldn’t be too difficult to make the same available on Debian or whatever other distribution, since containers will run on any flavor of linux.

3 Likes

I think that the bold section is… wrong.

With package management i can install only one instance of that package, unless someone repackaged with another name the same content.
With a container, i can have quite a lot of replicated contents/applications in different containers for different uses/users.
Which the current system is quite technically unachievable, unless the configuration for the package/service/application is quite re-build from scratch and protected by the regeneration by the update command, creating the proper fragment.
But not with containers… Every container could be configured separately.
I need 4 user bases? Why i cannot have 4 OpenLDAP instances? Then 4 NextCloud, 4 Groupwares, 4 mattermosts…
I’m quite sad that @davidep and @filippo_carletti did not wrote by themeselves. What i wrote few rows above is true, but won’t become reality with cockpit+podman NethServer.

@pike: My talk and these ideas are not set in stone. It is a possible direction where we can go to. As always, please do amend and comment on the idea so we can make a version of NethServer that is adding functionality and usability.
For me, I wouldn’t oppose an option of multi-account-provider and multi-modules of the same kind. But to be honest, I don’t know what this would bring towards complexity and manageability.

I really doubt if someone is logging in a containerized nextcloud, he will have a different experience than someone who is logging into an rpm based install of nextcloud.

1 Like

I can agree on that. On the other side, most users of this platform are sysadmins or wannabe (i put myself into second one) so having the possibility to install two Nextcloud instances (or any other module, which can be configured) can change a lot!

2 Likes

Whoops, maybe the subject needs to be redefined :slight_smile:
Never mind, a really interesing turn this all took.

I agree to that, but i think there is even more why Nethserver is more attractive to use.
Following example: A Synology Disk Station also offers a central account provider and tight integration with a whole bunch of other “apps” (calendar, contacts, media server and of course it acts as samba/nfs/ftp storage) all managed via a centralised, unified interface. You may also run it as a mailserver if you like to. BUT: If you are unhappy with the configuration options predefined by Synology or simply need something not provided by them, you cannot do that easily as the underlying linux is IMO heavily restricted and at quite a few places does not resemble linux at all.

In Nethserver, the owner may fully customise everything and also add functionalities not pre-packaged if needed. PLUS having the advantage to run a (if needed physically) separated system as security gateway without the need to learn yet another kind of administration workflow.

Well, admittedly, the comparison may lag behind as I think Synology NAS are being consider targeted rather toward the enduser segment and they were never intended to be a gateway I think. However, I hope it isn’t too absurde.

Won’t above mentioned customisability get considerably more complex when fully relaying on containers? I myself do not have any experience in regard to containerised anything up to now. Therefor I think a new version of Nethserver relying on containers will surley add a layer of complexity - maybe only at first glance. Please don’t get me wrong, I do not intend to sound as I’m totally against any plans regarding Nethserver 8 containerisation, I definetly also see advantages.
Speaking only for myself: Another steep learning curve to master. :partying_face:

I must admit I really like the idea of multi-account-provider. This way it may be possible to host e.g. several email domains on the very same Nethserver but still keeping those fully separated.

Thats also something I really like about Nethserver: The developers are actively listening.

5 Likes

Sorry but multiple tenants are still out of sight by now because NethServer is targeted to SMB/SOHO. There is room for collateral projects :wink:

This is still a primary goal: owning data and configuration.

:+1:

Back to the topic, I hope we can still achieve the same even if we rely on two distinct (and more specialized) OSs: one for the gateway, one for the services container. Time will tell…

1 Like

And SMB/SOHO needs containers? C’mon Davide, I can agree that using containers can ease a some integration issues for some other software, but the load of the system, compared with simple packages, is bigger (without slightly).
Therefore, you’re getting some of the advantages of virtualization, without a full fledged capabilities of virtualization like running different OSes. Also, due to goals of nethesis, without advantages of multiple containers with the same application.

IMO, container only became a hell no.
As stated before

Again, IMO.

1 Like

SMB/SOHO needs a variety of services, and I doubt they (for the most part) much care how they’re deployed. Just like any other technology, they have their pros (which I think you’re minimizing or ignoring) and cons (which you seem to be exaggerating). Is the overhead of a bunch of docker containers significantly greater than that of having a half-dozen PHP versions all installed and running at the same time?

Like it or not (and while I don’t have strong feelings on the subject, such feelings as I have aren’t that positive), containers seem to be the direction Linux application deployment is heading. RedHat certainly seem to think so. If that’s the case, as it seems to be, containers are going to become, to a greater degree, the primary means of distributing software, and we’ll need to either use them, use third-party packages, or build our own packages. The path of least resistance would seem to be to use containers.

Granted, this means the OS won’t run on an i386 with 1MB of RAM. I don’t think that’s the end of the world.

2 Likes

@danb35

Hi Dan

SMB/SOHO just wants the job done, the itch scratched. What or how doesn’t matter too much, costs do… In that sense you’re quite right.

I do have more issues with certain “mental processes” behind the mechanisms of Dockers - even by project leaders in big companies like Red Hat:

Why should a dev bother with setting permissions or securing the database server like PostgreSQL? It’s only a single purpose, isolated Docker…

So security is ignored with such a mindset…

It’s not my problem, it’s not in my yard. Someone elses problem…

In the meantime the network complexity is increased mannigfold, ports exposed etc.
And no one has any overview of what or where is not secure or open - except for hackers!

Standing back a bit to take in the whole picture:

  • Less security, because: who cares?
  • More networking issues, due to more requirements of Containers/Dockers.

And:

When the sh*t hits the fan, the damage will be really extensive: Thousands or millions of containers hit at the same time! And nicely globally distributed, in the case of a few BIG companies…

I tend to view things from a security perspective - like the old discussion of open by default or closed by default.

UNIX has everything closed by default, if you need a port open, you open it. If you forget to open it, it won’t work, but no security gotchas!

Windows has everything open, if you don’t need it, close it. If you forget ANYTHING, you have a gaping barn door open!!!

It’s no more “You have a security issue” but “You ARE the security issue”!

I have NO problems with virtualization or dockers / containers. Heck, I use them myself a very lot. But I DO want attention paid to security issues - or possible issues!

My 2 cents
Les avcocats diabolis :slight_smile:
Andy

2 Likes

I agree with you here @Andy_Wismer
And in the case of NethServer I see the options to have those containers secure in nethserver repo’s: secured and configured packages that seamlessly fit in the ecosystem.
And still you can be adventurous and install some docker container or even create one yourself. But then you are responsible yourself for that security. Sysadmins who know what they do will still be needed to keep the environment sane, safe and secure.

2 Likes