Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security IT Technology

Most System Administrators Prefer Firewall GUIs Over CLIs (zdnet.com) 159

Posted by msmash from the people-have-spoken dept.
When it comes to firewalls, most system administrators prefer to use a graphical user interface (GUI) rather than a command-line interface (CLI), a new academic study published over the summer has revealed. From a report: Despite the many preconceptions that system administrators are almost all ardent CLI users, firewall GUIs won by a pretty large margin in a survey compiling results from more than 300 respondents. Almost 60% of sysadmins said they "preferred" GUIs over CLIs, and 70% said they "used" GUIs on a daily basis. The survey showed that while CLIs might be popular in some circles, they are not the most ideal interface for managing a complex security software suite like a firewall. The survey, which included more than 15 questions that also sought to discover the reasoning behind each answer, revealed that "usability" was the main reason why system administrators tended to prefer and use firewalls more than CLIs.
This discussion has been archived. No new comments can be posted.

Most System Administrators Prefer Firewall GUIs Over CLIs More

Most System Administrators Prefer Firewall GUIs Over CLIs

Comments Filter:

  • Group the results by age. The older folks are comfy with CLI as they grew up with it.

    Younger kids are less excited about using it.

    • Group the results by age. The older folks are comfy with CLI as they grew up with it.

      Younger kids are less excited about using it.

      I'm about 4 years from Social Security age, and I hate CLIs.

      I know them. I grew up with them. But I still hate them.

      Next generalization?

    • Re: (Score:2)

      by mark-t ( 151149 )
      I would guess that is only to the extent that age might tend to overlap with experience.

  • Most likely to do with familiarity (Score:3)

    by guruevi ( 827432 ) on Monday October 28, 2019 @02:16PM (#59355490)

    I like CLI for the stuff "I know" but I prefer GUI's for stuff I'm not continuously using or overly familiar with. I also like GUI's that can do complex tasks for me in a single button, which firewall rules belong to typically.

    In the end, I have to regularly dive into the CLI anyway, but I'm shying away from eg. deploying Docker for my team because specializing someone is risky. Rather have a GUI like VMWare or VirtualBox even though it's not as performant as Docker, but Docker development and associated GUI's are crap, let alone Kubernetes, SystemD and all the other hell-spawn the "cloud" brings us.

    • This. Script or GUI to generate the core set of firewall rules into a script, then edit the resulting script to add a few tweaks that the GUI didn't account for (like running stuff on non-standard-for-protocol ports)

    • Research (and common sense) suggest that for a unfamiliar system, it's useful to he able to see the available options. Once you know what you want to do, a CLI is much faster.

      As a silly example, I don't go to McDonald's much. The other day I went in an saw they have kiosks where you can order. With no training necessary, I clicked "Sandwiches > Burgers > Quarter Pounder with Cheese", then "Customize > Onions > Remove". It only took maybe two minutes to order a burger, without ever having see

      • Re: (Score:2, Informative)

        by war4peace ( 1628283 )

        If I were entering burger orders all the time, I could type "quarterpounder -onion" in under 3 seconds.

        How I love it when people conveniently leave out all other steps and yell "me can do in 3 seconds!" - no, you can't.
        First you would need to log in. The GUI does that for you, but the CLI doesn't. Then, the "-onion" option would need to have arguments, which you would need to learn, e.g "-onion off" or "-onion double", or if the CLI option would be really elegantly built, "-onion keeponly" which would remove all other optional ingredients and leave only onion enabled. You are also missing the quantity argume

  • Of course GUI has advantages (Score:3)

    by fred6666 ( 4718031 ) on Monday October 28, 2019 @02:19PM (#59355506)

    You don't have to remember cryptic commands by heart and you can get a quick view of the available options.

    The problem is that firewall GUIs only implement a tiny subset of what can be done. All other options must be configured either using the command line, or by editing a configuration file through the GUI, which kind of defeats the purpose of a GUI.

    I like the fact that I can enable masquerading and port forwarding easily through my router's web interface. However, I had to add custom commands to do advanced stuff such as routing based on source IP address.

    • And that's the point. Too many times the GUI gives you fisher price level of control and you are forced into the command line in order to execute advance commands. .

      • But that's not the problem with GUIs, it's the problem with *a* GUI. The fix is to close the gap.

        • Give me a single example of a GUI with all options from iptables and iproute2
          And no, a GUI with a text editor an a configuration file doesn't count.

      • And if you ever touch it again with the GUI it will delete all the "advanced" configuration and go back to being a fisher-price toy.

    • Re: (Score:2)

      by mark-t ( 151149 )

      You don't have to remember cryptic commands by heart ....

      Objectively labelling the commands as "cryptic" when that is actually only a function of how much exposure one has had to them is, I think, kind of poisoning the well [wikipedia.org].

      The English language is going to be cryptic to someone who has never heard it before, that certainly doesn't make the language cryptic.

    • Re:Of course GUI has advantages (Score:4, Informative)

      by That Ordinary Guy ( 6159720 ) on Monday October 28, 2019 @02:57PM (#59355710)

      However, I had to add custom commands to do advanced stuff such as routing based on source IP address.

      Strictly speaking, you don't do routing with a firewall. You can nevertheless tag packets so they are handled differently at the routing layer. You may also redirect ports/ips but this is not really routing.

      I never put routing instructions in my firewall scripts since the firewall is reloaded more often than the routes and you don't want to affect the routes every time you reload the firewall rules.

  • To the potential (elitist?) naysayer i say go configure a Cisco ASA.
  • Well designed GUIs are great when you need to get something basic going quick, but they lack the power that one can get out of the CLI when you know what you're doing with them. For instance, when I set up CISCO routers through the CLI, I can use my network documentation to get it and the firewall configured and throwing packets around in about 2 minutes per machine, mostly waiting on the hardware to catch up. When I was configuring my Ubiquiti router for the first time through its GUI, it took me a bit l

  • Doesn't that kind of depend... (Score:3)

    by Hizonner ( 38491 ) on Monday October 28, 2019 @02:31PM (#59355550)

    ... on exactly what you're actually doing at the moment?

    Study brought to you by somebody who wants to cheap out on one or the other...

  • Why not both? (Score:3)

    by bettodavis ( 1782302 ) on Monday October 28, 2019 @02:33PM (#59355562)
    GUIs and web based interfaces are fine for interacting with products you aren't very familiar with or that you .rarely have to interact with

    CLIs on the other hand are better for automation.

    Products targeting massive deployment and replication should have CLIs in the first place, but you can certainly have both to give you options. VMWare ESX is a good example of a product giving you both a functional GUI and a solid CLI for automation

    As long as proper security measures are enforced, you can benefit either way.

  • With a gui editor over any GUI interface.

    CLI over you more control over GUI.

    A GUI Editor will make you editing rules faster and prevent stupid error

  • GUI are good. But keep a fully functioning CLI (Score:3)

    by jellomizer ( 103300 ) on Monday October 28, 2019 @02:39PM (#59355602)

    I am happy with a GUI interface for tools. A good GUI gives you all the options the product can do and a way for you to look them up and see what is available, and a new feature or a new request makes it easier to see if it can be accomplished. However my main rule of IT. If you are doing the same job every day in IT, you are doing your job wrong. In that case CLI are wonderful for scripting, so those common jobs you need to do every day can be done via CLI inside a nice script.

    I am normally weary of hiring an Admin who is CLI only, or GUI Only. a CLI only guy will use the feature they know about, and often are not to curious about new features and tools available. In terms of Firewall and Security we need flexibility and often out of the box methodologies to keep security high, while meeting business requirements. GUI Only people often fail to understand the core on how things really work, and often wast their time playing in the GUI where a quick and effective script can do the the job. As well sometimes there are CLI options not available on the GUI.

  • I put up with the command line for firewall configurations when I'm forced to use it. (For example, there were more advanced things I couldn't configure with the GUI that came with my Ubiquiti EdgeRouter X firewall appliance.) Because their web site has good support pages with details on how to do most tasks, it make that much more acceptable. Just do a search for what you need and follow the step by step directions.

    I remember a less pleasant experience configuring firewall rules in an old Cisco PIIX firew

  • Last time i looked for OSS FW GUIs i settled on fwbuilder. It spits out a shell script if you target Linux. Then you can fiddle the script.

  • For some things, like linux administration, I generally prefer CLI w/ just a few exceptions.

    For SAN fabric mgmt though, I definitely prefer GUI, I like seeing everything layed out in neat columns, and it's less likely to result in a broken zone due to my mistyping a long ass WWN or something. Also, the mini map that Cisco DCNM SAN Fabric mgr provides is a nice visual of the whole SAN.

    Tools are tools; CLI and GUI just offer somewhat different perspectives for the most part. Unless the GUI is really poorly

  • - Most people who use a CLI, prefer a CLI (CLI 61 vs GUI 7).
    - Most people who use a GUI, prefer a GUI (GUI 169 vs CLI 30) .
    - The amount of respondents currently using a GUI is higher than those currently using a CLI.

    I don't think it's a very interesting study, especially given the lack of any questions regarding the (operating) systems used.

  • I don't know any professional who uses GUIs for those sorts of tasks. Maybe MCSEs or something.

    GUIs are problematic for any complex configurations: (1) You can't easily save the exchange as notes for future reference like you can with text. (2) You can version text in a source control system and easily see what changed over time. (3) You can't script GUI interactions so you can replicate things over multiple devices & sites.

    Sure, normal users don't know anything beyond the basics of working their "

  • Really, it depends on how heterogeneous you have to be. If you support a mix of hardware, keeping track of the differences in CLI language is mind-numbing. And even when you start to learn one, it's still so verbose as to be mostly wasted time.

    Either you're using an external GUI (at the minimum an advanced text editor) to edit your CLI script, or your using an intrinsic GUI to edit the config directly. Nobody reasonable is hand-typing an entire configuration more than once.

  • /Oblg. Why not BOTH?

    CLIs have pros and cons; GUIs have pros and cons. A smart person uses multiple tools depending on the task.

    Yet another stupid debate like Vim vs Emacs. Everyone "clearly" knows Vim is superior. /s

    --
    Patreons I believe worth supporting:
    * China Uncensored [patreon.com]

  • In past usage of Cisco firewalls and routers, the GUI was at best deficient and at worst defective. To get anything done you had to use what I referred to as their "Assembler for Routers" language. Because of the complexity and the high cost, I eventually applied the ABC rule of networking - "Anyone But Cisco". I've used other top-rated firewalls where GUI is complete and usable and gives a great view of complex configurations.
  • A GUI is worthless if there's "hidden options", which I think is why there are so many holdouts that either use both or won't go without a CLI. The ability to dump/diff configs to text or xml or some other human parse-able form is totally invaluable. Think of *REALLY* bad nights where you've been working all day with the old system and the new system and they're 'identical' but don't work the same way, either because it has to load in some certain order, or some feature is retain-able when a parent is tur

  • CUI's and GUI's could have been closely related in that one builds a GUI by specifying what commands and/or attributes are sent back and forth. When using a GUI, one would have an (optional) command console to see what commands the GUI is sending to and from the CUI. That way you can learn or paste from the CUI (console) for when you need to automate some or most tasks, AND build your own customized GUI as needed. It would be natural to switch back and forth and to mix and match. It just takes good road-te

  • Depends on the CLI and the GUI (Score:3)

    by barc0001 ( 173002 ) on Monday October 28, 2019 @04:16PM (#59356106)

    Not all firewall GUIs suck and not all CLIs are paradise. Each can be downright hellish to work with if poorly designed, or a pleasure to work with if designed well.

    Same as anything really. I've seen great CLIs for setting up RAID cards, and awful non-intuitive GUIs for RAID cards (looking at you LSI...). The relatively recent motherboard push to GUI for BIOS setup shows there are definitely winners and losers in the UX design by different manufacturers as well.

    Bottom line if it is designed well, it will be a pleasant experience to work with. If it's poorly or carelessly designed, you're going to hate it.

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      The relatively recent motherboard push to GUI for BIOS setup shows there are definitely winners and losers in the UX design by different manufacturers as well.

      Not really a good example, since most BIOS Setup programs (when they started building them in were menu driven. (Remember the IBM PCs required booting a special disk in order to configure the system, or flipping DIP switches if the change you made was needed before POST)

      Menu driven UIs are a sort of predecessor to GUIs since they often encompass the

    • "The relatively recent motherboard push to GUI for BIOS setup "

      I do not think I have EVER seen a CLI interface for BIOS configuration on a PC. Even the original IBM PC used a GUI. I think you are confusing a GUI with a WIMP interface. BIOS configuration interfaces that used to be FAST keyboard text-based GUIs are being replaced with SLOW WIMP graphical GUIs. Just because. Even though they are slower and more difficult to use.

      • > I think you are confusing a GUI with a WIMP interface.

        Agreed. I was thinking more the transition from a text menu driven 100% by keyboard to this new mouse-driven paradigm. Although I would still argue that they WIMP is not a GUI any more than a CLI is, as it's all still just text on a screen, albeit nicely arranged. The new BIOS screens on the other hand...

        https://phoenixts.com/wp-content/uploads/2016/07/UEFI-e1468002142999.jpg

        definitely a GUI. Complete with logos.

  • "...system administrators tended to prefer and use firewalls more than CLIs."
    Was this article about CLI versus GUI or about CLI versus firewall. How is a CLI a substitute for a firewall?!?

  • The really interesting part of this to track is that API+Other column being a not trivial 8.6%.

    I haven't used either a gui or CLI to manage a firewall in years. It's Terraform, Ansible, Puppet, Chef, all the time.

  • I would be more interested in the breakdown of those admins that were self taught verses those that took the career path because they were told 'computer science is where the money is', and how it correlates to preference of CLI vs GUI - if at all.

  • ... bears always face to the front.

  • Command lines are linear in nature. You type a command, and get a list of results, then another command, and another result. Each line in the terminal represents a command or an element of response, more or less. A line is above or below another line, but there is nothing on the left or right, and it only goes down, you can't change wha'ts above.

    It is very limiting in term of interaction. With a GUI, you can go in all 4 directions, open sub-menus, have many things happen in parallel, etc... You can even go

    • Re: (Score:2)

      by nyet ( 19118 )

      Good luck keeping GUI actions in SCM, or replicating them across dozens of instances.

  • Then use whatever tool you want to mange the content.

  • Comment removed based on user account deletion

  • I won't argue with the statistics from the study, but the author gives a clue about how much his conclusion is worth.

    " In hindsight, it is pretty hard to get things wrong in a firewall GUI."

    Obviously, regardless of the statistical chops of the authors, they do not have any actual hindsight that applies to firewalls. I personally use a GUI for configuring/maintaining a firewall stack which is also doing internal routing. Primary reason is the CLI on this particular firewall really sucks. The GUI isn't great,

  • CLI has major advantages (Score:3)

    by Crypto Gnome ( 651401 ) on Tuesday October 29, 2019 @10:23AM (#59358442) Homepage Journal
    Sure pointy-clicky is EASY , but you lose so much by not using the CLI.

    Once you drive your network devices via CLI you are empowering the Infrastructure-As-Code methodology.

    Everything (yes even your router, firewall, load balancer, switch) can be configured by the CLI, via copy-n-paste interactions from A Text File.

    Which means
    1) The Change File is an exact , complete and literal descriptions of the change being applied
    2) Changes can be stored in Version Control (of your choice)
    3) Changes can be easily audited (see item #2)
    4) Change is easily managed to conform to standards (yours, mine, NIST, CIS, etc)
    5) When necessary, reversing the change is MUCH easier (due to #1 and #2)

Slashdot Top Deals

Whoever dies with the most toys wins.

Close