Why do senior admins use a GUI

Linux on Servers
1

Hi Jay,

After watching a few of your videos it seems you have migrated your personal setup to the GUI for many things. Your firewall & VM/Container host being the two primary “things” I am referring to. Why is that? You lose a lot when you go back to the GUI. Security, performance, stability, flexibility, etc. Are there any other reasons for this general migration?

For the FW transition, you gave one specific example of a time based rule for your kids. From what I understand that wasn’t inherently possible with iptables, but it is with nftables. I use it for my kids too. Was the nftables migration one of the reasons for the migration to the gui?

Thanks,

2

Welcome to the forum!

While not addressed to me, I’d like to point out a few things:

I wouldn’t say “a lot,” but there are a few things and I’d consider tradeoffs rather than outright loss.

Debatable. Some things, like pfsense / opnsense / openwrt and others are not inherently insecure just because you run a GUI. You might have more attack surfaces, but if you believe you can simply hack to one of these (given they are configured properly and they aren’t set to listen on WAN or permit traffic inside from the WAN), then I invite you to and report it to the respective project, to get them to improve their security enough to become acceptable for you to use (assuming you would want a GUI).

Basically negligible. And I know, I’m running iptables on a rockpro64 as my main router and I don’t feel a difference (the cpu is mostly idle, to the point I was thinking of maybe running containers on it, but that’d increase the attack surface, so I didn’t).

I would have to guess it’s because ease of use. You lose flexibility and automation, but you get an easier interface to use. And if you don’t mess with your firewall or hypervisor or NAS daily, you’ll forget the commands for certain stuff, unless you document them (I personally keep some basic cheat scripts on-hand, because I tend to forget them). It’s easier when you visualize a thing (like add rule, from ip, to ip, from port, to port etc.) than when you have to remember a command you don’t use often.

I’m a fan of minimalism (to the point of memenimalism) myself. But I’m highly desensitized to what other people are using. And I don’t really talk about what I use unless otherwise asked or if it’s a useful anecdote. Although I documented many things I use on the L1T forums.

2 Likes
3

Thanks for the feedback. I appreciate the conversation.

Ease of use is a big win for GUI’s if you don’t keep good notes after climbing that learning curve. I’ve learned that the hard way. But once you have climbed that learning curve and you have good notes, the ease of use succumbs to the speed of use advantages. But again, for the casual user the initial learning curve is probably the number one deal killer. For someone like Jay, though, it is odd to switch back. It’s like putting training wheels back on you bike after you know how to ride.

Security is probably one of the areas I would consider the cli a solid win, for a number of reasons. As you mentioned attack surface, the issue of running a PHP web server (as root) is inherently more insecure, but practically speaking that can be mitigated significantly. I’d buy the argument it is negligible if you lock it down to a single IP/VLAN or whatever.

However, shrinking the attack surface is only one security issue GUI’s have. Often the services controlled by the GUI are not locked down as well as they could be if admin’ing them by CLI. The CLI gives you options which the GUI does not. For example, your pfsense DHCP server is running as root on your host box directly (not to mention an old EOL server as of January). Jay advises running under the assumption of assume breach. How many steps does it take to own the box? One. Put that in a container and you have to exploit the DHCP server (which you can now choose to run a current supported version), break out of the container, and then elevate from standard user to root on the host. Honestly, which setup would you prefer?

Also, as for minimalism as a security point, there is so much less to go wrong and so much less trust that comes with it in the CLI. Supply chain attacks are reduced if you have 1/8 the code base. I am ditching my crutch with using netplan on the principal of minimalism, although I really do like that crutch and know I am pushing this idea too far.

I agree performance is negligible. You can run on smaller hardware but meh, who cares. You often have more options in the CLI to tweak things, but again I would concede this is negligible in all the ways I can see it applied. Using the GUI can put a very modest strain on the host, but in most cases that is not a big deal. Small advantage for sure.

I only ask Jay this because he is an admin who knows how to do all this and went back to the GUI. I am sure he is limiting his attack surface as well as can be done, but he is still running a lot of code directly on the host as root. Why not containerize everything?

4

I’d say it’s more akin to learning to drive on an automatic car, driving like that most of your life, learning how to drive a manual transmission and owning a manual for a few years, then moving back to an automatic (in Europe and likely other parts of the world, that’d be different, as most people learn to drive manual transmission cars first).

I agree with containerization of the DHCP server, or better yet, moving it out of your router / firewall box for security purposes. But that is a bit extreme IMO. Sure, it’s hypothetically possible to have your DHCP server as an open vulnerability that could be used to exploit the rest of the OS (i.e. a hazard), but the probability is not that big (i.e. the risk). It’s good to remove hazards if you want to remove any risk, but these hazards are likely a very small risk for just a little bit of convenience.

Personally, if I was to configure a new network for a company, I’d do 2 boxes: router + firewall and a small container box for services like DHCP and DNS (or maybe 4 boxes, with 1 being the firewall and the other 3 being a redundant dhcp and dns server configs with either keepalived or pacemaker + corosync). Then everything else would come afterwards.

5

Dare I say you agree with me?? The cli is better than the gui. :slight_smile:

I watched a video where Jay and Tom were lauding the merits of key based ssh authentication while completely ignoring their GUI login was likely running on the same interface. It’s like focusing on the cat door while completely ignoring the double wide garage door.

Big question is, would you admin by mouse or keyboard in that new network? Would you use pfsense for that router/firewall and some proxmox setup for you other stuff? Or have I won a convert? :slight_smile:

6

And the argument that this is all low probably has some merit. But it’s similar to the seat belt argument. I probably could never use my seat belt, but that doesn’t mean it is a good idea.

If you aren’t scared of a GUI exploit, why not expose it on the WAN. I do that for SSH, but that is containerized too just in case. Might as well put on a seat belt if I am going to take a risk.

7

I agree with you, in the sense that I like minimal setups myself. Just that I don’t care what others use.

I prefer managing server via the cli, so definitely keyboard.

I’d use OpenBSD for the firewall (unless there are some performance requirements for using FreeBSD, which I’d be fine using - not pfsense or opnsense, but actual FreeBSD).

Not sure if I’d go with Proxmox as a hypervisor, or try OpenNebula again (it’s overkill, but being able to use firecracker is a big advantage). But lately I’ve been delving into NixOS, which has a hypervisor flake of its own (microvm.nix - it also has support for firecracker, crossvm, run-of-the-mill qemu and others).

I used to manage CentOS CLI NASes at my previous workplace. Mostly NFS shares and mdraid stuff, the easy stuff.

Not really, as I was already one from the start. Just that I don’t think GUI is inherently bad, or too much worse than the CLI. It’s a very slight tradeoff.

In all fairness, when it comes to monitoring, I prefer things like Zabbix, or Prometheus and Grafana. Could I set up CLI scripts for monitoring? Sure, but I think GUIs have some advantages in certain scenarios. Would Grafana have a way larger attack surface than just cat-ing a summary report in the cli? Absolutely. Would I trade it for security? Nah.

I’ve seen places doing that. Just not my preference. If you use the default 443 port and 22 for SSH, you’ll see how bots at some point will try to brute-force your credentials. Not something I like seeing. Changing the default ports on WAN severely decreases the number of bots trying to script-kiddie you, but I’d still not expose a management interface on WAN, be it HTTPS or SSH. At worst, I’d expose a jump server, with only ssh-key authentication and an unprivileged user, with a minimal distro, stripped of most utils (like alpine). And from inside this user, I’d su into another and then ssh to another server.

By the way, you can ping @jay by just mentioning him. Higher chance he’ll see a message like this.

@jay, check the OP.

1 Like
8

