Where is this going, with the security side of things?
For one, OpenBSD isn't Linux-- it's just another Free OS.
Really.....? Where did one say it was linux? Well, when I think of serving I think of security IMHO.
Well for one I will start with the inadequacies of hardening, it's simple.
Hardening either before or after shipment typically includes but is not limited to the following actions:
1 Removing unnecessary packages/applications.
2 Removing unnecessary services.
3 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?(you would think)
Wrong, 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.
I am sureMANY 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.
Next,the benefits of homogenization. (Important points but a non-definitive argument.)
Nearly all exploits fall into one of two categories:
1. Configuration error.
2. Otherwise correct configuration but inadequate to provide protection against flawed source code.
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.
Compare the two systems now really, one is shipped in a soft state (systemA) and one shipped in a hardened state (systemB).
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.
2. 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.
3. Any single instance of systemA is more likely to exist in an insecure state than any single instance of systemB.
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 systemBs 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.
If you didn't know already, 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 doesnt 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 youll be ahead in security assurances, costs, time, and the skill level needed by your implementer. If you dont agree with these facts I can provide reading material.
Wee...no one should have to man command for everything. When I want to install a fourth window manager, I should have that option, without it being cryptic. pkginstall isn't cryptic, but that's because we know it. The "Newbie" install for Slackware as an example, gives basic functionality like it should, but the Full install is where it's at. You have to consider that a "l00nix" newbie doesn't give a shit which X client GUI is the default, they just want icons and pretty text so they can run Mozilla and dick around with uptime and maybe configure ls output to their liking. That is, if they can even figure out what the console is really for. They don't care about , resource files, or having to make install everything, they just want the damn software to work without issue, and the first time after installation. Point and click & KISS (Keep It Simple Stupid).
I'mnot saying this isn't possible, but it's not user friendly. If your grandmother can't understand linux, I don't think it's going to be that widely used.
For the record, I've talked to people that have had their parents/grandparents running some variant of linux. And without issue I might add. People, please do not post opinions that resulted in some form of users error.
Windows 2000 server has a lot more complicated bits underneath if you know about them.
What I like about Linux, and I recommend to anyone who feels the same, is the feeling of control - you can see what's going on, and turn it off if you don't like it. The same can't (usually) be said with Windows.
Also, while giving a pretty UI, some of the server bits in Windows 2000 (NT to a lesser extent) are actually pretty complicated, and work in a non-trivial and counter-intuitive way. I always felt that the underlying semantics were what made something hard, not how pretty (or not) the GUI works.
You try setting up file replication in Windows 2000 server ... it may have a pretty GUI but it's still a b^H female dog
*Nix is the first step to actually achieving realization of your skill. What you need to do, is jump headlong into linux,realize that you aren't good with it, read manuals, books, tutorials, etc, then go back to it... you will then realize your potential. People don't undermind yourselfs.
But IMHO I recommend solaris for server use. Granted, the configuration assistant just about drove me insane everytime i tried to boot into solaris (until I figured out how to turn it off), so did the user registration thing,(hey, I like throwing my keyboard against the wall) I've had peticuliar network problems related to hostname lookups and dhcp -which I've managed to pinpoint and fix, I'd rather have the menu-based install like freebsd has (I guess I've just grown so accustomed to it) Everything wentgreat when I was given the correct hardware.
After all, it makes sense that an operating system made by sun would run better on hardware made by sun. I currently have my ultra 10 box running solaris 9 performing dns, mail, etc services.
