Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Vadim Kurland <vadim@vk.crocodile.org>
To: Kevin Dwyer <Kevin.Dwyer@algx.net>
Cc: netfilter@lists.netfilter.org
Subject: Re: inner workings of IP tables
Date: Mon, 30 Sep 2002 10:34:09 -0700	[thread overview]
Message-ID: <3D988B11.2020107@vk.crocodile.org> (raw)
In-Reply-To: Pine.LNX.4.40.0209300905060.19596-100000@klepto.security.algx.lan



Kevin Dwyer wrote:

>>    
>>
>I think you're right, with the exception that the CLI in question here is
>usually a shell (unless someone has built their own thing on top of it --
>I'm only referring to netfilter as it is distributed freely) and usually
>has a text editor available, which gives you the means to adequately
>modify any ruleset without needing a graphical workstation, given you are
>familiar with typical unix commands (which you ought to be if you are
>going to be administering a netfilter firewall).
>  
>

I see. I meant the set of command line options for "iptables", which is 
CLI in this case. Even someone who is very good at shell, vi etc. may 
have no idea about relationship between chains and tables, not to 
mention modules and their parameters. Firewall administrator thinks in 
terms of addresses, packets and protocols, but CLI in this case exposes 
details which are too low-level. This makes learning curve longer, which 
increases the risk.

>So if you do use a GUI like fwbuilder for generating rules, you get the
>advantage of a visibly clear ruleset and damage control when you're
>partying in Hawai'i but the boss calls unexpectedly saying they need a
>special quick fix change implemented.  This is not the case with the CP
>GUI, as experience has shown.  It's the _option_ that I find most
>appealing, I suppose.
>  
>

I do agree very much here. My goal is to find a fine balance between 
high level of abstraction and ease of use of the GUI and maximum control 
that experienced administrators want.

--vk




  parent reply	other threads:[~2002-09-30 17:34 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
2002-09-30 13:21               ` Kevin Dwyer
2002-09-30 13:36                 ` Antony Stone
2002-09-30 17:34                 ` Vadim Kurland [this message]
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=3D988B11.2020107@vk.crocodile.org \
    --to=vadim@vk.crocodile.org \
    --cc=Kevin.Dwyer@algx.net \
    --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