The Evils of Default Security (tutorial)

After a seven week leave from this site I figured I ought to try and come back with something useful and interesting to remind you all of how much you missed me. ;)

A large percentage of this site and really all computer security forums focus on a single topic: "Which is better (more secure)?" where various people will throw out random biased opinions, unlisted options to show how smart they is, or perhaps even *gasp* relevant facts. Facts are good right? Well, to quote Homer Simpson, "Facts are meaningless. You can use facts to prove anything that's even remotely true. Facts shmacts." As a rule, Homer tends to be not too bright, but his words frequently carry a deeper truth thus he is so lovable. In this case it seems that just because something is a fact, doesn't mean it is a fact in a given situation...

Confused yet?

I speak of default configurations. I can't recall how many times I've come across "X is already hardened, so it is more secure." Operating system like OpenBSD and Windows 2003 both fine examples of tribute to this fallacy. The subject of this tutorial is to demonstrate to the reader that “more secure by default” actually results in a less secure real world system. (How is that for facts shmacts?)

----------------------------------------------------------------------------------------
Part 1: The inadequacies of “hardening”.

Hardening either before or after shipment typically includes but is not limited to the following actions:

• Removing unnecessary packages/applications.
• Removing unnecessary services.
• Stronger default file permissions (removing suid/guid, adding sticky bits, etc)
• Locking down administrative accounts. (Using wheel to limit su, preventing telnet access, etc.)
• Utilizing an intrusion detection system. (Tripwire et al to monitor the system.)

Following this checklist you will have a very secure system right?

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.

The next broken BIND, thieving admin, or perhaps that one web application input that was accidentally not validated, just to name a few examples will suffer little resistance from your best hardening efforts.

I am sure many of you were already aware how this type of security falls short, but are probably still thinking that even the paltry security offered by hardening is better than nothing and for the vendor to offer such security by default not only makes your job easier but makes the system overall secure as few attacks happen against it.

----------------------------------------------------------------------------------------
Part 2: The benefits of homogenization. (Important points but a non-definitive argument.)

Nearly all exploits all into one of two categories:
[list=1][*]Configuration error.[*]Otherwise correct configuration but inadequate to provide protection against flawed source code.[/list=1]
The Apache.org root via FTP/Apache/MySQL configuration errors is a fine example of the former while the IIS Unicode attacks of the latter. While it is true that two additional types of exploit exist (source error indefensible by a different configuration and design flaws that have no source issues and cannot be fixed via admin configuration) these have not be included as they make up a very small percentage of real world attacks and because they have nothing to do with the subject of this tutorial.

Let us compare two systems now, one shipped in a soft state (systemA) and one shipped in a hardened state (systemB).
[list=1][*]Any two instances of systemB are likely to exist in the same state, as implementation/administrative intervention is less likely since a “secure” system was purchased.[*]Any two instances of systemA are likely to exist in different states, as post-purchase configuration is needed to bring the system into a secure state.[*]Any single instance of systemA is more likely to exist in an insecure state than any single instance of systemB.[/list=1]
This means, that since systemA is more likely to be insecure, valid exploits are more likely to exist. It also means that an instance of systemA, which has been configured to an equal state of security to systemB, is actually less likely to be effected by exploits than systemB is. Consequently the likelihood of systemB being vulnerable to random threats is greater than systemA existing in the same state. SystemA is also likely to be less vulnerable against specific threats since the exact configuration is less likely to be known by the attacker. Your odds of being the victim of packaged attacks are reduced without patches and the odds of you not seeing a 0-day attack coming are also reduced as a greater likelihood of an attacker error exists.

It is true that a systemB implementer/administrator could alter systemB’s configuration making it less predictable, but this would not only remove any advantages of having a secure by default system it would also play into bigger issues identified in section three.

----------------------------------------------------------------------------------------
Part 3: The costs and consequences of knowledge.

Consider two sand castles, the first already built the second a kit containing your bag of sand, various molds, and a detailed instruction manual. Using the kit you are able to make a sand castle (castleA) exactly like the one already built (castleB), and you do so. Now there are two identical sand castles on the table in front of you.

Depending on how exact you were in the construction of castleA, it is possible to know essentially everything about it. How many grains of sand in the left tower, the exact volume of the moat, if any additional measures are needed so that a base width of X can support a height of Y, etc, etc. If you add an extra doorway into the wall of castleA and you track what exactly you remove, you will know exactly what remains and have a better understanding of exactly how the remains are structured. Less chance for error exists and less requirement for auditing.

This example of sand castles may seem silly, but when compared to information system security it becomes highly valid. If for some reason you need to change the security of systemA, this will be very easy, especially from the default state. An error become obvious as you add security, if something no longer functions that was needed to function, undo the last step. When starting with a system secure by default and functionality needs to be added, errors will not present themselves without an additional security review. Additionally the implementer needs to know far more about the system to make changes. This can be easy with an old system, but to completely learn the number of grains in a system or patch just released… it gets impractical. (I’m not talking source I’m talking roles.) Critical elements may be (and in practice frequently are) inadvertently removed while trying to increase functionality.

In any controlled system it is a simpler task to calculate the effects of the addition of an element rather than a subtraction of one.

----------------------------------------------------------------------------------------
Part 4: What it all means.

Systems secure by default are little more than a marketing ploy, that prey upon users lack of understanding about the actual mechanisms and architectures that go into secure computing. These vendors feel that they will make more sales by selling a product that seems more secure than one that actually is more secure. (Unless you are like OpenBSD and scare all your clients away with your pompousness.) Odds are they are probably right, but that doesn’t mean it is a valid point to consider when comparing two systems.

If you start with something insecure but highly functional, so long as it comes with the tools to lock it down you’ll be ahead in security assurances, costs, time, and the skill level needed by your implementer.

catch

Bout time you got back. I thought this was great information. I'm making a request:

Write a paper on OpenBSD and the false sence of security it delivers.

If you have time anyway.

I just thought you made very valid points the last time we argued. It was a damned good arguement too. Both of us presented our proposols, neither flamed, and we both talked about it for a long period of time and made very valid points on both sides. We need a thread like that on here.

And, yes, I am admitting that I learned alot from catch in that arguement, and actually changed my views around on OpenBSD.

Thanks, catch. That was good. Nice topping to my lunch break today.

You make a number of excellent points that deserve further discussion and expansion.

Quote:

---

If you start with something insecure but highly functional, so long as it comes with the tools to lock it down you’ll be ahead in security assurances, costs, time, and the skill level needed by your implementer.

---

A question at this point may be: "How do we keep the insecure but highly functional systems out of the hands of the incompetent?"

;)

Looking forward to more exchanges with you.

Much thanks gore. People who are secure in their knowledge tend to not feel the need to flame so much. (unless they are tired of banging their head against the wall with someone that just doesn't get it.)
I do like to pick on OpenBSD... I might take you up on that... oh the flames I'll receive. ;)

Thank you rapier, I am glad you enjoyed the post. Your question:

Quote:

---

How do we keep the insecure but highly functional systems out of the hands of the incompetent?

---

is a great one.

Actually it is to the benefit of systemA users if the majority of systemA users tend to be lazy and or uneducated. Primarily that it keeps the level of attack sophistocation down. (People won't seek a complicated attack if a simple one likely exists.)
These insecure by default systems that are always getting compromised are unimportant, they are systems that are not used to protect anything worthwhile or the level of attack that occurred didn't effect anything worthwhile. (I wrote about this a while back regarding .gov website defacements.) The end result is an artificially high number of recorded compromised systems.

From my experience, systemB type setups have way way way more compromises of the types that nobody reports. That should be the true measure of a system, sadly companies keep that data to themselves.

catch

Excellent. I was precisely debating with a friend two days ago about the OpenBSD case and about its default policy. I thought nearly what you exposed here, even if my position was less hardened than yours.

Rapier57> We can't! Light speed, gravity, Plank constant and stupidity are the four major physics constants.

This is an excellent post. In fact, it is one of the most well written that I have seen here in quite some time.

Nice to have you back.

Good to see you around again Catch. I think you bring up some good points especially about homogenization. While a 'secure by default' operating-system is not an "end-all" solution I think a more accurate description would be 'somewhat more secure by default' :) (we all know the mantra that security is a process anyway :) ) I do think these systems do have merits which can give some advantage to the savy admin. And while many attacks will succeed against them many more will be thwarted. Some of the major 6 issuses are addressed in some fashion or another in the afore mentioned OSes. For instance overflows can be somewhat mitigated by Stack protection (present in both the new OpenBSD and Win2k3) and hand auditted code and some appplication code auditing (OpenBSD) and while it is known these can be defeated I think they represent a leg-up on OSes in which this is not present. I think you point out correctly that many people interpret 'secure by default' to mean 'no administration neccessary' which simply is not and will not ever(that I can see) be the case. I think your comparsion to a sand castle is an excellent one but I think core OS that attempts to be more secure at a kernel level is a good foundation for building a secure system but the 'secure by default' system cant be blamed the first time some idiot configures his web server wrong on his box and gets rooted. :)

