RE: FreeBSD Security Survey

[mailto:owner-freebsd-questions@xxxxxxxxxxx] On Behalf Of Ted
Mittelstaedt
Sent: Sunday, May 21, 2006 11:20 PM
To: Colin Percival; FreeBSD Questions
Subject: RE: FreeBSD Security Survey

Colin,

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
wouldn't
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
upgrade)

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.

Ted

Colin,

I had the same problem with #6 and also with #12. #9, which
offered a time-line, was better. All needed an "other" field.

In my case, the servers aren't on the edge of the Internet
(we use OpenBSD for that) and aren't subject to inside attacks;
hence, most advisories can at least be deferred. As Ted points
out, turning off services or adding firewall rules are often
the path of least resistance. Not only have most of us been
burned by a Windows security upgrade breaking a server's
application suite, my sense from this forum is that some
people have at least had this problem with version upgrades
(and many have had trouble with port upgrades)
and they (and now I) are understandably cautious.

Another consideration, not captured in your survey, is
"newbie-ness". After 18 months or so using FreeBSD, I still
consider myself a newbie. When it comes to version upgrades,
patches, and port upgrades, I'm definitely a newbie. Not only
do I have to be extremely careful doing an upgrade, I also
need to be extra careful testing that I haven't broken anything.
Thus, unless a security advisory is directly applicable, I only
get around to the upgrades (and I do OS and ports all at once)
every several months. Maybe as I gain more experience, I'll
be able to upgrade and test more efficiently and will be inclined
to do them more frequently.

I also agree with Ted that client cost is a deterrent to upgrades.

Finally, it may be interesting to expand the questions somehow
to include Linux. Many of us also maintain Linux machines, and to
the extent there is reluctance to upgrade, it probably applies to
Linux as well - it does with me, even with much more Linux
experience.

Hope this helps,

-gayn

Bristol Systems Inc.
714/532-6776
www.bristolsystems.com


_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"

Loading