[nzlug] Firewall ruleset check...

[Daniel Pittman]

Steve Holdoway <steve at greengecko.co.nz> writes:
> On Wed, 14 May 2008 19:05:26 +1200
> Cliff Pratt <enkidu at cliffp.com> wrote:
>
>> Why re-invent the wheel when you can use someone else's expertise.
>
> <hobbyhorse>
> Because if you actually understand what you're doing, then you'll do a
> better job. 

I would argue that this is true only if you say:

    Because if you actually understand what you are doing *better than
    the developers of the firewall tool* then you'll do a better job.

If you are not as good as the people building an upstream solution, or
if you don't have as much peer review, or if you are misinformed of the
capabilities of the tool then you may well do worse.

On the other hand, yes, you may do better.  Understanding the tool, and
the situation, is necessary -- no blanket statement is ever going to be
universally true.

> I doubt that the iptables developers were intending to make their
> solution as difficult as possible to understand - I suggest that it
> was the exact opposite, and their solution is as simple as it could
> possibly be.

I don't believe that simplicity is the sole axis on which to judge
iptables, or a wrapper around it.  Furthermore, I don't believe that
there is a *single* axis of simplicity.

For example, I would suggest the iptables developers designed their tool
to be as correct and simple as possible *from a kernel implementation
point of view*, rather than focusing on a simple user interface.

> These gui tools won't provide the flexibility of the underlying
> product, 

I don't believe Cliff suggested a GUI tool, but I certainly wouldn't.  
I do agree with his recommendation, however, that you use something that
wraps around iptables rather than using the raw commands directly.

> and relying on them can foster a lack of understanding of the problem
> and the tools available to solve it.

I certainly agree with this, in general.  On the other hand, at some
point you need to make the call that there is a worthwhile trade-off in
your knowledge of the underlying tools vs the high level wrapper over
them.

> I'm a fanatic believer in KISS, but in order to implement that
> approach, it's imperative that you have a good understanding of the
> technology involved. 

I don't believe that is true.  In order to keep your solution simple it
is necessary to keep your solution simple; it may help to understand the
technologies, but it is not always necessary.

In any case, at least in the area of firewalls, I would strongly suggest
that writing out the equivalent of my current firewall by hand is going
to be a lot less simple than building it with a helpful wrapper.

(That would be ~ 700 lines now, down from the ~ 1,750 it used to be when
 I had a couple of other network blocks here and ran a few more
 services.)


Oh, and I /strongly/ believe that when you look at simplicity you should
look at the total picture of what you have to build: it is probably more
work, overall, to design a secure firewall *and* build a solution that
effectively and safely implements that.

Trivial features such as "try" mode where you can safely remotely modify
the firewall configuration, for example, sound seductively easy to write
yourself and can be non-trivial.  They can, however, greatly reduce the
complexity of managing the firewall.

> I do not equate the availability of a gui tool with that knowledge.

That is your prerogative.  It is worth considering, though, that writing
off /any/ class of solutions in a stroke will necessarily result in your
having less chance of identifying the best solution at some stage.


> It's like the age old ( well in *nix terms ) question... what's the
> best programming language? C. Why? Because you can do anything with
> it. OK then, what's the worst programming language? C. Why? Because
> you can do anything with it.  

Hmmm.  I am not quite clear what this is intended to illustrate, but to
use my favorite programming language comparison here:

Using iptables directly is, in many ways, comparable to programming in
assembly language.  You may achieve a faster or better result -- but
most people choose to use something higher level because it reduces the
costly part (developer time) and reduces errors.


> </hobbyhorse>
>
> So I say, keep on with your current approach, make loads of mistakes,
> understand what you did wrong, get it fixed, and only *then* use the
> shortcuts that make life much easier.
>
> Sorry, but after pushing 25 years of looking after computers, I see
> the same basic mistakes made time and time again, and usually because
> corners have been cut in this way. I'm sure you've seen the same,
> being at least as old as me!
>
> IMO, the hard yards need to be travelled (:

Inevitably, at some point, you need to learn.  I believe, though, that
the idea you can only learn by doing things the hardest way possible is
incorrect.

(Er, and yes, that does come from well over a decade and a half of
 experience with computers, for what that is worth.)


Some people learn wonderfully well that way, but others don't -- they
learn best starting with something high level and working down.  Others
learn best from a book, others from practice, and so forth.

Regards,
        Daniel