Date: Mon, 22 May 2006 07:08:48 -0700 From: "Gayn Winters" <gayn.winters@bristolsystems.com> To: "'Ted Mittelstaedt'" <tedm@toybox.placo.com>, "'Colin Percival'" <cperciva@freebsd.org>, "'FreeBSD Questions'" <freebsd-questions@freebsd.org> Subject: RE: FreeBSD Security Survey Message-ID: <01e201c67da9$42111a80$6501a8c0@workdog> In-Reply-To: <LOBBIFDAGNMAMLGJJCKNCEPNFDAA.tedm@toybox.placo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> [mailto:owner-freebsd-questions@freebsd.org] 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01e201c67da9$42111a80$6501a8c0>