|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical summary (Re: how to get people to upgrade?)
in addition to many public comments (cc'd to nanog or just sent there),
i received a number of private replies. here's a representative sample:
> problem is if the default is off you will probably not catch the
> clueless folk that you want to target, better would be default on and
> the clueful world can choose to ignore it...
>
> btw, my impression of the vulns in earlier binds was that everyone who
> mattered had upgraded and perhaps only corporates were left on old
> version, of course you prolly know more than me on that.
pv: (the roots and most tld servers always update, and the vendors
always have patches, but by no means everyone who matters always
upgrades.)
> I'd certainly consider using a service offered by ISC on this basis for any
> servers for which I have any responsibility.
pv: (four other people said the same; thanks for your enthusiasm! one added:)
> ... However, since the problem applies to multiple software packages,
> perhaps it is worth the effort developing a unified standard for this
> kind of purpose (RFC, something similar) and passing it on to package
> maintainers, distribution maintainers, etc? Creating a universal
> "versioning system" would solve a lot of problems with keeping software
> updated.
i think that's true, but beyond the scope of ISC's resources, and also
likely to take a very long time to settle. interestingly, since it's
a protocol, the ietf should care, but since it's about software, the
ietf probably won't care.
> In my experience people are perfectly capable of shutting their eyes for
> the need to upgrade. Harrassment by e-mail won't change much there.
pv: (this is interesting, since it represents the prevalent view here that
just because people want the functionality that some software provides,
does not imply any commitment to keeping it from being used as an entry
point for an attack nor launch point for attacks on others. this should
have been obvious but i'd never thought about it that way before today.)
> 1. I have another idea though, during setup of the server ask for email
> address of list administrator, but keep that on the server itself.
> 2. Setup some dns server that provides dns record if there are necessary
> updates (here is one example in reverse dns notation...:
> 1.2.9.bind.updates.isc.org and set it to particular ip or
> particular MX or whatever to show if update is needed).
> Possibly have this special update dns recorb be HINFO to url where more
> information on update is available.
> 3. When bind starts if the record in #2 exists and shows that update is
> necessary, have bind server email to address entered in 1 and with
> abscense of that have it email to [email protected] and if HINFO
> exists, it can take that and enter this as custome email.
pv: (alas, in most bind installations, there is no script that's run to
install the software or generate a config, and where this is done, it's
platform/vendor specific, i.e., not written by ISC even if we had one.
as to #2, there's a lot more value in MIM'ing the response to a query
than there is in MIM'ing the reporting of a version:hostname:email tuple,
and i don't thing we should create new attack vectors. as to #3, not
every bind server host has the ability to send e-mail at all.)
> This idea could be taken further, with a service offering that vendors
> and/or users support. Instead of having the server only answer for BIND, it
> could answer for any number of products. Vendors would have to supply the
> details on the latest software versions and patches, hopefully funding the
> listings (in the case of software sold for dollars, open source would have
> to be supported in another way, such as by user subscription).
pv: (i love this idea, and if somebody else leads, ISC would try to follow.)
> I think the key to getting people to upgrade may be one of:
>
> 1) provide an automated audit tool which can look at an existing
> installation and flag known issues, and do pre-installation checks
> for required supporting packages which may also need to be
> installed -- sort of an automated mentoring system. Given the problems
> with misconfigured software in some remote parts of the world, it
> would probably be worth building that code in a way that facilitates
> internationalization from the get go...
>
> 2) have the application periodically check for updated versions,
> and nag/nudge admins when appropriate (or possibly even auto-update)
>
> Yes, I know, neither of these should be necessary, and yes, I know
> that automation of installation tasks poses its own set of problems
> but we live in the time of Windows Update and "system admins"
> who aren't what they used to be, I'm afraid.
pv: (i suspect that something like this, as an outboard tool capable of
running on a NOC machine, is the right short term approach. it'll need
the ability to scan for BIND instances in the local address space, keep
track of their version numbers, and download (via https:// i guess) a
file from some central repository indicating version availability and
safety, and to send mail at various junctures. i wish i had this for
NTP as well, now that i think of it. maybe this should be a NOCOL thing.)
|