Slashdot Mirror
Installing A Secure FreeBSD Box
ltwally writes "The guys over at LittleWhiteDog have a how-to on securing FreeBSD. Topics range from the basics to custom kernels, blowfish encryption, smtp, and custom firewall scripts. Definitely worth a look if you're running a FreeBSD box, or are interested in *nix security in general."
Never heard of Gentoo? How about LFS? How about downloading the source and compiling it yourself?
I didn't know that packages in FreeBSD were actually source! I thought ports were source?
Why not just write your own code, after all, you wouldn't want to do what the author wanted to do, now would you?"Now that just hurts. Obviously there is no consideration of SRPMS? What about Portage? It can't be THAT bad, after all, they did port it to FreeBSD.
An objection I have to the 'standard' OpenBSD install is the 'kill a process with processor time' problem.
Named - running along fine than BLAM! Dead process.
Or rsync as another example.
I understand the 'why' - denial of service concerns via run away processes. But to deny a service you want by killing it? Naw, sorry. The cure is worse than the problem.
Just wandering what sendmail uses port 587 for? I haven't disabled it in the past as I assummed it was need for sendmail to work, but maybe not according to this article!
This request is outrageous. There is any amount of material on the net already about security theory and practice. I've read most of it myself. How much of it am I practicing myself? Not very much. I'm not a full time sysadmin, I sysadmin during my recess breaks from my development activities. Why do I not bother to take security measures I hear preached on every street corner? Because the devil is in the details, and I can't afford to have my FreeBSD server go offline because ICMP was accomplishing something I didn't know about.
This guide is more useful to me than another dozen sermons. It gives me confidence that I can lock down aspects of the system I don't have time to understand in depth with a modicum of confidence that the essential functions of my box will continue to perform.
In my development life there are some aspects of security I work with daily: OpenSSH (tunnels, authpf), OpenSSL, IPsec. Despite my meager time budget to practice host-based security, I'm far from clueless about good security practices.
Do people forget what an incredible sinkhole of human productivity security has become? A simple overview of X.509 destroyed a week of my time. Yet another horror show more easily avoided in theory than practice.
One of the problems with Google is that you never see the thickness of the fully assembled tome. I recall an era where system documentation was measured in shelf-feet. Whenever I had the urge to make my life more complicated than necessary, I just had to look at that bookshelf and ask myself "do I really want to go there?"
I'm at the point in my life where I'm never again going to set aside whole days to master intricacies like all the special perm bits on the FreeBSD implementation of FFS.
I cherish the people out there who return from the trenches with a tattered cheat sheet with the barbed wire, machine gun nests, and landmine locations carefully documented. And then I read highly rated comments from the Rear Admiral types that "this is all well and good, but it isn't another volume of War and Peace". I would love to find to a complete set of VAX manuals on Ebay to donate to this idiot, but I don't think I could afford the shipping charge.
What this article needs is not more theory, but more warnings about "if you experience this kind of problem after making these changes, you took your security measures too far too fast". The art of security is not in knowing what you ought to be doing, it's knowing *what you get away with hardening* given other constraints, such as having any time left over to accomplish something productive.
I always remember the famous quote about building the Fermilab accelerator. When challenged about how Fermilab improved national security, someone shot back: Fermilab is the kind of project that makes America *worth* defending. People and nations who can't grasp that response end up eating their own tails.
- Hardware Support: If a vendor chooses to support a piece of hardware for a BSD OS (beyond Windows, Mac and maybe Linux) then most likely it will be FreeBSD.
- Jails:
Man page
- Applications: FreeBSD has way more ports than OpenBSD. Whether someone uses most of them or not is another topic, but chances are what you need you will probably find ported for FreeBSD already
- FreeBSD 5.* onward: Nuff said
FreeBSD and NetBSD are just as secure as OpenBSD so stick with what you're comfortable with. As for new users I'll turn the question around to you: why OpenBSD? You've already mentioned security (which I've addressed, if you think I'm wrong then point out how so) and pf doesn't count since it's already ported or being ported to the other BSD's.