From: Vadim Kurland <vadim@vk.crocodile.org>
To: netfilter@lists.netfilter.org
Subject: Re: inner workings of IP tables
Date: Sun, 29 Sep 2002 20:16:56 -0700 [thread overview]
Message-ID: <3D97C228.6030602@vk.crocodile.org> (raw)
In-Reply-To: Pine.LNX.4.40.0209292103480.19136-100000@klepto.security.algx.lan
Kevin Dwyer wrote:
>>At least with a CLI you're in full control, even if you need to learn
>>a bit more syntax before you start typing.
>>
>>
>
>Precisely.
>This is seen as a drawback to some people, because you are given the gun
>with which to shoot yourself in the foot. However, I'd prefer to have a
>competent firewall admin over a point-and-click lemming.
>
>
>
I would like to assert that in the case of CLI we are just as like in
the mercy of a vendor who may or may not implement interfaces to certain
features of underlying software. I prefer to think of these components
as layers of different level of abstraction and access: first, there is
TCP/IP stack, then a set of hooks and kernel functions, then perhaps a
CLI tool to configure this stuff and on top of that may be a GUI. This
is rough and inaccurate model which I have here just to explain my
point. Each level needs to be implemented and while doing so certain
features of underlying levels may get dropped by various reasons.
Cluefullness of firewall administrator has almost nothing to do with a
type of user interface firewall he prefers to use. Like we never saw
wrong firewall configurations done in iptables, or in ipfilter, or PIX
using their CLI. In the end, what matters is how much time one needs to
spend building rules and verifying them, and what is the proprability of
an error still slipping through. Anything that can help reduce this
probablility is useful, even if it is a GUI.
Another reason is this: what if you have a staff and need several
engineers to be able to work on the same policy at different times?
Again, anything that can make this policy look uniform and
understandable is useful.
I agree that interface does induce certain model and makes us think of a
subject in a certain way... That is of course true and choice of good
unterface, both CLI and a GUI, is a difficult task. But this is a
different interesting topic, which can be far more scientific that
religious war of CLI versus GUI.
--vk
next prev parent reply other threads:[~2002-09-30 3:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-28 14:11 inner workings of IP tables Naleendra
2002-09-29 9:19 ` Antony Stone
2002-09-29 19:05 ` Mitesh P Choksi
2002-09-29 19:30 ` Antony Stone
2002-09-29 23:37 ` Kevin Dwyer
2002-09-29 23:52 ` Antony Stone
2002-09-30 1:11 ` Kevin Dwyer
2002-09-30 3:16 ` Vadim Kurland [this message]
2002-09-30 13:21 ` Kevin Dwyer
2002-09-30 13:36 ` Antony Stone
2002-09-30 17:34 ` Vadim Kurland
2002-09-30 17:49 ` Matthew G. Marsh
2002-10-01 5:51 ` Julian Gomez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D97C228.6030602@vk.crocodile.org \
--to=vadim@vk.crocodile.org \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox