The Evils of Default Security (tutorial)

Quote:

---

Originally posted here by catch

Systems that ship in a secure state require far, far more effort to make calcuable changes to the security policy for things such as adding additional services. hence a real world system that shipped "securely" is going to be less secure (lower assurances) that a system that shipped in an insecure state with the same effort (resources).

"the 'secure by default' system cant be blamed the first time some idiot configures his web server wrong on his box and gets rooted."

There is an internet full of documents on locking systems down, there are virtually none on how to open up a hardened system in a secure manner. Are they an idiot, or are they doing the best they can (at a more difficult task) in absence of good/any information?

Very high security systems ship in a least secure configuration and come with a guide on how to lock down each aspect of the system if it is used or not used. this type of compartmentalization is very good and offers a great deal of assurances, but when you start removing security.... god knows what unthought of thing that change may unlock...

catch

---

From what I've read here you are saying that people are smart enough to read up and lockdown a non secure system, but not smart enough to follow the same procedures after opening things up from a secure by default system. What do they do with a system they've locked down but now need to add services to? Wipe to a default config and then lock it down to the necessary level?

As far as placing the blame on 'secure by default' boxes that have been rooted, the companies involved want that blame placed on the bone head users that turned the knobs they shouldn't have. People are banging on their doors asking why so many entry points are left open on systems by default. Entrypoints that most users do not know about, even quite a few that the experts don't find out about in time.

While this piece makes some interesting points, I'd have to agree that it isn't quite a tutorial. It would probably be more appropriately placed in one of the os discussion forums or in a separate 'essay' style forum.

Quote:

---

Systems that ship in a secure state require far, far more effort to make calcuable changes to the security policy for things such as adding additional services. hence a real world system that shipped "securely" is going to be less secure (lower assurances) that a system that shipped in an insecure state with the same effort (resources).

---

This sort of made me think of Novell: Where would they fit in? Novell 5/6 were actually pretty good and AFAIK, ship in secure state by their default install. (Unless I misunderstanding what you are referring to).


catch: I've moved this out of tutorials because I'm not sure it's a tutorial as much as an opinion piece. I'm open to discussions from others (either way and via PM if you feel that way) but for now I'll leave it here as I think it will generate some good discussion.

The reality is, IMHO, no system is secure from the get go. And anyone who thinks that an OS is secure by default (because it says so) is opening up the possibility of making a mistake. There are some systems that lend themselves to be made more secure or are designed to be flexible enough to be secured well but none is truly secure. The adage "Be paranoid and be even more paranoid" should be the mantra for all secure admins, experts, etc.

Quote:

---

Originally posted here by MsMittens


The reality is, IMHO, no system is secure from the get go. And anyone who thinks that an OS is secure by default (because it says so) is opening up the possibility of making a mistake. There are some systems that lend themselves to be made more secure or are designed to be flexible enough to be secured well but none is truly secure. The adage "Be paranoid and be even more paranoid" should be the mantra for all secure admins, experts, etc.

---

Amen to that.

Quote:

---

Originally posted here by MsMittens
The reality is, IMHO, no system is secure from the get go. And anyone who thinks that an OS is secure by default (because it says so) is opening up the possibility of making a mistake. There are some systems that lend themselves to be made more secure or are designed to be flexible enough to be secured well but none is truly secure. The adage "Be paranoid and be even more paranoid" should be the mantra for all secure admins, experts, etc.

---

Indeed, but IMHO an operating system designed with an eye towards security will prove itself to be MORE secure (not 100%) than any other operating system. Indeed, even the most secure linux boxes recently had a kernel vulnerability. There's no way to protect the operating system from itself in that situation, the best you could do is patch and restart. I would say that an operating system like OpenBSD indeed lends itself to be much more secure than say, NT4. I guess it boils down to I don't get why it's a bad thing to be out-of-the-box secure (or more secure than the alternatives).

Paranoia is definitely an attribute every good admin I've met has. Usually a lot of it involves constantly keeping tabs on the latest exploits and so forth, being on every security mailing list out there, etc., etc.. It is an invaluable tool to be aware of what is going on at large. As they say, knowledge is power, and you definitely aren't going to hurt yourself any by getting some 900-1300 emails/day. :)

