Re: Scalable Debian vulnerability tracking
In gmane.linux.debian.devel.security, you 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.
>
> 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?
[..]
> So any suggestions on how to implement scalable Debian vulnerability
> tracking in the interrim would be greatly appreciated.
Hi Sheldon,
that sounds like an interesting project. Thanks for the intent to
share and to provide your possible solution it to the public!
For an environment the size of yours I'd recommend to implement a Nagios
plugin, which checks the local state of installed applications against
the data from the Debian Security Tracker, which is also used for debsecan.
The Security Tracker URL is http://security-tracker.debian.net/tracker/
The whole data is available in SVN under svn://svn.debian.org/secure-testing/
(don't let you be fooled by the name, it also applies for stable and
backports.org, the repository name is due to historic reasons).
All the data is below data/, the code to parse the data is below
lib/python/ and bin/. The existing scripts should provide an easy
base to build upon.
Beware that there might a some false positives, all data in debsecan
and the Debian Security Tracker is initially flagged as vulnerable
for stable-security unless it's properly validated or fixed, so it
can happen that a package is marked as vulnerable for Etch, which
is actually safe. We have an extensive HOWTO on how the Debian Security
Tracker works:
http://svn.debian.org/wsvn/secure-testing/doc/narrative_introduction?op=file&rev=0&sc=0
If you want to amend/correct data, please send mail to
debian-security-tracker@lists.debian.org. (This is also the mailing
list for followup questions on the Tracker or the code)
There are also people available on the OFTC IRC network on #debian-security
who should be able to help you out.
BTW, the Debian Security Tracker also provides a view for backports.org,
see http://security-tracker.debian.net/tracker/status/release/stable-backports
Cheers,
Moritz
Reply to: