[12733] in bugtraq
Re: Operational Issues: Applications & Appliances (was: Buffer
daemon@ATHENA.MIT.EDU (Mark Seiden)
Fri Nov 26 02:31:54 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <19991124094003.C2096@seiden.com>
Date: Wed, 24 Nov 1999 09:40:03 -0800
Reply-To: Mark Seiden <mis@SEIDEN.COM>
From: Mark Seiden <mis@SEIDEN.COM>
X-To: Crispin Cowan <crispin@CSE.OGI.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <383AF822.275BCCFE@cse.ogi.edu>; from crispin@CSE.OGI.EDU on Tue,
Nov 23, 1999 at 08:25:06PM +0000
right you are. it's a problem for both firewall and vpn products, and
our consultants see this frequently in the field when doing network
assessments.
most of the vendors try to control the environment by taking the
traffic to their own processes (sometimes in the kernel, often in
userland), which can do proxying or stateful inspection. (sometimes
these processes have even been statically linked.) (they think this
limits the size of the exposed target to a productive attack -- as
opposed to a denial of service).
when you ask an architectural question
"what services provided by the OS do you rely on, and for what, exactly?"
very few software companies have prepared or documented an answer to
this question, and without open source you can't answer it yourself.
we are left to wonder if they even *know* the answer, which doubtless
changes for each dot release of each firewall product.
in practice:
many of the vendors try to document their way around the problem.
e.g. they have a big section in their administration manual or on the
web site about securing the operating system before doing the
installation, prerequisite patches and the like.
usually, on unix, they turn off services by replacing /etc/rc* and
inetd.conf, and most of them add a packet filter (as a kernel driver)
which limits traffic to ports running known services, often provided
by the vendor.
seldom do they replace key binaries (e.g. named, sendmail).
seldom is there a mechanism for maintaining trust in key binaries
or configurations (e.g. tripwire).
areas of concern i've noticed include:
- reliance on naming services (like dns)
- how logging is done (syslog, nt event logs, proprietary logs etc).
- management tools provided by hardware vendors (running snmp)
- mystery users running processes
for firewall products running on NT, this is a much bigger mess, since
any sort of installation script would be taking the operating system
from one unknown state to what is merely a different unknown state.
given a random installation done by some reseller of the product,
what can we do after the fact?
you can't trust the gui, in my experience. you have to look at the
text output of the gui, which represents the rules and definitions of
objects such as trusted networks which are what is actually loaded by
the bits that do the actual work.
you look at netstat and services running, scratch your head (who's got
*that* port open?), try to find some analog for lsof on NT (please
tell me about your favorites), run scans against the firewall, and ask
the vendor:
"which of these services MUST be left running on NT lest the firewall
stop working?"
it usually isn't documented, and you get crappy off-the-cuff answers,
in my experience. (then you go through a painful dialog: "now, tell
me what you use the rpc service for. tell me why i have to run the
microsoft dns service on an nt firewall, rather than relying on
another dns. tell me what this user with a predefined password is
for... yes, i know compaq insight manager comes on every compaq
machine, but...")
it's painful partly because it's hard to find the people at the vendor
to answer the questions, since the support people are not the
programmers, and even when they answer a question about how it needs
to be to continue working, they don't know how to answer the question
"why?" and refuse to say "i don't know but i'll let you talk to someone
who does".).
to reduce radius exposed to attack, you're forced to practice computer
science as if it were experimental brain surgery: lobotomize some
services, and see if anything noticeably breaks. (taking comfort only
in binary search converging in log n time.)
On Tue, Nov 23, 1999 at 08:25:06PM +0000, Crispin Cowan wrote:
> I'm rather amazed at the existance of the firewall *application* market, where
> you buy a firewall product and install it on one of your server machines. How
> can such an application install take a pre-installed machine from an unknown
> state to a secure state? Does the install script for (say) Checkpoint do
> extensive configuration checking and adjusting? Or do they just assume a very
> competent sys admin puts the machine into a "firewall" configuration?
>
--
mark seiden, mis@seiden.com, 1-(650) 592 8559 (voice) Pacific Time Zone
or mis@securify.com.