I don’t care what Jay uses either. Just making conversation and interested if he would dig into why a little more. It seems a guy like him would want to play around with his config more than what a GUI could offer. Plus, I have some down time now, so why not kick off a conversation.

Openbsd, huh. That shows your age my friend. I thought about playing around with that almost two decades ago, but Linux is just too dominate to learn something new.

Oh, and I use GUIs for some admin stuff too. I’m only a little crazy. If I were to setup a syslog server it would be running a GUI of some kind.

9

Just because something is popular or dominant, doesn’t mean it’s necessarily superior. OpenBSD has minimalist code and is the only project that I know of that removes the legacy cruft of the system to reduce attack surface. Some argue it’s the most secure OS, I’m not making such claims. But what I do like is their secure by default policy. If you do something to compromise it, it’s all on you.

FreeBSD has seen more usage in the enterprise and has been more battle tested than openbsd. And because of its popularity, it gets better drivers, giving it a speed advantage (especially in the networking stack, which is why it’s typically the choice for firewalls and why other projects use it as a base, despite pf being an openbsd project). There’s other linux firewall projects, like vyatta (which I’ve only seen twice in the enterprise in the wild), but most use iptables. For local firewalls, I’ve seen people use firewalld and ufw, but never as a network firewall (I recall them being based on nftables, but don’t quote me on that).

I’ve used Linux firewalls in a corporate environment before, but I really didn’t like it. Which is funny, because I ended up with a linux firewall here (only because the wifi usb I’m using for WAN doesn’t have BSD drivers and barely has linux drivers at that, I had to build the kmodule). For firewalls, I’d pick a BSD any day. And arguably, for a NAS, I’d probably go with freebsd as well (which is what I’m running on my NAS, because ZFS).

That reminds me, going back to hypervisor stuff, proxmox would be on my radar if I needed to do a hyperconverged infrastructure, because of ceph. But if that wasn’t necessary, I’d still run freebsd on the storage (and probably ceph too, depending on how supported it is on freebsd).

For a lab or a testing environment, maybe. But once you get everything set up and you just want to monitor or make small changes, a GUI is preferable if you want to be lazy. For me, it’s an absolute nightmare to configure all the rules in pfsense compared to just running pf or iptables now. But if I had everything configured already and only needed to check some traffic flow and add a single new rule, then maybe I would consider it, but that’s not how it works, so I prefer the cli.

1 Like
10

True that on the dominant argument. Hello windows.

I switched over to nftables two years ago and like it a lot better than iptables. I have never configured pf via the cli. Is the config layout better/simpler than nft? More features? I am pf curious. From my previous googling the advantages were more noticeable years ago. Opensource is an extremely efficient market, true advantages don’t last long. If you have some specific reasons please let me know. I won’t debate you on them or ask any followup questions. I note the smaller code base (I guess by line count?), and just wonder if that is it?

Totally agree on the CLI work flow for fw rules. Pfsense users just don’t know what they are missing. Nearly all of them don’t care, but that’s not audience we are talking about here.

By play around I mean customize. Like my example of running a DHCP server in a jail or container. Slightly more advanced stuff like that. Stuff that goes beyond click a few buttons and never think about it again.

11

And on that point about cli efficiency with fw rules. I wonder if those efficiencies would ever be enough to justify an MSP to move away from the GUI? Obviously, they don’t. So the lower learning curve must be the overwhelming force?

If I had to admin a bunch of boxes, I wouldn’t want to do that via the pfsense gui. Unless there is some management service I don’t know about. Even then, you’d have to click through so many pages and tabs just to see the layout of all the interfaces. Not to mention all the other advantages of the cli I have tried to argue.

12

I haven’t taken the jump to nftables, I’m just used to iptables and what it can do (like limit / burst stuff, which pf has). I haven’t tried some of the advanced options with pf on the CLI yet. But what I love about it is the man pages, especially the examples (like most of the BSD man pages, linux man pages are always inferior to bsd ones).
https://man.freebsd.org/cgi/man.cgi?query=pf.conf&sektion=5&n=1
https://man.openbsd.org/pf.conf.5