-Maestr0

"It is the flawed assumption that security mechanisms can be adequately
provided in layers above the operating system. A perfect security application
cannot make up for flawed or absent security features within the OS kernel.
It is the classic example of building a castle on a swamp. You can build
a strong fortress, but it makes no difference if it slowly sinks into the
ground. "
- Mike Schiffman "The Belt and Suspenders Approach"

Maestr0, I think part 3 of my original text is important and not to be overlooked.
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).

Also, there is a difference between a system that has a security kernel and one that ships in a hardened state. OpenBSD for example offers no additional security functionality over Mandrake Linux, but people think it is more secure because it ships with a more secure configuration. My arguemnt is that after setting up a real world system, the Mandrake one will have greater implementation assurances and consequently will be more secure for the same efforts than the OpenBSD one.

"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

Quote:

---

Originally posted here by catch
Much thanks gore. People who are secure in their knowledge tend to not feel the need to flame so much. (unless they are tired of banging their head against the wall with someone that just doesn't get it.)
I do like to pick on OpenBSD... I might take you up on that... oh the flames I'll receive. ;)

Thank you rapier, I am glad you enjoyed the post. Your question:

is a great one.

Actually it is to the benefit of systemA users if the majority of systemA users tend to be lazy and or uneducated. Primarily that it keeps the level of attack sophistocation down. (People won't seek a complicated attack if a simple one likely exists.)
These insecure by default systems that are always getting compromised are unimportant, they are systems that are not used to protect anything worthwhile or the level of attack that occurred didn't effect anything worthwhile. (I wrote about this a while back regarding .gov website defacements.) The end result is an artificially high number of recorded compromised systems.

From my experience, systemB type setups have way way way more compromises of the types that nobody reports. That should be the true measure of a system, sadly companies keep that data to themselves.

catch

---

HEHE, as soon as you want to, go ahead on the OpenBSD thing. I think it'll be great fun to make it public this time. That can let ALOT more veiws get added in, and we can FINALLY have something worth replying to about a "touchy subject".

Most OpenBSD users are the one's saying "So, Linux users, how is your system doing? I have updated in 3 months, and it's hard as a rock!"

As for the flames, well, I do flame alot, but I try to do it for humor. I like making people laugh, and basically getting any reaction out of them I can. Most arguements I'v had publicly here were pretty much a waste of time as either I would loose my cool to fast and be at fault for being an ******* and flaming, or the other side would lay down a line that satisfied them, sounded good, and solved nothing.

You on the other hand, never went into flaming with me, we had our arguement over a long period of time, and we both made our points and talked about them, and I think we should do it publicly when you have the time to start your post on Open BSD.

Only recent time I'v argued a good well thought out arguement, was the other day on IRC with Pwaring, and Syini666.

We argued about drug laws, and we all plan on doing it again. Why you may ask? Because it was damned good fun, and both of them probably have a respect for me now they may not have had because none of us flamed, none of us used name calling, and we showed RESPECT for others feelings and ideas.

We argued for a while untill I had to leave but we agreed on doing it again. Heh, funny huh? We argued and WANT to do it again. Most people argue, and never want to speak to the other person again, while we are looking forward to it.

Catch, you need to stay back now, I havnt had any good argueing besides on IRC, in a long time, and you're one of the few willing to give me the chance to say what I feel and respond to it. Besides, you're one of the only members to ever change my mind about OpenBSD ;)

SuSE Linux you have hardly a chance in cold bloody hell at changing my mind about, but I'd listen to you first at least....Hmm, want to have a discussion about SuSE Linux too? I'm looking forward too a damned good arguement with you man.

I was curious as to what your other positions on operating system security were, so I looked at some of your posts, and this is pretty well the best one it seems...

Quote:

---

Originally posted here by catch
I speak of default configurations. I can't recall how many times I've come across "X is already hardened, so it is more secure." Operating system like OpenBSD and Windows 2003 both fine examples of tribute to this fallacy. The subject of this tutorial is to demonstrate to the reader that “more secure by default” actually results in a less secure real world system. (How is that for facts shmacts?)

---

Without facts to back you up? I find that somewhat amusing. Yes, let's not let little facts get in the way of our making our point shall we?

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.

---

Oh, so what you mean to say is that the process of removing unneeded accounts, trimming down your user's access capabilities, jailing processes so that if they happen to be exploited system-wide access isn't guaranteed, and removing setuid binaries does nothing for actually securing a system? I want to make sure I get that right, since that's what you wrote and all. Wouldn't want to be confused about something like that.

Quote:

---

The next broken BIND, thieving admin, or perhaps that one web application input that was accidentally not validated, just to name a few examples will suffer little resistance from your best hardening efforts.

---

You have evidently misunderstood the entire purpose of hardening your system. If you have some childish preconceived notion that hardening a system is done to prevent software vulnerabilities from happening, you possibly need to read a FAQ on the subject.

Quote:

---

I am sure many of you were already aware how this type of security falls short, but are probably still thinking that even the paltry security offered by hardening is better than nothing and for the vendor to offer such security by default not only makes your job easier but makes the system overall secure as few attacks happen against it.

---

It does not fall short. It does exactly as advertised. That you are delusional and believe the hardening process is advertised as the be all and end all of security is not the responsibility of those who point out their OS is secure. You should seek some kind of understanding about the situation, rather than assuming you know what you're talking about when you actually evidently don't.

Quote:

---

Nearly all exploits all into one of two categories:
[list=1][*]Configuration error.[*]Otherwise correct configuration but inadequate to provide protection against flawed source code.[/list=1]
The Apache.org root via FTP/Apache/MySQL configuration errors is a fine example of the former while the IIS Unicode attacks of the latter. While it is true that two additional types of exploit exist (source error indefensible by a different configuration and design flaws that have no source issues and cannot be fixed via admin configuration) these have not be included as they make up a very small percentage of real world attacks and because they have nothing to do with the subject of this tutorial.

---

Yes, actually, I find it funny that you categorize the other two as being unimportant when they are indeed the actual flaws responsible for the Windows XP exploits/flaws as well as basically ALL of the IIS vulnerabilities. Since you are evidently also not a programmer (which leads me to wonder, who are you to speak of any authority on such matters), you also don't seem to get that the second option you list above, is indeed the same as the third and fourth you mention. Basic design flaws are still 'flawed source code'. I like how you're vague enough to fool people but can't be precise enough to show you know something.

Quote:

---

Let us compare two systems now, one shipped in a soft state (systemA) and one shipped in a hardened state (systemB).
[list=1][*]Any two instances of systemB are likely to exist in the same state, as implementation/administrative intervention is less likely since a “secure” system was purchased.[*]Any two instances of systemA are likely to exist in different states, as post-purchase configuration is needed to bring the system into a secure state.[*]Any single instance of systemA is more likely to exist in an insecure state than any single instance of systemB.[/list=1]

---

And where is the proof of this? How can we not know that two instances of System B are more insecure because of something they are both doing (under the guise of homogenization) where the two instances of A are more secure because of their differing roles. If you look at it logically, it favours A actually:
Examplis Gratis:
System A1 runs a buggy webserver while System A2 runs only mail services.
System B1 and B2 run a buggy webservers.
Exploit comes out affecting said buggy webserver. 100% of System B machines will be affected, while only 50% of system A machines will be, due to diversity of services. So where is your logic that A (non-homogenous) will be worse?

Quote:

---

It is true that a systemB implementer/administrator could alter systemB’s configuration making it less predictable, but this would not only remove any advantages of having a secure by default system it would also play into bigger issues identified in section three.

---

Having played quite a bit of the intrusion game myself, I can unequivocally state you are wrong in your assumptions about attacker methodologies.

[..snippage of inane and utterly useless example..]

Quote:

---

Part 4: What it all means.

Systems secure by default are little more than a marketing ploy, that prey upon users lack of understanding about the actual mechanisms and architectures that go into secure computing.[/b]

---

Indeed, that would be why those facts state otherwise (damn, knew those pesky things were going to come up once in a while). The truth is, 'secured by default', while definitely a marketing tool, is also a truth. Slackware and OpenBSD both have excellent security track records, since they don't enable anything by default. Secure by default and 'hardened' are not the same thing, which is yet another concept you seem to have failed to grasp. Secure by default is simply a way of securing the system from remote intrusion attempts by not having services starting up by default. Until OpenSSH, I believe both OpenBSD and Slackware had a perfect security record in terms of remote security.
I suppose given your opinion, everyone is MOST secure if they run out and install WinXP Pre-SP1, since any default security seems to be a waste.

Quote:

---

These vendors feel that they will make more sales by selling a product that seems more secure than one that actually is more secure. (Unless you are like OpenBSD and scare all your clients away with your pompousness.) Odds are they are probably right, but that doesn’t mean it is a valid point to consider when comparing two systems.

---

Yes, it is a valid point to consider when comparing two systems. It sounds mostly to me like you just don't like being told you don't have a secure system by people who do. Indeed, that is your perogative to be cheesed off about it, but honestly, this diatribe of half-truths and outright falsehoods needed to be pointed out. The only reason you got any greenies for this is because evidently nobody was around to point out the utter flaws in this. Not only that, but why this is a tutorial I don't even know. It's an opinion essay, a very poorly researched one at that. Of course, there are those damn facts again eh? Why should you actually have to research something to believe you're right?

It saddens me to see that the level of technical expertise has fallen off so drastically that catch here is regarded as an 'expert' by some. He has a LOT of learning to do, and perhaps some decent discussion can be had after he lands a job (if) and gets bit by his idiotic practices.

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

Quote:

---

Originally posted here by Juridian
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.

---

That only supports the hypothesis that 'hardening' an operating system actually does something, which is counter to what catch has posted in this tutorial. I agree, people need to be aware that secure by default only applies to default configuration, and the moment you make a change it changes the security level of the box. I do however not believe that it is wrong for them to say it is secure out of the box in its configured state after installation. That is not necessarily something that's any good since a box will rarely be left in that state, but it does not bar the truth of the thing as stated.

Quote:

---

Originally posted here by MsMittens
Even Novell?

---

Hence why I did not say "all other OSes". There are obviously other like-minded security endeavours out there, and I would classify Novell as one such thing, since they perform some very rigorous code auditing (at least last I knew of).

Quote:

---

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? ;)

---

The results speak for themselves:
http://search.cert.org/query.html?co...set=iso-8859-1
http://search.cert.org/query.html?co...set=iso-8859-1
http://search.cert.org/query.html?co...set=iso-8859-1
http://search.cert.org/query.html?co...set=iso-8859-1

On the surface, the results appear to suggest that OpenBSD has indeed had 30 or so vulnerabilities that warranted advisory status, but in reality very few actual deal specifically with OpenBSD, and though it is mentioned, it is usually something along the lines of:

Quote:

---

OpenBSD's dhcp support is much modified, does not have that feature, and therefore does not have that bug.

---

From: http://www.cert.org/advisories/CA-2003-01.html
or

Quote:

---

OpenBSD is not vulnerable as OpenBSD's malloc implementation detects double freeing of memory. The zlib shipped with OpenBSD has been fixed in OpenBSD-current in January 2002.

---

From: http://www.cert.org/advisories/CA-2002-07.html
As examples. Few of the vulnerabilities are issues with OpenBSD, while many other vulnerabilities exist in both Windows and Linux. Those are the remotely exploitable vulnerabilities that CERT felt worthy of advisory status. Actual bugs that may or may not exist in many configurations also exist in other operating systems.
Netware and OpenBSD appear to have similar track records in terms of security based on CERT, at least recently.

Open BSD has http://www.openbsd.org for it's "reports" about how secure it is, and a few other sites should have something listed...But i've learned not to always believe that. The Free BSD web page says it is secure to.

What about Trusted Solaris? Has anyone had any experiance with that? I've looked into that OS as I think Solaris is a great OS as long as it is on a Sun Sparc or something.

What about other trusted OSs? OpenBSD is far from the only OS claiming security. I doubt the OSs running on shuttle launches for NASA are anything we have seen. ;)

OpenBSD isn't a "bad" OS, but it is not the most secure thing on the planet. It has had security updates, meaning they have found something in it before right? Still, I think it has many uses.

I think "Hello, World!" is the most secure peice of code on the planet that actually does something besides compile.

Mainly because I'v never seen an exploit for it.

I think that just because an OS is saying it is secure, really does not mean much. It's good if it is, but it doesn't mean the OS is actually secure. Default security is another thing that has alot of opinions.

Take life for an example:

Humans are born cold, naked, and a Dr. gets paid to whack us on the ass and make us cry. We are shipped in a very insecure state. So far though, the turtles and snails havn't taken over, and they ARE shipped in a secure state. They both have shells protecting them.

So why havn't they taken over and made us slaves?

Because they lack the thinking required to do so. Or the "programming" to do so. So instead they wonder off to be eaten by birds directly after birth, and we sit in a hospital, stuck in a room full of other babys, and then we get taken home and we eventually, with the right tools, become secured.

The turtles and snails that don't get eaten also become a little more secure, as the shell they are born with hardens.

What I am trying to do here, besides get a smile/laugh out of someone, is just make a point that just because something is shipped in a secure state, doesn't ALWAYS meen that is is. And just because something DOESN'T ship in a secure state, doesn't mean it can't be.

And, also, remember, the right tool can bring ANY OS down. I'll use the life example again:

Turtles come with a hard shell for protection, but Sledgehammer V2.0 still cracks that with no problem. And people come with no security, but can be secured to take a whack from a hammer with helmet 1.0 and armor 2.0. Point being; the right tool will break through any security system you put forth no matter how secure it came.

Hopefully you see what I am trying to say. I'm not trying to claim to be the great Goradini who can break through anything, I'm just saying with the righ tool, you can, be it knowledge, or a sledgehammer.

Quote:

---

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.

---

576869746568617, you're attributing comments by me to catch I think...

Quote:

---

..the results appear to suggest that OpenBSD has indeed had 30 or so vulnerabilities that warranted advisory status, but in reality very few actual deal specifically with OpenBSD..

---

But are those advisory in CERT indicative of the security of it or rather the lack of use by "hackers" at finding and searching for exploits? We know that a larger audience using a particular OS (Linux and Windows -- specifically Windows) has resulted in more bugs and vulnerabilities found. So if we base "security-ness" on the "lack of CERT Advisories" is this an accurate picture if few people use it? By this logic, the most secure OS is Macintosh OS 9. :D

Quote:

---

Originally posted here by MsMittens
By this logic, the most secure OS is Macintosh OS 9. :D

---

I'm far from a Mac expert, or user, but from what I understand, Mac OS is fairly secure. MsMittens, I think you'v said you use Macs correct? Are they a secure computer? I know Mac OS X is supposed to come fefault everything turned off, but are they really secure? I'd get a Powerbook with superdrive if I could afford it right now. I need some OX X practice and also I do enjoy making music and making art work. I use Linux for the art work right now and Windows XP for my music, but that's another topic than what we are discussing,

since we have been talking about OS security, how secure would Linux rate? I know this is something that can depend on the distro, but for example, Mandrake Linux 9.X seems to be very reliable and secure. I got my first Mandrake system when 7.1 came out. I bought it at best buy, and at the time I think I had only had a computer for a few months, but I wanted it because Tux was on the box and a friend of mine in IRC used Linux so I wanted to learn.

So I bought it. Of course I never used it untill a year ago. I'v only been using Linux and BSD for....Less than a year. In like 3 days it will mark one year that I'v been using it. In that time I have learned an aweful lot about it, and how to secure each distro.

Quote:

---

Originally posted here by gore

I think "Hello, World!" is the most secure peice of code on the planet that actually does something besides compile.

Mainly because I'v never seen an exploit for it.

---

While there may not be many bugs in the hello world code itself, there are most likely numerous bugs in the libraries supporting the hello world application itself.

Quote:

---

Originally posted here by MsMittens
576869746568617, you're attributing comments by me to catch I think...

---

Nope actually, the quote is out of Catch's original post. I quoted the same piece as well.

Quote:

---

Originally posted here by MsMittens
But are those advisory in CERT indicative of the security of it or rather the lack of use by "hackers" at finding and searching for exploits? We know that a larger audience using a particular OS (Linux and Windows -- specifically Windows) has resulted in more bugs and vulnerabilities found. So if we base "security-ness" on the "lack of CERT Advisories" is this an accurate picture if few people use it? By this logic, the most secure OS is Macintosh OS 9. :D

---

From a remotely exploitable standpoint yes. Again, it comes down to specifics about the environment. Are you looking at desktop security? Are you looking at server security? etc.. As I said before, context matters greatly. From a server standpoint, obviously OpenBSD is a good SECURITY choice. Security alone does not make decisions, but it should definitely be considered.

Quote:

---

Originally posted here by Juridian
While there may not be many bugs in the hello world code itself, there are most likely numerous bugs in the libraries supporting the hello world application itself.

---

Oh, ****! Forgot about #include and so on....I'm no programmer but I do know that #include has alot of code in it...Or at least a programming teacher told me that.

So the most secure program would be this then? ::

int main()

{

return 0;

}

That does'nt do anything but compile, but it's secure!

Quote:

---

Originally posted here by chsh
Nope actually, the quote is out of Catch's original post. I quoted the same piece as well.

---

Umm... Double check that. The portion you quoted is

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

---

That is from the bottom of post 12. My post. No where does catch state this. He's done three posts, post 1, post 4 and post 8.

Quote:

---

From a remotely exploitable standpoint yes. <snip> As I said before, context matters greatly. From a server standpoint, obviously OpenBSD is a good SECURITY choice. Security alone does not make decisions, but it should definitely be considered.

---

No. From the standpoint of the fact I asked you for specific proof of OBSD being secure. You stated:

Quote:

---

Few of the vulnerabilities are issues with OpenBSD, while many other vulnerabilities exist in both Windows and Linux. Those are the remotely exploitable vulnerabilities that CERT felt worthy of advisory status. Actual bugs that may or may not exist in many configurations also exist in other operating systems.
Netware and OpenBSD appear to have similar track records in terms of security based on CERT, at least recently.

---

So in the case of OS 9, which AFAIK, never had any CERT worthy vulnerbilities, wouldn't it be a secure OS? When I asked for reports on the security of OBSD I was hoping that there is some 3rd party that has done a study on it and has stated that it's secure. There are organizations and standards that do this:

Common Criteria: This is the new standard to replace the Rainbow books. http://niap.nist.gov/cc-scheme/ (go figure, CC's site is discontinued *shrug*)

IEEE: has started an organization/committee on secure OSes Baselines: http://standards.ieee.org/announcements/pr_p2200.html

ICSA Labs: I had thought they did OSes as well as security applications/devices but unfortunately no. For those interested, visit it here: http://www.icsalabs.com/

Going by vulnerabilities alone doesn't give an indication of success for a secure system. It's gives an indication of good programming perhaps. There is a website -- but damned if I can find the thing -- that shows which Open Source programs have good secure, stable code. NMAP was the only security application there. This site is for testing Open Source applications since Open Source developers often are missing the funds to prove that their applications are sound, stable and secure when it comes to government standards.

Meeting a standard set for security and that is accepted by an industry and/or government usually is an indication of security-worthiness. Does this mean that OBSD isn't a secure OS? Not necessarily. Rather, it's definition of security is different than what the industry may be looking for or perhaps there is nothing left in the budget to test it's security-worthiness against other systems.

Now, in my search for finding more information about the standards for secure OSes I did find the following article which might be a worthwhile read by all.

Lastly, in a PM to me, catch stated that the tutorial is based on a "mathematical fact". Since this wasn't clear to me (and I think others) perhaps you could clarify this for everyone. It might help put things in context (since that seems to be an issue). :D

Quote:

---

Originally posted here by MsMittens
Umm... Double check that. The portion you quoted is
That is from the bottom of post 12. My post. No where does catch state this.

---

That is correct, however I took 5(etc)s post to mean that he would first respond to the first quoted block, and then to the latter. I suppose it lies in the interpretation, but to me, clearly the first part of his post is aimed at the first block he quoted.

[quote][b]No. From the standpoint of the fact I asked you for specific proof of OBSD being secure. You stated:
[...]
So in the case of OS 9, which AFAIK, never had any CERT worthy vulnerbilities, wouldn't it be a secure OS? When I asked for reports on the security of OBSD I was hoping that there is some 3rd party that has done a study on it and has stated that it's secure. There are organizations and standards that do this:
[..snippage of good links..]
Yes, however again, I stress the importance of context here. How often is MacOS9 used as a server? I would say little to none at all, and virtually all of the CERT vulnerabilities will be in regards to server vulnerabilities, which is why such a difference exists. From a remote security standpoint, I feel confident in saying OpenBSD does a far better job protecting itself from harm than any other server operating system. OpenBSD has a host of other issues however pertaining to other things that bar its widespread use, not the least of which is application/developer support.

Quote:

---

Going by vulnerabilities alone doesn't give an indication of success for a secure system. It's gives an indication of good programming perhaps. There is a website -- but damned if I can find the thing -- that shows which Open Source programs have good secure, stable code. NMAP was the only security application there. This site is for testing Open Source applications since Open Source developers often are missing the funds to prove that their applications are sound, stable and secure when it comes to government standards.

---

Using the count of the vulnerabilities is silly, I agree. If you look at the meat of the vulnerabilities, and the general statements made in response, OpenBSD's common indicator is that it is vulnerable because it is something that the kernel itself can't stop, or it is not vulnerable because the kernel itself can stop it. An example of the former would be Apache vulnerabilities, but in that sense, OpenBSD still is more secure since by default it still jails the webserver process as well as nameserver (I believe, I could be wrong on that). An example of the latter would be the double free() vulnerability I quoted to which BSD is not vulnerable since the kernel detects double free() and prevents it. The alternatives do not offer this kind of protection, therefore they become vulnerable to a wider range of exploits. Again, this is in the context of remote security, where a user doesn't have local access, just so we're clear. I would venture to say that this is roughly say, 80-90% of all circumstances, and indeed, even your own courses on the subject would indicate highly favouring remote security over local. Local security is another beast entirely. It is rapidly becoming clear that this is indeed quite a number of discussions itching to be had, perhaps I could start threads for each type of security? :)

Quote:

---

Meeting a standard set for security and that is accepted by an industry and/or government usually is an indication of security-worthiness. Does this mean that OBSD isn't a secure OS? Not necessarily. Rather, it's definition of security is different than what the industry may be looking for or perhaps there is nothing left in the budget to test it's security-worthiness against other systems.

---

Therein lies another discussion: are the government standards that which make up what is actually secure? It is often jokingly said that the most secure box is the one that has no operating system, let alone network connection, but that is also true. The question becomes, if an operating system is unusable, and is NEVER used but is ultra secure, its security could be quantified as both infinite, AND 0. It is both absolutely perfect in that it will never be hacked, and absolutely imperfect in its unsuitability for use.

Quote:

---

Now, in my search for finding more information about the standards for secure OSes I did find the following article which might be a worthwhile read by all.

---

Yep, def. a good read.

Quote:

---

Lastly, in a PM to me, catch stated that the tutorial is based on a "mathematical fact". Since this wasn't clear to me (and I think others) perhaps you could clarify this for everyone. It might help put things in context (since that seems to be an issue). :D

---

Well I too am interested in seeing the mathematical fact behind this, but have to wonder why it wasn't represented that way in the first place.

I said I confuse easily!!!

The original post seems to me like he thinks building security from the base up is better because if something breaks along the way you know exactly what did it and fix it. The default security just works if you want to entirely customize the system yourself. Systems pre-secured will cut down the time an admin has to spend securing the box. If your good you should know what is breaking a certain program on the system.

Also OpenBSD IMO is pretty secure out of the box. It might have had patches, but it's main claim is that it has had the fewest remote root exploits, and I think they boasted that it didn't have one for like 5-6 years(I haven't been to the site in a while). Mac OS would seem the most secure because macs don't run anything very important and everytime I hear of them it is for some graphical purpose.