I used to believe that security was/is only as good as the admin maintaining it, and in a lot of cases, that's very true. Like all things however, there are caveats to consider such as vendors not supplying patches. An admin can do everything right, but if an organization knows of a vulnerability and is slow to patch software or simply doesn't patch it at all then said admin is left only with the options of shutting off services, exploring alternatives, or hoping that the patch comes out before he/she gets hit (if applicable).

Quote:

---

Indeed, but IMHO an operating system designed with an eye towards security will prove itself to be MORE secure (not 100%) than any other operating system.

---

Don't you think this opens up the door for a false sense of security? Because we are told it is mroe secure, therefore we don't worry about it as much? It reminds me of a person who wanted to be a prof. Usually, you have to do a practise teach. He did his on CISCO routers and ACLs. Now, I'm not a CISCO expert but understand the concept of ACLs and the importance of placement of ACLs. So in his example of multiple LANs and blocking one from another (accounting to engineering I believe) I asked him why he put the ACL where he did. His response: "It's supposed to go there". I asked again. I got the same answer. I asked one last time stating that I didn't understand why it had to go at that specific spot (inside rather than outside IIRC). His final answer: "Because the book said so. " (he didn't get hired) but the point is evident.

If we believe it's secure ("because the company told me") rather than question how secure it truly is, we might be leading ourselves into a false sense of security. And that, IMHO, might result in a resume building exercise.

Quote:

---

An admin can do everything right, but if an organization knows of a vulnerability and is slow to patch software or simply doesn't patch it at all then said admin is left only with the options of shutting off services, exploring alternatives, or hoping that the patch comes out before he/she gets hit (if applicable).

---

So then we get back to security being "like an onion" and having many layers from the admin to the user to OS to the network devices to the security devices to the policies to the managers to the CEO.

Any sysadmin who has a feeling of security should be resume building. :)

-Maestr0

Quote:

---

Originally posted here by MsMittens
Don't you think this opens up the door for a false sense of security? Because we are told it is mroe secure, therefore we don't worry about it as much? It reminds me of a person who wanted to be a prof. Usually, you have to do a practise teach. He did his on CISCO routers and ACLs. Now, I'm not a CISCO expert but understand the concept of ACLs and the importance of placement of ACLs. So in his example of multiple LANs and blocking one from another (accounting to engineering I believe) I asked him why he put the ACL where he did. His response: "It's supposed to go there". I asked again. I got the same answer. I asked one last time stating that I didn't understand why it had to go at that specific spot (inside rather than outside IIRC). His final answer: "Because the book said so. " (he didn't get hired) but the point is evident.

If we believe it's secure ("because the company told me") rather than question how secure it truly is, we might be leading ourselves into a false sense of security. And that, IMHO, might result in a resume building exercise.
So then we get back to security being "like an onion" and having many layers from the admin to the user to OS to the network devices to the security devices to the policies to the managers to the CEO.

---

I can see how a person who is uneducated and/or inexperienced at it may see it that way (referring to a user running the operating system and mistakingly believing they are 100% secure once they install extra applications/services), but in a sense, the facts (as they are plainly presented) do tend to agree with the assessment that OpenBSD boxes are by far more secure than other operating systems in their default configuration. The false sense of security would come only from not understanding that once you modify the default configuration you have thrown the security out the window. Indeed, awareness of such things is a good thing, and SHOULD be stressed to all admins -- especially the up and comers.
What the argument lacks tho is a clear definition of whom we are discussing. Are we discussing competent admins? Are we discussing some guy who just loads up any given OS the first time on his home machine? With a clearer definition of the context in which this is taking place, I would have much more suitable answers. Every situation will ultimately differ from every other situation, even if only in minute detail. The result is that we can't reliably discuss a generality, since in one instance a security measure may make great sense, whereas in another situation, the opposite may be true. Perhaps some case studies would be good to further discussion. Had I any such materials handy, I would gladly post them, however it will take me a few minutes to dream some up.
I do however (as a paranoid person) believe that if you do know what you're doing, you can't go all wrong starting with an operating system with an eye towards security, and that if you don't know what you're doing, you can make just as much a mess of ANY operating system.

