Re: Teaching Firewalls (was: Firewall for Pedagogical Purposes)

["Marcus J. Ranum" <mjr () nfr net>]

> > For teaching, I'd think it far more important to teach (just an
> > off the cuff list):
> > - TCP/IP and how it works
> > - Filtering techniques (and why);
> > - Various (common) protocols and their weaknesses and strengths.
> > - Monitoring techniques (with IP security issues in mind)
>
> these are all important foundations in learning to secure your system.  in
> fact, each _good_ system administrator should know about these much more a
> security consultant (and other titles). but one would question as to the
> depth of teaching these @ a particular length of time and how. 

One of the problems I have with firewalls is that it's really
hard to know what to let in and out of a firewall anymore. If
you teach how to build a firewall and don't teach people how
to assess the risks of various protocols, you've just taught
them how to build a typical "feel good" firewall.

I think it's essential (as said above) to talk about various
protocols and weaknesses, but you need to cover WHY protocols
are weak and WHY they are strong and then HOW to identify
which are which. This is a hard problem.

When I do tutorials on Internet security these days I focus
on the hard problem of how to reason coherently about connectivity
between groups of machines. It's a thing I call (for lack of a
better phrase) service-oriented requirements analysis. Basically
what you do is assume different roles of computing have
different security properties and then, based on those properties,
mapping the amount of connectivity that you need to get the
job done. I won't go into details here (mostly because I don't
have time to do a 15 page writeup) but I'm not even convinced
it works -- because EVERYONE has flat network topologies (security
wise) and nobody is going to redesign to a segmented multi-domain
network just for security. The other problem with treating things
as separate domains and mapping connectivity is that you are
dealing with a cross-product matrix of properties, which means
you have states equal to the square of the number of domains.
Gets unwieldy very very fast. :(

Anyhow, the problem is that it's useless to build a firewall
until you have learned how to reason about perimeter security.
And nobody has figured out how to do that, yet. So that leaves
things kind of in limbo. I felt, after a while, like I was not
even helping by teaching how to build a firewall. :( Now I
teach how to design a firewall -- a different process, really.

> as such, teaching firewalls would only a subset of a full security course
> that would span for quite some time but would not be continuous in the
> sense that _students_ would be allowed to gain the prerequisite experience
> before going to the next level. 

Nobody has time. If you're a "real" network admin you're too
busy to focus 100% on security. If you're a full-time security
person you're either too busy fighting fires and political
brush-wars or you're too busy punching holes in your firewall
because you lost some political battle and someone ordered
security taken down "for convenience."  The problem is that
security is something you can spend a lot of time on and the
technology is changing so FAST even full-time pros can't keep
up.:( I've been doing the management thing for a year now and
I'm totally obsolete already.

> > I offer this because I have cleaned up firewalls set up by "trained"
> > people who shouldn't pass a CNE test, who shouldn't be an SA.  To

Interesting point!! I've had similar experiences. It turns out
to me that there's seldom anything wrong with the firewall
itself -- it's usually that the policy the firewall is configured
to enforce doesn't make sense. ("permit no traffic in except for
in-the-clear telnet to the mainframe" !!)  I keep coming back
to the realization that the firewall is just a tool that needs
to be wisely employed -- and wisdom is in short supply.

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr