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.
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.
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!
"*BSD a try today! You won't regret it!"
You BSD Tro...
Erm...hang on...
Oddly Draconis
Too cynical to live, too stubborn to die.
%cat /etc/services |grep 587
/etc/defaults/rc.conf | grep sendmail_submit
submission 587/tcp
submission 587/udp
%cat
sendmail_submit_enable="YES" # Start a localhost-only MTA for mail submission
sendmail_submit_flags="-L sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost"
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.
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.
Fine, then hack mine.
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.
IIRC, you can load them up as a module therefore you don't have to recompile the kernel. Well, I don't know the parent might have been a troll, if so then I fell for it.
The authoritive answer to *BSD setup questions is almost always on the *BSD website. Linux is a hodgepodge of out-of-date HOWTOs that usually refer to some obscure, now-abandonded beta software, and are often specific to a kernel version.
Do you even lift?
These aren't the 'roids you're looking for.
The only useful conclusion you can get from that data is that FreeBSD and BSD/OS (still two different OSes, by the way) are popular with lousy admins. Not updating your server for years isn't something to be proud of. I'll take the timely and easy to deploy patches of FreeBSD over it's ability to wait for script kiddies to own my mighty Apache 1.2.4 any day.
Programming can be fun again. Film at 11.
Programming can be fun again. Film at 11.
Heh. Just as we are talking, a new FreeBSD advisory - ARP-related remote DOS - hits my inbox, requiring me to patch my kernels and reboot... Oh the irony.
Programming can be fun again. Film at 11.
Has anyone ever done a comparative study on the pros and cons of BSD vs Linux
Linux is like living in a teepee. No Windows, no Gates, Apache in house.
Would you reboot your server with the latest security updates if you made it into the netcraft top 50? Id build a new server and just keep the other one running to stay up top, i doubt that those old boxes do anything mission critical.
I run a small unix shell provider running on BSD, and while I was running though this how-to, I came accross a number of things not set-up for a secure system.
Congrats to the wonderful person who wrote this document, I found it increadably useful!
metamod to the rescue!
The World's Worst Webcomic!
And your point? Lets see if we can waste bandwidth instead...
I tried that and now my friends can't get my emails. You don't know SHIT about locking down a box.
Yes, I'm joking.
-Looking for a job as a materials chemist or multivariat