On Sun, Oct 14, 2007 at 03:27:20PM -0500, Aaron wrote: > I hope i'm not out of line changing the thread but this seemed like a good > place to ask this question.
Not at all, and changing the thread title when changing the thread subjet is a welcome relief from the usual misc@ practice. > I'm fairly new to OpenBSD and have set up a few machines, nothing > production (...). One thing I did read up on (...) was hardening > beyond the default install. Two of the tools that most of the > hardening articles i found, Securelevels and systrace, (the third one > seems to be common sense), have now seemingly been rendered useless. > (...) > I'm wondering if there are other tools/ways besides these that I just > haven't heard of to do similar things (hardening of the system) or if there > is in effect no way to do the things that, these two tools, specifically > systrace has historically handled(is there really a need in the first > place?). I say specifically systrace because from the discussions i've > been reading, the whole securelevel methodology, to the people that do the > work on OpenBSD, is flawed. I'm not here to dispute or even to discuss > that point, as currently I can't program (nor afford to hire people that > can) so my likes and dislikes are moot. I'm not aware of any current `replacement' for systrace in OpenBSD. This is both a blessing and a curse; systrace gets its tentacles deep into security-sensitive code, and I remember at least one instance where that caused a bug (though not what bug). On the other hand, systrace allows one to express a security policy that's more fine-grained than the default UNIX permissions allow. > Like i say, i'm still relatively new to OpenBSD so I'm just looking for > insight, I haven't used systrace in the past, and until about a week ago > was working with securelevels but then found the aforementioned article. I > had abandoned the securelevel method in light of the 'issue'(s)/false sense > of security with securelevels and from the discussion had decided to pick > up with systrace, until i saw this thread yesterday. > Is it more common than not, to not worry as much about "hardening" the > OS, via these methods, but rather just to make 'hopefully' wise decisions, > install the least amount of software as you need, physical separations(i.e. > logging to remote server instead of sappnd'ing your logs)(but what happens > when after getting root on the system producing logs, the attacker proceeds > to work towards your logging server?) and stay current w/at least the > stable branch? > 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. It's not entirely impossible to improve on OpenBSD's default security, although the default security is pretty good. The most obvious improvement is disabling SSH logins using passwords, as has already been mentioned. It might also be a good idea to periodically audit /etc/master.passwd for weak passwords. John the Ripper <http://www.openwall.com/john/> might be useful here. There is also something to be said for dropping all IPv6 traffic; the IPv6 stack is not as thoroughly tested as the IPv4 stack, despite a lot of work by the smart people of the KAME project. In the same vein, a restrictive pf configuration might help prevent or at least mitigate the effects of exploitation. You could also take a good look at /etc/login.conf; it does a pretty good job of limiting resource usage, but it's a bit more lenient than it could be, especially for the 'daemon' group (daemons very rarely really need the ability to allocate an unbounded amount of memory). It should be noted that the 'daemon' group appears to be used only by ports, though. However, this merely prevents an attacker that has already gained access from DoS'ing the rest of the applications on the machine. If you have local users, you might also want to vet suid applications. You could also move the 'root' entry in /etc/master.passwd away from the first line; if there is a programming error whereby a suid app that can be told to parse an arbitrary file, the password hash for root cannot be discovered (see <http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=157> for an example of this problem; while this is not the only example I know of, this problem is not particularly common). This also isn't much of a problem if root has a password that is too complex to bruteforce, which should be the case. It could also be argued that, should you require an MTA that is accessible from the outside world, replacing sendmail with your favourite alternative may increase security. Finally, X11's direct hardware access is scary. However, OpenBSD already goes to great lengths to mitigate the impact (see xf86(4) and some of the papers in the www.openbsd.org/papers section). Beyond this point, it's a matter of not creating vulnerabilities while installing ports. The most important part here is to choose the most secure ports you can find, or at least the most secure ports that provide acceptable functionality. This might mean choosing Konqueror, Dillo or even w3m over Firefox. This might mean choosing PostgreSQL over MySQL. This might mean choosing mutt over Thunderbird. This definitely means running all daemons under their own user and in a chroot jail. This also means disabling modelines when using vim. There is also some possibility to improve intrusion detection; /etc/security is useful, but can be extended (and files can be added to the list to check for - see /etc/mtree). An automatic log watcher might also be useful. IDS and IPS systems tend to be rather useless in a OpenBSD environment, as they are likely to be more vulnerable than the systems they protect. Further improvements to security tend to be rather paranoid; logging critical data to a printer, for instance, is a good way of preventing an attacker from wiping the logs (but you need some way to handle him or her filling the logs faster than the printer can print). Incrementally burning a CD has much the same result, in that data that has already been written cannot be wiped without it being obvious. (Although I wouldn't bet you that the printer cannot be made to mangle the paper, or that the CD drive cannot be made to destroy the CD.) However, all of the above is not necessarily of real value; OpenBSD is very secure in the default install, and if one chooses the ports to install with care, it remains very secure. Joachim -- TFMotD: nsphyter (4) - National Semiconductor DP83815/DP83843/DP83847 10/100 Ethernet PHY
