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."
But unless one really needs something special out of FreeBSD ( eg, SMP ) why not start with OpenBSD?
/me likes OpenBSD :)
OpenBSD's security is alot more than just services disabled by default, and is usefull well beyond a firewall.
...still needs work.
NitPick 1: a cvsup cron job every 3 hours? Cvsup traffic is always high at the top of the hour because everyone does this. Fix: Look at the second hand / second readout on your watch right now. Pick that value as the minute your cron job does its thing. It's a simple psuedo-randomizer that makes things a little easier on the cvsup.freebsd.org servers.
NitPick 2: a cvsup cron job every 3 hours? (Is there an echo?) freefall.freebsd.org is the authoritative cvsup source. Its only client is cvs-master.freebsd.org, which checks freefall every 6 minutes. Official mirrors are allowed access to cvs-master, and generally update between 1 hour and 4 hours. If you're updating more often than once a day via cron, maybe you need to think about becoming a mirror. Besides, the smart thing to do is do a cvsup on your src and ports trees and keep it back a day and watch the mail lists to see if anyone else's machine burnt their toast. If there aren't (m)any complaints, go for it.
Nit 3: An official warning and a gruff "who the heck are you" getty message aren't going to keep kids from nmapping you. Try Fooling Nmap for Whatever Reason. If you're worried your OS and your kernel version will give you away, maybe you aren't keeping as up-to-date on your security lists?
Nit 4: Sendmail. Sure. You could run sendmail, but why not look into qmail, written by djb. While you're there, check out djbdns if you need DNS services.
This is one of the most comprehensive articles I've ever seen about locking down a FreeBSD box. It covers stuff I didn't expect, including using schg to deny the ability to overwrite files.
:).
The but is that I felt it could have included more information about *why* you'd do these kinds of things instead of just how. This information would help people who are newer to FreeBSD understand how to expand on this. While it is comprehensive, I feel it could give people a little more idea of the 'why' rather than the 'how' so that people could do some securing of their own
www.sitetronics.com/wordpress
> Never heard of Gentoo? How about LFS? How about downloading the source and compiling it yourself?
First: Haven't heard of LFS, so please elucidate. TLA's don't google well (now there's an idiomatic phrase). As for downloading and compiling the source: that's precisely what ports do. More to the point that they download, patch, configure, compile, package, and install automatically but that you can manually intervene in any of these steps, and that you need only edit very modular and flexible makefiles to do so. Gentoo requires a special tool, and if emerge doesn't fit your needs for one purpose or another for a particular package, let's hope you're a very dedicated python hacker. There's a lot of very neat stuff portage does but it looks to have started complex, not based on anything all that simple or flexible.
> I didn't know that packages in FreeBSD were actually source! I thought ports were source?
Packages are binaries. Ports builds and installs a package. If you want custom, you just cd to the work/src/ directory and you have the source tree just like the author made it (modulo any patches) from which you're free to do the usual configure && make before going up to the port dir and doing a "make package" (or just "make install" if you want to auto install it). Compare this to the tedium of customizing a source RPM.
I've finally had it: until slashdot gets article moderation, I am not coming back.
And while the post was somewhat tongue-in-cheek, at the same time it outlined an underlying truth.
NAT was cutting edge circa 1997; it's now 2003, very nearly 2004, and that means NAT is paleolithic technology. I am well aware that traditionally FreeBSD is thought to possess one of the nicest TCP/IP stacks in the business, and that much of that stack has made its way into commercial offerings, but still, at this point in time, the stack ought to be sufficiently modular that a computer with two network cards in it can be immediately turned into a NAT bridge/router with no more than a few lines of text in a configuration file, NOT A RECOMPILATION OF THE KERNEL!
And no, those of us in the real world don't have time to Google for weeks on end trying to find instructions on just what it is we're supposed to do as part of this kernel recompilation, only to find that no two sets of instructions are the same. At the very least, there should be an official FreeBSD document at the official FreeBSD website that gives the officially sanctioned set of steps one needs to perform to get NAT bridge/routing up and running on a FreeBSD platform.