I also see the issue that MsMittens brought up as a user education issue. While it could and probably will give some users a false sense of invulnerability, the companies or individuals involved will most likely put up disclaimer text that will give that user some sense of reality. Otherwise they will in fact get sued out of existence by every corporation and user who finds out otherwise. You can't market a bulletproof vest and say it will keep you safe from getting shot in the head when used properly.

Alot of the problems people are experiencing right now are the ones being brought up in this thread. Users put up a system and think it's secure even though it's not. Those who understand it's not secure, or just finding it out, do more work to lock it down. The same will most likely be said if everyone pushed secure by default systems. There will still be a fair share who pop em up and think they're fine...and the rest will educate themselves to various degrees to prove to themselves that they are fine. I believe that pushing secure systems will most likely lessen the chance of mass worm infection of the scale and type we are seeing today, as well as make the script kiddies on my local cable network work a lil harder to actually do something to Ma and Pa Kettle's computer down the way.

Quote:

---

..the facts (as they are plainly presented) do tend to agree with the assessment that OpenBSD boxes are by far more secure than other operating systems in their default configuration.

---

Even Novell?

And sorry. I think I'm a bit dense from the holidays but where are the facts that support that OBSD is "far more secure than other OSes in their default configuration"? Is there a report? study? ;)

First:

Quote:

---

Nearly all computer attacks stem from the following six issues stack overflows, access to services, privilege and privileged accounts, networking resources, shared environments, and other bugs in applications and services. Considering this, it should be painfully clear how little hardening does for actually securing systems. Clearly different architectures and mechanisms are needed to deal with these issues as hardening alone is simply not viable.

---

And then this:

Quote:

---

The reality is, IMHO, no system is secure from the get go. And anyone who thinks that an OS is secure by default (because it says so) is opening up the possibility of making a mistake. There are some systems that lend themselves to be made more secure or are designed to be flexible enough to be secured well but none is truly secure. The adage "Be paranoid and be even more paranoid" should be the mantra for all secure admins, experts, etc.

---

I hope your point is that hardening alone is not enough, but from this line: "Considering this, it should be painfully clear how little hardening does for actually securing systems.", it seems you're just bashing hardening. :confused: I'm with chsh on that subject.

Don't take this the wrong way, catch, I'm not flaming you, but what you said almost seems like a contradiction of the subject at hand. I agree that no OS is secure out of the box, and I also agree that system hardening, when used alone, is a poor security measure. I just don't see the point in bashing something that has proved itself in real world situations. I mean, If I remove un-needed services from my server, and patch the services that I do use, doesn't that make it more secure by eliminating potential vulnerabilities facilitated by those services. That's part of what hardening is, isn't it?

And it's not hard to add services to a "hardened" OS and keep it "secure" as long as you fully understand how the OS and the service function, the vulnerabilites and limitations of that service, and how to limit or eliminate any vulnerability and harden the service. Just remember that security is relative, and no system will ever be 100% secure as long as a user can access the system.

IMHO, to say that system hardening is paltry and does little for overall security is absolute hogwash. I would never dream of using a system that wasn't hardened. System hardening is the foundation over which all other security is built.

Maybe I just misunderstood what you were trying to say on that.. I dunno.

A do agree with your criticism of admins, though. You simply can't be a good administrator if you're not paranoid. I know I'm paranoid...It keeps things interesting :p

Overall, it's a great tutorial. You covered a lot of informaton, and aside from that one part that ruffelled my feathers, you were on the money, especially the 3rd section.

Props for trying to tackle such a tough subject. Next time, just think it out a little more....I confuse easily! ;)

"You can be sure of succeeding in your attacks if you only attack places which are undefended. You can ensure the safety of your defense if you only hold positions that cannot be attacked. "

Sun Tsu
The Art of War