[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Scalable Debian vulnerability tracking



-----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.

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.

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-----


Reply to: