Linux Netfilter discussions
 help / color / mirror / Atom feed
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





  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