On 10/14/07, Aaron <[EMAIL PROTECTED]> wrote: [snip]
> I guess with all the hoopla about 'hardening'/trusted this and > that/fuzzy knobs(i.e. SE Linux) i got a little overzealous looking for > ways to tweak things (which i know can end up either making things less > secure (especially with false sense of security) or just plain breaking > them), but if there is/are acceptable, ways, I'd at least like to be > aware of them and the scope of their use from the people that know > OpenBSD best. You're asking the right questions. Some of the answers, unfortunately, aren't as cut and dry as one might hope at first, and this stems from the fact that some security measures are sometimes subjective. What one person might see as a good hardening measure might be considered completely useless to another person. Ultimately it comes down to whether you feel a hardening measure makes sense for the gap you're trying to cover in your circumstance. OpenBSD goes a very long way toward providing a very hardened Unix system out of the box, without you having to flip a set of switches to turn them on. You can see them everywhere. Run a web server using the included httpd and you'll have the benefit of chroot'd operation. Run the in-tree BIND as a nameserver and you'll find that it employs a number of security improvements out of the box which make it a safer system. This kind of stuff exists everywhere in the system and they are examples of real, practical, and effective things which a.) do improve security of a system against known threats, and b.) don't required complicated decisions by the admin to kludge them into place (a la some of the policy wrappers that exist out there.) Figure out your threat profile for your anticipated use, figure out from that how those threats will impact the services you intend to run, and address those with controls you feel you can put in place that can mitigate those threats. External controls might help, like firewall or IDS/IPS, and don't forget you can use PF locally. See if you think a file integrity checker makes sense. Don't run things as root that don't need to. See if you can help things out with policy and technical enforcement to back it up (like if you have shell users, and you're afraid they'll choose weak passwords, configure SSH to only support key-based authentication and make that your authentication policy. ...and so on. DS
