Re: Securing a Linux Firewall

["R. DuFresne" <dufresne () sysinfo com>]

On Fri, 26 Jul 2002, Stephen P. Berry wrote:


        [SNIP]

>       -The list of Bad Things gets long in a hurry
>       -Call the size of your list n.  The set of all Bad Things running
>        around in the wild is always at least n + 1
>       -It ain't really what you want to do.  Nobody really wants to allow
>        just any damn thing to happen on their networks.  

This is very dependent and in many cases untrue.  Too often the business
model is to allow far too much; the CEO wants to read e-mail off another
site, management wants to use IM/ICQ/etc, different businuss groups want
to play with whiteboarding in netmeeting, the list goes on...  The mjor
problem is the toys and protocols in use are underpar.  Thus the recent
thread on proper coding and the worthiness <or lack thereof> of code
auditing.  Additionally there are Marcus' rants on a need to rewrite most
protocols from the ground up to fix the issues of security.  All else is
wedging and remodeling.


>        Put another way, the
>        list of Bad Things will always be a proper subset of things you
>        don't want happening on your network---the other elements being
>        things in your acceptable use policy, the contents of relevent RFCs,
>        and all sorts of other things.  In order for a network to function
>        things have to behave in fairly specific ways, and even an exhaustive
>        list of exploits du jour doesn't cover all the ways a network
>        can fail to do so

Far too many organizations do not have a properly defined, if they have at
all "acceptable use policy", concerns relating to such are common
questions to this and the firewall list.  Few organizations that try to
impliment an "acceptable use policy" have the balls to enforce it.  The
main issue there being management buy in, which has remained an area of
critical discussion for years in the firewals list also.  Remember <see
above>  management is most often the key factor in wanting to circumvent
safety/security precautions.  Management tends to buy into marketing hype
far to easy, and want the latest and greatest toys to play with <e.g. the
wireless mess now rampant in various organizations>.


> The above applies pretty much equally well to host security:  Your list
> of Known Bad Things will grow rapidly; your list will always lag behind
> evildoer developments;  and your list won't cover all the behaviours you
> don't want happening.


We're still in perimiter mode, individual host security, on the inside and
often on the DMZ's is lacking, and often just totally non-existant.  As
Marcus, and I'm sure others have expressed here in a number of ways, as
well as in other forums, few organizations really know what's passing
about their network cabling.


> If you build a minimal install of the OS, you're not really creating
> a Known Good list of binaries, devices, libraries, or whathaveyou.  You're
> creating a list of the things -necessary- for providing some particular
> function.  In you define what is necessary and eliminate everything
> else you are in fact defining a system with the minimum exposure (given
> the OS, platform, and so forth).  That's the motivation---tagging
> a minimal install as Known Good is an act of hopeful optimism that I
> couldn't condone, but I routinely build miminal installs because I'm
> interested in managing risk.

What Gaspar and others are trying to convey, this works well with single
boxen nad or minimal setups, but scales poorly when dealing withmass
pushouts of various differening OS builds on a larger perspective.  Take
this in consideration of host issues you mention above.  Trying to keep up
with "known good and working" for each OS and HW platform and you tend to
need a whole department broken into OS/hw groups to maintain proper builds
and images to spew onto new systems, not to mention the group responsible
for hitting all production boxen for upgrades.  When this spreds with an
organization that is geographically complicated to manage and maintain,
like say Nortel, having LANs spread across the globe, well the issue
becomes a nightmare of  proportions.

I worked with such a group of 4, charged with auditing and bringing into
complaince over 800 servers in the unix realm into corporate security
guidelines.  The systems had various OS/HW layouts of various versions of
each, all across the globe, and new systems were spewed into existance
daily, often without the knowledge of change manangement or any other
group charged with the ntwork infrastructure, certainly without the
blessing and rituals of the security groups <yes, we were as complicated
as the US gov was recently seen by the GAO, with disparrate groups
functioning without a clue of what the other groups were tasked to
accomplish>.  The problem with getting a handle on the nightmare at our
fingertips was complex, in management <change management can be a pain in
the backside when trying to push out critical upgrades in a timely manner>
perspective and further complicated by a systems group over burdened to
the point of not being able to keep up with the most recent hanges and
fixes for the various OS/HW platforms, let alone have a handle upon older
OS/Hw under their domains.  We'd audit a set of systems, get them up to
speed, one of them would crash, and the restore, if possible would undo
all the work we'd done, or worse yet, if the system had to be rebuilt,
well, the idea should become plain here.  Just the task of unrolling and
mandating that all system admin chores be conducted by ssh1 caused so much
suffered whining and crying over the difficulties now increased upon admin
staff upset their web surffing time had been reduced for the immediate
future to nill was a social-psychology phenomina to witness.  Scaling
these chages and audit fixes took a grand amount of resources, and getting
them to stick over time was a continuous nightmare ot maintainance.


> I'm also fond of tricks and traps, and having a minimal install as a base
> makes deploying that sort of thing much easier.  If you know, say,
> that ls(1) isn't being used by anything involved in the legitimate
> operation of the system, its use is a simple and unambiguous indication
> that something's amiss.
>
>
> I won't tell you that it's -easy- to build a bare minimum install of an OS.
> But it ain't -hard-, either.  And hopefully you're not swapping OSes
> capriciously, so once you develop a pared down distribution, chances are
> it's going to last you awhile.

And yet maintaining that level of known good bare minimum over upgrades
and version releases, let alone patch fixes and such can be a tasking
issue.  On a small scale, for single systems it's a no-brainer, but,
getting this to scale is another matter altogether.


Thanks,


Ron DuFresne
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        admin & senior security consultant:  sysinfo.com
                        http://sysinfo.com

"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
                -- Johnny Hart

testing, only testing, and damn good at it too!

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards