Just a couple problems with the survey:

Question #6 needs a "Sometimes" as it is not going to be a yes
or no question for many people.

Your also ignoring the fact that many security holes are a lot
easier to ignore and just block off the affected service.  For example
we run an older RADIUS daemon that has the hole in it that CERT
documented a few years ago.  But we restrict incoming radius
queries to this server to the NAS only.  When the FreeBSD telnetd
problem came out a few years back I didn't bother patching systems,
I just disabled telnetd and waited until it was time to replace the
server with a new version of FreeBSD.

The thing is, though, that when your dealing with a production
server you really have to understand what is involved to apply a
patch.  You don't just go to a production system that a lot of people
are using and run some automated patch-me program that fucks around
with a bunch of files on that server under the hood.  You have to
apply the patch to a test system, by hand, to know exactly what
it's changing, then run your test suite on the test system to make
sure the production system isn't going to tank when you touch it,
then schedule a time to touch the production system and patch it,
and make sure you have plenty of time in your schedule available
post-patch just in case something reacts wrong.

  And, when the FBSD system is a server you have built under spec
for a customer, it's a whole different ballgame because before you
spend a minute of time on it, you have to go to the customer and
tell them a security patch came out for their server and they got to
pay you a couple hundred bucks to install it on their server you
built for them.  Your not going to work for free.  And the customer
may take the attitude that they are planning on replacing the server
in 6 months anyway, and at that time you can just use a new version of
FBSD that doesen't have the hole, and they are just going to take
their chances until then.

  In that situation even if patching their server was merely a matter of
spending 2 minutes logging into it and running an updater, you still
do it and you know why?  Because the second you start doing work for
that customer for free, they are going to expect it.  It's better from
a business perspective for you to warn them their server is open and
they have to pay you to patch it, have them decline for the moment
and leave it unpatched because they are going to gamble for another
6 months that it won't be attacked, and then have a cracker bust it up
so you can tell them "I told you we needed to patch that and you decided
to cheap out, look what you get"  (of course you say it in a more
diplomatic way)

  Your survey responses lack any responses that indicate that leaving
the system unpatched may be deliberately done, for monetary reasons,
your responses in the survey assume that all system admins that
understand the security implications of leaving a system wide open
are going to always patch them, and only ignorant/newbie system
admins are going to run an unpatched system.

  And the other problem too is that there's still a lot of hardware
out there that runs FreeBSD 4.11 much better than 5.X and later.
I have a number of Compaq dual-PPro deskpros for example that work
fine under 4.11 but run slow as molassas under newer versions of
FreeBSD.  send-pr reports are pointless here since many people
have already complained about such behavior with a lot of different
gear, and it appears all the FBSD developers today are building
on nice new gigahertz hardware not old stuff, and have the attitude
to just scrap the old hardware, and buy new, it's cheap enough.

  You need to add another question like:

X) why are you running an obsolete version of FreeBSD:

  ) hardware I have doesen't work well with newer versions of FBSD

  But, I realize that very likely you won't add this because it's
not something the FBSD development team wants to hear.  (ie: spend
more time optimizing and working through the PR database and less time
coming out with new gee-whiz FBSD versions and trying to get people to

  Good luck with it, but understand also that the same issues apply to
patching Windows systems.  When we install a Windows server, we never
turn on auto-updates, we only do this for desktops.  And before applying
a MS patch to a Windows server it has to go through the same rigamarole
of testing and such that a patch to a FBSD server would.  Too many times
in the past, patches have broken application software.


>-----Original Message-----
>[mailto:[EMAIL PROTECTED] Behalf Of Colin Percival
>Sent: Sunday, May 21, 2006 10:34 PM
>To: FreeBSD Questions
>Subject: FreeBSD Security Survey
>Dear FreeBSD users and system administrators,
>While the FreeBSD Security Team has traditionally been very good at
>investigating and responding to security issues in FreeBSD, this only
>solves half of the security problem: Unless users and administrators
>of FreeBSD systems apply the security patches provided, the advisories
>issued accomplish little beyond alerting potential attackers to the
>presence of vulnerabilities.
>The Security Team has been concerned for some time by anecdotal reports
>concerning the number of FreeBSD systems which are not being promptly
>updated or are running FreeBSD releases which have passed their End of
>Life dates and are no longer supported. In order to better understand
>which FreeBSD versions are in use, how people are (or aren't) keeping
>them updated, and why it seems so many systems are not being updated, I
>have put together a short survey of 12 questions. The
>information gathered
>will inform the work done by the Security Team, as well as my
>own personal
>work on FreeBSD this summer.
>If you administrate system(s) running FreeBSD (in the broad
>sense of "are
>responsible for keeping system(s) secure and up to date"), please visit
>and complete the survey below before May 31st, 2006.
>Colin Percival
>FreeBSD Security Officer
> mailing list
>To unsubscribe, send any mail to
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.1.392 / Virus Database: 268.6.1/344 - Release Date: 5/19/2006

_______________________________________________ mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to