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."
Where the hell is SECURE?
I also had to compile in IPv4-to-IPv6 translation support. It wasn't even in the default kernel! Give me a friggin' break. And I suppose I'm going to have to read something to figure out how recompile my kernel!
To parent: I think I see a nice shiny new Windows box in your future! You don't have to understand security with Windows. And don't worry, I think they got the last of the bugs worked out. No more security problems now!
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.
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.
Recently I had an experience to use FreeBSD. I had heard many great
things about it, and was excited to replace a dead Linux firewall with
this OS. Unfortunately as things turned out, FreeBSD proved to be more
nightmare than solution.
When not attending classes at my community college to get my
humanities degree, I work part-time at a printshop. Our Linux box
there finally gave up the ghost. I'd heard that FreeBSD was incredibly
secure so I talked my boss into putting that on as a replacement.
Part of the appeal of FreeBSD was its history. A fork of the Linux
kernel, it was originally intended for Steve Job's failed NeXT cube.
Recently, its found a home amongst the ignorant and easily-fooled as a
firewall OS (later on, we'll see how Job's reached back to use FreeBSD
in OSX. This will be important later!) BSD was also famous for an
incident in the early 80s, where they were sued by Microsoft when the
BSD developers stole the TCP/IP stack from Microsoft's PC-DOS.
Once my boss gave approval, I quickly headed over to FreeBSD.com and
downloaded the ISOs from the web site. Our box was pretty
state-of-the-art, a two-CPU'ed Pentium III. Installing it went pretty
flawless and I had high hopes for our new firewall.
Almost immediately however I began to have concerns. I noticed no
where did FreeBSD display the terms of the GPL. Since its based on
Linux, this should be a requirement. Apparently the history of theft
amongst the BSD developers still continues!
I was even more shocked to learn that the ipchains rules we'd
carefully setup on our Linux box would not work on FreeBSD! Perhaps
FreeBSD is still using a SHARE-based networking security from the DOS
TCP/IP stack! Or more likely they just haven't caught up to Linux and
are still using iptables.
Whatever the case, almost immediately our box was rooted. FreeBSD
proved to be aptly named as the box was "free to be hacked" by the entire world.
Later on I would find out that despite its claims of being secure,
FreeBSD's default configuration appears to start up every service
known to man! I find it shocking that an OS commonly used for
firewalls would have BIND running by default.
Then there was the OpenSSH holes. I would later learn that FreeBSD has
a history of remote exploits. Perhaps they should work with the team
at RedHat, as RH knows how to secure their distros.
After spending a week trying to patch a leaky firewall, I gave up. I
found an Mac SE/30 and put OSX on it. I then installed Norton Personal
Firewall. That became our firewall and I'm proud to say that its been
happily running for two weeks without a single incident. I find it
funny that despite FreeBSD users arrogant claims of superiority, a
humble SE/30, running an OS that's loosely based on FreeBSD, performed
much better. Perhaps its another failing of open source versus
commercial software. Whatever the case, its clear that FreeBSD has a
long ways to go before it can be taken seriously.
Well taking recent events remove ssh and sendmail. Access via telnet only. No one will ever see my password that way
Rus
Cheap UK and US VPS
*generic BSD troll*
How about server stability?
take a quick look at Netcraft's longest-uptimes page and see what OS is most prominent on that page.
Here's a summary for you.
BSD/OS and FreeBSD: 50
GNU/Linux (all distros): 0
All other *NIX's combined: 0
Windows (98, XP, 2k and 2k3): 0
Mac OS and OS/X: 0
I'd have drawn a pie chart, but I think you know what a circle looks like already..
455fe10422ca29c4933f95052b792ab2
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
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.
You mean like the dedicated chapter on Network Adress Translation in the official handbook? (http://www.freebsd.org/doc/en_US.ISO8859-1/books/ handbook/network-natd.html)
No, no, no, no. This was the funniest line.
"Then there was the OpenSSH holes. I would later learn that FreeBSD has
a history of remote exploits. Perhaps they should work with the team
at RedHat, as RH knows how to secure their distros."
This really has to be modded up as humorous.