Hello Sheldon,
On Tue, Jan 6, 2009 at 21:34, Sheldon Hearn <[email protected]> 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 [email protected] > with a subject of "unsubscribe". Trouble? Contact > [email protected] > > Best Regards, -- Jonás Andradas Skype: jontux LinkedIn: http://www.linkedin.com/in/andradas GPG Fingerprint: 5A90 3319 48BC E0DC 17D9 130B B5E2 9AFD 7649 30D5 Keyservers: wwwkeys.eu.pgp.net | pgp.rediris.es