It has similar group rules like iptables (I hated them on iptables, but they are straight forward and more readable in pf conf). The only thing that you have to keep in mind is that pf will go through all the rules and match the last rule, meaning that it’s the opposite of iptables, where the first matched gets applied. There is the “quick” flag to match it immediately, but I’d not use it. Just need to remember that the last rule matched will apply, meaning that your order should be something like:

  • Block 192.168.1.0/24
  • Allow 192.168.1.2

For linux, it’s in reverse, because the first match for the ip 1.2 would be that block for the subnet.

I can’t really give a fair comparison with nftables though, since I’ve never used it. The code size is certainly one thing, but most of all, I have a big trust in the OpenBSD project and everything that comes out of it (like pf, OpenSSH, OpenSMTPD, smapd, OpenBGP, LibreSSL, CARP, doas, OpenNTPD and others). I’m using some of the openbsd software on linux and the only reason I don’t switch over to openbsd on all my servers is that I really got into low power computing. My homelab is almost exclusively aarch64. When I can getaway with it, I run linux containers, when not, I’m planning on deploying a firecracker hypervisor for minimalist virtualization (microVMs seem the way forward, but only linux can run in microvms AFAIK).

Highly doubt it. That’s not because they don’t have some talented staff (depending on which company we’re talking about), but because in a MSP organization, the biggest challenge is changing things. I work for a company selling software to a lot of MSPs and getting them to even upgrade EOL software is hard enough, because they have so many customers that they need to organize with, I can’t imagine having them change to a CLI and have to train their staff to use the CLI, unless they get a really big benefit from it.

Well, some proprietary offerings from different vendors, like switches, routers and firewalls for example, all have ways to configure their appliances both on a GUI and via CLI. Cisco comes to mind first, but HPE, Dell EMC, Huawei and Zyxel, all have two ways of configuring their boxes. Certain servers, like HPE may come with support for things like SLES or RHEL and if you buy them with support, they generally come with a GUI preinstalled (so you can use either the GNOME Network Manager and whatever else in RHEL, or YaST GUI in SLES). I prefer not having to deal with GUIs, but that’s just me.

However, MSPs like having GUIs, which makes newcomers learn faster how to use some systems. But when it comes to troubleshooting, there are a few people here and there who, because they don’t know the basics, don’t know how to read logs and it’s my job to fix stuff for them.

13

Thanks again for the detailed explanation. I have more stuff to learn now.

That firecraker/microservices stuff looks cool. If it gains traction I’ll kick the tires someday. Given you are a fellow minimalist, you may want to give systemd-nsawn a try on your linux box, if you haven’t already. I use that and bubblewrap. Honestly, I may use more bubblewrap in the future.

It is funny you think about power like me. I turned off my Dell heater two years ago and just run my Proctelli fw box and my work station. My office is silent now. This all works b/c I abandoned KVM a few years ago, everything easily fits on those two boxes.

If I ever really had a spark of interest to explore openbsd you killed it by letting me know the rules are upside down. Maybe I knew that and forgot, but at this point I just don’t think I could handle it. And I still don’t really know if the juice is worth the squeeze. I give a ton of respect to the BSDs but I can’t really say why in a quantifiable way. But they have a heritage, and that alone is worth something. I hope they stay relevant for the next twenty years, but I wonder how much new blood they are getting into their projects.

What you say about the MSP space makes sense from my outsider perspective. The MSP space looks like it is won or lost on sales. The operational side looks like it has solidified around a handful of tools, processes, and procedures. Squeezing out tooling efficiency on the operational side of things could help maybe, but not as much as a hard charging sales team. Or the tried and true approach of grinding your staff down to nubs.

Lastly, give nft a try. It might change your perspective on linux firewalls.

1 Like