On Tue, Jan 6, 2009 at 21:34, Sheldon Hearn
<sheldonh@starjuice.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi folks,
I work for an hosting provider, and am looking at how to improve
visibility into vulnerability exposure.
We have over 800 Debian hosts that we manage fore customers, and will
have over 1,000 by the end of this quarter.
A major problem we face is that our change distribution mechanism is
poor. We're working on that problem, but in the meantime, I'm looking
at ways to assert that we are / are not vulnerable to specific issues
disclosed by the Debian project. I realize that this isn't the whole
game, but it's an huge part of it.
First prize is a web application that we can draw reports from (or will
push reports to us or whatever), that knows what security issues have
been identified and addressed by the Debian project, what versions of
packages are installed on all servers, and therefore which packages on
which servers should have been upgraded but have not yet been.
Yup, basically the output of debsecan --only-fixed --suite etch. But
I'd prefer not to use email as the transport mechanism (unreliable),
and I'd have to write an aggregator for all those mails, because
working through mail from over a thousand servers is error prone.
If you can modify the mail system of each host, you could create an exim4 router and transport that will accept mail for a local user (lets call it "SecMonitor") which would pipe the output of debsecan to a script (be it shell, perl, python or anything you choose). That script could determine if any action is needed or not and then send it to a central server, as you propose below. Or you could just let debsecan e-mail it to the central server, and have there a similar script as above, which would update a local database or similar which could be used to display the desired results. It could even trigger alerts in case something is really wrong. This way, you would not have to go through thousands of daily/weekly e-mails, since it would be automated, but through the results. There could even be a "timeout", and if a server does not report its debsecan output in a regular fashion, it could be inspected manually, and thus eliminate the unreliableness of e-mail (I find e-mail much more reliable than syslog; if an e-mail message cannot be delivered, it queues, while a UDP message that is not received is lost forever without any notice).
So I imagine a solution involving:
* a web service to which servers can basically post their dpkg status,
* a feed consumer for DSAs,
* a vulnerability resolver that matches these two data sources,
* reports to provide a view into the persisted resolver results.
I spent a lot of time hunting for such a thing, and haven't found one
I'm happy with. I'm not keen on using Nessus for this, for a few
reasons:
* I don't think it's an hosted application with persisted results
(i.e. you have to initiate a full network-wide test every time
you want a report).
* The Tenable sales people are useless.
* I don't think their feeds are worth the money.
OpenVAS would address the last two, but I can't recommend it in
production on Debian Etch or Lenny yet, and there's still the matter
that it's not an hosted application with persisted results.
Regarding OpenVAS, there is an option for performing Debian local security checks, which are updated via the NVT feed. In order to perform these local security checks, you only need to create (or re-use an existing one) on each host you want to monitor, and configure the OpenVAS-client to perform only the Debian local security checks. In this way, you could have the whole list of servers in a scheduled analys that will return you reports.
So I'm hoping for one of:
* Someone points me to an existing app, I bow my head in shame, admit I
have no Google Fu, and avoid reinventing the wheel.
* Someone points out how wrong I am about Nessus and suggests how I
might re-educate myself (hint: I _have_ actually installed and played
with it).
* I go ahead and implement the solution proposed above. I'm confident
that my employer would be keen on release under a DFSG-compatible
license (probably MIT, since I'd be using Ruby).
I have a handle on every aspect of the solution except for one: the feed
consumer for DSAs.
I've reverse-engineered debsecan, and mostly have my head around the
security tracker's suite feeds. I'm talking about the feeds available
at URLs like:
http://secure-testing.debian.net/debian-secure-testing/project/debsecan/release/1/etch
I just need some clarity:
* I'd have to consume feeds for multiple suites, (because we use
backports and volatile), and would have to do some version munging to
deal with things like ~bpo in versions. I could get package suites
with something like apt-show-versions. Am I on the right track here?
* I get what the etch, lenny, sid suites are for. What's in the GENERIC
feed?
* There are fields in the feeds that debsecan calls "unstable_version"
and "other_versions". As I read the code, a package is vulnerable if:
pkg_version < unstable_version
pkg_version == any of other_versions
This seems unlikely to me, and I suspect I've misread the code. Can
someone clarify?
Again, to be clear, I realize that we need to work towards update policy
and mechanisms that guarantee that security updates are applied
automatically and in a timely manner. We're working on that, but it's
going to take us time. And even once we're done, we'll still want a
vulnerability tracker for some time thereafter, until we're confident
that things are running smoothly.
So any suggestions on how to implement scalable Debian vulnerability
tracking in the interrim would be greatly appreciated.
Thanks,
Sheldon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD4DBQFJY8BUpGJX8XSgas0RAlrWAJ9/PubX5OTma2DwbPy+NfUcR8k7xQCVHR3w
Dsk1udom6T+JZzDX0Y86LA==
=tdtx
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org