Re: FreeBSD Security Survey
I'd have to agree with most of Ted and Gayn's points. Also, it's hard to answer many of the questions when they are different for different servers. Unless there is a serious bug in something like SSH, then a paying client with a seriously firewalled server and no malicious users might get upgraded every four months. My own server might get upgraded weekly when I'm not too busy, or not for four months when I am. But a security bug with a network service would get much more immediate attention. If I still administered machines in an academic environment, my answers would be quite different, but the risk analysis that led to the different answers would (theoretically) be the same. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: FreeBSD Security Survey
> [mailto:[EMAIL PROTECTED] 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 >
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 >-Original Message- >From: [EMAIL PROTECTED] >[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
