[Osiris-devel]osiris version 2.0 goals and considerations

[Aaron Racine]

Hi.  I just recently subscribed to the list and started reading the
archives.  I'll throw my comments on the general goals/considerations
inline.

On Fri, 9 Nov 2001, gdead said:

# [pitch]In the "making it braindead to use" category, most folks
# won't start with a good baseline for most machines.  I think the
# Unified DB of Known MD5's is a good way to solve this problem....
# However that's a project in and of itself.... Should we try and
# bunch that together with osiris in 2.0?  Or is that more long term?
# Or am I smoking crack?

Whoa, feature creep! =)  I would think this should be a separate
project and more long term (or 2.0 would never be released ;),
although maybe it deserves some skeletal code in osiris to support
baselining in the future?  BTW, Sun already has a DB of Known md5
hashes.  I believe it's only a one-way mapping of md5 hash ->
/path/to/binary, though:

  http://sunsolve.sun.com/pub-cgi/fileFingerprints.pl

Unfortunately, they don't distribute the db.  Is there sufficient
value in an interface to their cgi script to justify the work?

Maybe the way to address the baselining issue is to get OS dist.
maintainers to create Osiris baselines and distribute them with their
distributions.  Osiris would have to be pretty popular before they
would start doing that, though, so initially maybe a group of Osiris
supporters could take the time to install new distributions and create
baseline db's for everyone to use?  Just my $0.02.

# > - central host managing and storing databases and configurations.
# >
# > There are many arguments for this, few against it.  The
# > biggest problem
# > being that all of this data might have to go across the
# > network periodically.
#
# Bandwidth is cheap, esp in a datacenter.  I can't believe the amount
# of data that flies around my network due to Tivoli and HPOV.  This
# shouldn't be much of a problem

I agree.  Organizations over-estimate b/w needs anyway.  They all
think they have the next killer app/service and that there will be 10x
as much b/w as there really turns out to be =)  One exception may be
universities, which can usually consume as much b/w as is given to
them.  I don't think you should worry about b/w a priori.

# Ideally the connection between client and server will be "proper"
# bi-directional auth'd SSL (complete with CRL checking).  Regardless
# of if it's in or out of the public Inet.

Amen to that.  Assume all networks are hostile.  In fact, I would
argue that the edges are where the high risk is, not the core (e.g.
Internet), but I won't get into that unless someone provokes me =)

# > - OpenSSL for all encryption and authentication methods.
# >
# > a lot of discussion will need to take place to make sure this is
# > done correctly. What about OpenSSL support on platforms like
# > windows.  Has entropy gathering become usable for this type of
# > product on this platform yet?
#
# Entropy is overrated ;)  seriously, we should be able to leverage
# other OSS projects that deal with making good sources of entropy to
# kill this problem (if it's a real problem).

Have you considered packaging stunnel [www.stunnel.org] with Osiris
instead of re-implementing ssl functionality?  It seems to be meant
for pretty much this exact situation, and it runs on *nix and Windows
(comes with a couple dll's to install, which the author claims are
from the default installation of openssl).

# > - protocol suitcase for talking to various devices/hosts.
# >
# > routers are the main issue here. We talk to our own code
# > otherwise.  What
# > will be the functionality we want out of this, just grabbing
# > the config?  More?
# >
# I'm all for generic protocol interfaces that are agnostic to the
# underlying device... For those who shot the shit on FEMA, this
# should sound familiar.  We need to put some thought into this.  At
# this point, I don't know if it's feasible.

I agree that generic interfaces would be ideal.  One comment on
getting info from routers (or networking infrastructure in general) is
that it seems like a different model than the main client-server
design.  Unless you're talking about a Juniper router, you're not
going to be running an osiris client on the network infrastructure.
Would you have a special client that would be responsible for querying
the infrastructure, or would the central host be responsible for that,
or... ?

To address Brian's original question, I think you'd be pretty safe
with grabbing the running config and the nvram config (talking about
Cisco's here, obviously).  An intruder could still cause trouble
without changing the config, but I don't see what Osiris could do to
help detect that sort of thing (e.g. clearing a bgp neighbor).  There
are other ways to address those issues, anyway (like command logging
w/ tacacs).


Is there a way to get access to the development code (cvs/webcvs), or
is it pretty much closed-devel w/ the list being to discuss devel
ideas?

Regards,
Aaron

P.S.  R.I.P. FEMA