Episode 3, FreeBSD

PodCast Feed


Links:
Freebsd.org
FreeBSD Documentation
Get FreeBSD
Install FreeBSD
Donate Money to FreeBSD
Disable Sendmail
FreeBSD Firewalls
FreeBSD Partitioning
How to keep your ports up to date
Jail Man Page
OpenNTP

RYOS, Episode 3 - FreeBSD

Thud: The RunYourOwnServer podcast for June 24th, 2006.


Thud: In this episode, FreeBSD. Why is FreeBSD a good server OS? Some information on the installation of FreeBSD, basic lock-downs, OS updates, and a moment of Sec.


This episode's reverse sponsor is the Fedora Core project. Fedora Core is a free operating system that offers the best combination of stable and cutting-edge software that exists in the free software world. For more information, please visit fedora.redhat.com.

Thud: all right, so let's jump right in. Seg, can you tell us a little bit about the history of FreeBSD?

Seg: If you're interested in learning more about FreeBSD history, it is outlined in the first few chapters of the handbook, which is the FreeBSD handbook which is available at freebsd.org. I've read the history a couple of times, but it hasn't stuck with me. All I can really tell you as far as the history goes is that it's a UNIX-based operating system.

Thud: OK, well what's the main focus of the FreeBSD project?

Gek: As described by Jordan Hubbard in section 1.3.2 of the FreeBSD handbook, the goals of the FreeBSD project are to provide software that may be used for any purpose and without strings attached. Basically, they want to give you a free OS that is free, much like OpenBSD's philosophy, where you don't have to pay for it, there is no commitment. They are not anti-GPL like OpenBSD. They do include GPL in their code and their source tree actually falls under the GPL.

Seg: And the GPL is, of course, the GNU Public License which you will see a lot.

Thud: Why is FreeBSD a good OS for a server?

Seg: I believe that FreeBSD is a good OS because it offers a lot more functionality than other server operating systems, including the other operating system I use the most, which is Solaris. I find that the tools the tools that I use a lot, grep, ls, sed, awk, all of these very core programs that be used by anybody who uses these kinds of operating systems, the versions that are available in FreeBSD and in OpenBSD as well and in Linux have much more functionality than those found in Solaris.


I don't mean to bash Solaris. I actually enjoy using Solaris in a lot of different environments, but when I can get away with it, I prefer to use FreeBSD because it's a lot more functional. As a systems administrator, as an admin of a server, that functionality helps out a lot down the road in daily usage.

Thud: With the default install of FreeBSD, are there any gotchas buried in the install somewhere?

Seg: Yes. Sendmail by default is installed and turned on. As soon as you get up and running, you are running a mail server, and a bad one at that. One of the first things you want to do when you install FreeBSD is to disable sendmail. There is a file called rc.conf in the /etc directory. There won't usually be anything in there after a first install, but the variables that you need to dereference to put in there to disable sendmail are going to be in /etc/default/rc.conf.


Now the /etc/default/rc.conf contains almost all of the variables that rc.conf will read, things that you can configure. But as you will read in the default/rc.conf file, do not edit that file. Instead, put the overrides in the /etc/rc.conf file.


In the case of sendmail, I believe what you need to do in there is sendmail_enable = "none", and the word "none" can be uppercase, lowercase, it can be switched case, it doesn't matter. sendmail_enable needs to be all lowercase, though. If you are curious as to what kind of options you can set in the rc.conf, again, go to /etc/default/rc.conf. You will find a list of variables in there and what they can be set to. Each variable has a comment next to it which will indicate how it's used in the system.


Also useful after an install is to load ipforward, which is the default packet filter for FreeBSD. The packet filter is, in essence, a firewall, but it is run as software and it is bound to the kernel. In older versions of FreeBSD you had to recompile your kernel to enable ipforward support, but in newer versions, I believe starting in 5.3, you can just load a kernel module during runtime and enable ipforward support.


So this means that if it came down to it, after the install, you would not have to reboot the server to load and ipforward firewall, whereas before you had to load the source tree, add the options into the configuration file for the new kernel and then recompile the kernel, which took a while, depending on your system speed and resources, and then after that you had to reboot and install the new kernel. To load the ipforward module during runtime, that information is available in the FreeBSD handbook, you use the kldload with the name of the module, which I forgot off the top of my head. The module can be loaded on boot; in the /boot directory, there is a configuration file in there where you can add the name of that to-be-loaded module.


So, with sendmail disabled and a packet filter loaded, you are ready to start using your server.

Gek: Actually touching back on sendmail, if you're someone like me who prefers Postfix, if you go to the ports-tree and you install Postfix from ports, one of the things it does as its final steps is ask you if you want to disable sendmail, and it will actually take care of making the changes in the rc.conf for you.

Seg: Oh, I did not know that. When I installed Postfix, I don't remember seeing that option, but yeah, that's pretty cool.

Thud: OK, are there any other gotchas that are in the install process? Are the default partitions what you would normally need for an everyday server?

Seg: By default, if you let FreeBSD choose the partitioning scheme, it will put the most free space in the /home directory. The thinking behind that is, you're going to be uploading stuff to the server in your home directory. If you're going to do it over scp, theoretically over ftp, you're going to be loading into the home directory, so you would want the most space there. If you wanted to upload a massive application, then you would upload the zip there, you would untar it and work with it and then install it from that location. In that thinking, it makes sense to put the most space in /home, but for me, I want the most space in either /usr or /var, depending on how the server is going to be used.


One of the latest servers that I had installed for me and I'm using in production right now, they used the default layout for it. I completely forgot the way FreeBSD had set it up, of course I got the server from these guys, there was a ton of space at /home that I can't use since it's /home. When you are doing the partitioning setup, it's not very user friendly. The actual program to do the partitioning, it's not something you can just dummy through. In fact, the partitioning setup for Solaris is a heck of a lot easier to use than FreeBSD's.


If you understand what a cylinder is, you can do some math and you can definitely work around with FreeBSD's partitioning setup when it's being installed.

Thud: OK, what are some of the common lock-downs that you can do on a FreeBSD machine? I noticed during the install there's a section where you can add users. Is it usually a good idea to add your main user there, or should you just use the box as the root user?

Seg: At least add one user account for your use at that point. At the end of the install, if you do make that one user account, you're going to have three important accounts. You're going to have the root account, you're going to have the toor account, and you'll have whatever user account you created. The toor account is a backup root account. If you were to lock out root somehow, you could get in with toor. Well, one of the lock-downs you want to do when you first get set up is disabling the toor account, including just deleting the user from the server.


Now, as root, when you're on the server, if you've installed I assume you're going to be on the console, on of the first things you want to install to help lock down is sudo. Sudo is available in the ports. Install it and then enable the user account that you created to have access to sudo and then use sudo to su to root. "sudo su -", hit enter, type in the password of the user account, and you will be sudoed to root.


One of the interesting lock-downs that gets overlooked a lot is looking down syslog. Again, this is a variable you can set in /etc/rc.conf. Syslog, by default, will run in one of its secure modes, where it will listen to port, oh my goodness, I think it's 512, I'm probably wrong about that, it'll bind to ports in TCP and UDP and listen for incoming syslog requests, the idea being that other servers in the network could log to the server that you're on. By default, that's the mode that it turns on to. You're want to actually turn that off. The syslogd flags that you want to include are -s -s, two -s, and that'll lock it down into secure mode. So when syslog runs, it will not bind to any ports, it will simply log to local disk.


If you run it without any -s, you can actually let it log off-site to a loghost somewhere else that you set up. That's not a secure idea, it's not a good idea on a public network. If you've got things running on a private network where there are many levels of security and many different ways to secure down the systems and the networks, then it makes sense to log off-site to a syslog server, but you don't want to syslog out over the Internet, definitely not.

Gek: There really isn't much lock-down you have to do to it. What you've been saying, Seg, is true, there are a few things you can do, but most services are turned off by default, unless during the install you tell it you want to turn things on.

Seg: Yeah, I think after I finished locking down the server, that pretty much consisted of locking down NTP, which means disabling the default NTP and using OpenNTP, securing syslog, killing sendmail, and I believe that was it. I did a netstat -an and looked at all of the open ports and there was nothing aside from the web server that I installed and was using.


By default, it's pretty locked down. The one thing that is required, as far as security goes, is you absolutely must get a packet filter. It could be ipforward, pf, ipf, there are a lot of different packet filters out there that will run on FreeBSD. Pf and ipforward, in my opinion, are going to be the two tops. I', most familiar with ipforward. You absolutely, positively must use a packet filter and then, of course, once you've installed a packet filter, you have to write a good firewall.

Gek: We've been talking about mostly system-level security. They also include something to help with application-level security. It's a port called portaudit. You can install it from the ports tree, and what it is it's a database of vulnerabilities for all of the ports that are in the tree.


What it'll do for you is when you go to install something from ports, specifically I know samba comes up a lot, if you try to install samba from ports, portaudit will throw up a warning saying that, "Hey, this has some bugs, you need to look at it." You can find out what exactly the vulnerabilities are, and if you don't care, you can tell it to go ahead and force it to install the port. That's something that is handy if you're not really somebody who's studying what's going on in the hacking community and current warez and current exploits, that's something to give you some assistance.

Seg: FreeBSD, at its core, is relatively secure. I'm not going to say it's very secure, I would say OpenBSD is very secure, but FreeBSD is relatively secure. The ports collection, though, is the main point of insecurity when it comes to FreeBSD. I like FreeBSD because it's very functional, it's very easy to use once you get comfortable with the way that things are laid out. It's very easy to use and I enjoy using it a lot, but I always stand weary of installing new ports.


Although installing ports and managing ports is very easy through pkg install, pkg delete, and pkg info. The code that is in ports is not audited very well, if at all. It's basically, if you can write something that will install in FreeBSD and you write a port for it, you compile it and make a port for it, you can pretty much get it into the list of ports. If you write a vulnerability for it, if you write a rootkit for it or something and it doesn't get caught right away, then, hey, you win, you just hacked a lot of boxes.


That kind of stuff has actually happened in the past from I'm told. I've never, thankfully, that I know of to date, have never been a victim to something like that. The people who write bad ports, people read the code a lot, and people compile the stuff from source a lot, there is actual bookkeeping done, but it's not on a professional scale, it is not as tidily governed as OpenBSD is.


If you're going to run a FreeBSD server and are very concerned about security, that's fine. Use FreeBSD, use a good packet filter, write a good firewall, but when it comes to applications, get it from the source. If you're going to want Apache, mySQL, PHP, get it from the source. The ports work just fine, you're not loosing anything by getting it from the source, in fact you're going to gain a lot of functionality by compiling it. You know you got it straight from the horse's mouth, and you're going to install the way that you want it to be installed, rather than the way it was installed for the package.

Thud: So basically, you're saying that ports aren't always the best way to go, even though it's easier.

Seg: Yes, yes. Ports are very easy to use, extremely to use. They're very easy to upgrade, they are very easy to install and de-install and things like that. Which is great, but they're not as secure as getting from the source.

Thud: So, let's go into a little bit about keeping FreeBSD up-to-date. Tell us a little bit about the process for keeping the OS updated.

Seg: When it comes to upgrading the kernel, there's actually a very easy way to do it. The sysinstall program that you used when you first installed FreeBSD remains on the box after the install. You can use the sysinstall program to modify existing components of the operating systems, you can install new ports and packages through it, and you can also upgrade the operating system itself. By using the upgrade option in sysinstall, it'll ask you where you want to get the files from and then it'll go out and get those files for you.


Doing it that way, it'll install the latest kernel and get the system level up-to-date. I'll tell you the ports and packages, however, is a different matter. There are a couple of ports in the ports tree that will help you in it. Cvsup is one of them. Cvsup, if you give it the right configuration file, will actually go out and get a list of all the current versions of the FreeBSD ports, compare them to the list that you've got, and then update your ports and help you out with that. There is a GUI version and a command-line version for that.

Gek: Also, they just included something that I noticed first in 6.1 called portsnap. It looks like it'll grab a snapshot of the ports tree and you don't actually have to do a cvs checkout, you can just grab a tarball that they've compiled of all of the current ports.

Seg: That sounds good, I haven't heard about that yet.

Thud: Yeah, that sounds like it would be a lot faster than using CVS.

Seg: Yeah, the CVS method I used about a year ago, and it worked but I would just set it to run and then come back the next day.

Thud: So basically, you're telling us the last time you patched your server was a year ago?

Seg: That server has been decommissioned for about nine months now, so that one doesn't really matter. As far as my newest FreeBSD servers go, the way I've been managing those, I do have ports installed and what I will do is I will actually just go to the FreeBSD FTP servers manually and do a comparison between the packages that I have installed and the newest versions. Because I am interested and I actually audit them manually, I look at them, I'll investigate to see if there have been any new security concerns with these ports and packages.


Then, if needed, I'll manually deinstall, I just run the pkg delete program to forcefully delete the old package, and then install the new package. If you do it that way, you have to do it in one sitting, it's important, because when you try to delete a package that has dependencies, pkg delete will complain and say, "I don't want to delete this, other programs are running and depending on it." So you will have to kill those programs, you have to shut them down, you have to force the pkg delete, and then force the pkg install of the newest version, that's how you do it.


If you force the delete of a package that is a dependency of another program, you're not going to have your server for very long. You're going to crash programs, you could even bring your server down if you do it that way. If you're not comfortable with doing this process, then, like I said, there are other tools that will do it for you and help you out with it. When it comes to, as I said earlier, it's important to get the programs that you want to use from the sites that they're actually writing it, get it from the source.


If you're doing it that way, it's even more work to upgrade those things. You can go to the sites, find out what the newest versions are, and then to upgrade you have to shut down the service. If you're going to upgrade apache, you have to shutdown apache, move the old compile directory that you used out of the way, get the new source, unzip it, untar it, and then compile the source the way you want it to be and then reinstall it, and stuff like that.


Depending on your system, an upgrade of Apache in that manner could probably take 10-15 minutes. I had to recompile Apache a couple of days ago because I forgot the mod_rewrite option in the compile, so I had to shut down apache, recompile it, the existing code that I had, and then I did a reinstall. It took about 10 minutes.


Keeping on top of the latest vulnerabilities, though, is a challenge. It's a job and a half in itself. After you've installed FreeBSD, you can subscribe to any of the FreeBSD mailing lists. Of course you can do it now even if you haven't installed FreeBSD. The mailing lists provide a lot of different venues for information, including development information, vulnerability information, critical security things, people looking for help, they have a lot of them in different languages and about different ports.


I stay subscribed to a couple of the newsgroups that keep me up-to-date on the latest vulnerabilities. But as great as those mailing lists are, they are not perfect. So the mailing lists are great for keeping up-to-date, but not perfect. You have to keep an eye on those, you have to keep an eye on websites that host the packages that you use, Apache, mySQL, PHP, things like that. You also have to constantly, this is all optional, I would just recommend it, you have to do checks out on the Internet, do searches for vulnerabilities and find out if your stuff is on fire or is crackable.


If a major vulnerability comes out, you'll probably hear about it, whether you read it on Slashdot or if somebody comes up to you in the office and says, "Hey, guess what, there is a new sendmail vulnerability, you should patch!" That's great, but for every 10,000 different vulnerabilites out there, we will only hear about one of them that way. So it is a full-time job to go out and always try to keep ahead of the curve, and find out what's broken as soon as you can.

Thud: I always try to stay subscribed to mailing lists of the operating systems, or even just the packages that I use. That's usually where you're first going to hear about a problem. Even if you hear about it beforehand, before they have the fix for it, at least you know there is an issue and that they are going to work on it, and you should be expecting to plan a patch run on your server in a couple of days when they do have the fix.

Gek: Also, you can't stress enough, especially with the BSDs, how great the documentation is. Everything that we've been talking about is completely documented in the handbook. FreeBSD's handbooks are awesome.

Thud: Yeah, it's probably even properly documented there.

Seg: Everything that I've learned, about 99% of everything that I've learned about FreeBSD, I've read read out of the handbook. If you want to know it as good as I do, which is not that well, but I guess it's better than some. Look it up in the handbook. The handbook is great. There are a couple of things that I found that are not as up-to-date as they need to be. Recompiling the kernel is one of them. Still, it's your best source for information for that kind of stuff.

Thud: For the moment of Seg this week, we're going to cover, actually, two things part of FreeBSD. One of which has already been mentioned, which is port audit, and the other one is FreeBSD's jails system. So Gek, tell us a little bit about portaudit.

Gek: OK. Well, we mentioned portaudit helps you to keep track of what vulnerabilities are affecting software that you're about to install, but it can also give you a report on what software you have installed and what it's now vulnerable for. What you do is if you run portaudit -F, that'll fetch the current security database from the FreeBSD servers, and then you do portaudit -a, and that'll print a vulnerability report for all installed packages. There are other options, they're all covered in the man portaudit, but it's a pretty cool little addition to the ports-tree. It makes things a lot easier. And like Seg said, you don't have to do as much legwork yourself to try and track down all the vulnerabilities.

Thud: And that's only been in since what version of FreeBSD?

Gek: I think I saw it in 5.5, but it may have been earlier than that.

Thud: OK, so tell us a little bit about FreeBSD's jailing system.

Gek: OK, I actually did something kind of crazy with the jail just for testing purposes. I wanted to see if I could set up Postfix transports and use each domain that I own on a different jail. So what I ended up doing was creating six jails total, having mail go to my primary firewall and then get transported from that Postfix to the Postfix instances in each of the jails. It's very easy to set up. It ends up being about six commands. If you type man jail and read through the docs, they explain what's happening, what you can do, what you can't do. It's very, very cool.


I have not seen anything like it on any other OS and the only reason I stopped using it was updating it. Keeping track of six jails on the slow machine that I had this running on was insane. It would literally take me a week or more, depending on how many things were being updated to recompile all of my ports and get everything working again to the point where all my mail flowed properly and everything was happy.

Thud: So, why would you want to use a jail in the first place?

Gek: Jails allow you to lock down a specific application or environment where it's not an actual machine, you're creating a virtual machine on your box, so you can create a jail that's just for your web server and then another jail that's for your database, and the two can talk. But if somebody broke into your database, they wouldn't be breaking into an actual box, they'd be breaking into that jail.


And then to gain access to anything else, they would have to try to break in either to another jail or the host system. As far as they can tell, for the most part since there are ways to tell that you're in a jail, they've broken into one system. They haven't gained access to your actual computer. The nice thing about a jail is, if I don't like the way it's working, I can just delete the jail and start over again, I don't have to reinstall the whole computer.

Thud: Yeah, that is pretty handy. So is this similar to a chroot jail, or is this at the OS level?

Gek: This is an OS-style jail. For all intents and purposes, you are loading FreeBSD into a directory, or as much of it as you want, and bringing that directory up as an actual operating system.

Thud: So it would be a lot more secure than just an application's chroot jail, similar to what OpenBSD does with Apache, where the application is running in its own little virtual machine, kind of. It really only has the libraries that it needs and not much more. So the FreeBSD-way of doing jails is much more secure because it's actually at the OS level.

Gek: And you can actually run it as just an application if you wanted to. The jail works in a similar way as chroot if you set it up that way. If you follow the instructions in the man pages, you'll actually end up with a virtual system. You can go into the system, pull out all the files and libraries that you're not going to use and shrink it down quite a bit so that it's just the files that the application needs.

Thud: OK, we're about out of time. So how about some closing remarks?

Seg: FreeBSD is a good server operating system for its own reasons. Just the way that operating systems are good for their own reasons. I choose FreeBSD because I find that it's more functional than other operating systems in the tasks that I need to do on a server. But again, if you compare FreeBSD to Linux, OpenBSD, Solaris, Windows, or any other operating system out there, each of them are going to have their strengths and their weaknesses. For the things that I want to do, FreeBSD works very well. But that doesn't mean that it's going to work well for everybody else.

Thud: OK, Gek, do you have any closing thoughts on FreeBSD?

Gek: Yeah. My favorite thing about FreeBSD is the documentation. I think I said that before. It is incredible how much you can learn from the documentation that these guys put out. They have handbooks for porters if you want to write your own ports and put them into the tree, they have a giant handbooks for that. If you want to write kernel code for them they have a huge handbook on what they consider quality code, how they want it written, how they want it tested, how they want it submitted. They have the documentation on how to use the OS.


I think, really, FreeBSD, for me anyways, seems like a great operating system. If you want to start learning how to write code or just use a Unix-style operating system and feel comfortable with it. With Linux, sometimes it's hard to find the answers to your questions, you've got to go searching through forums, you've got to go look through mail logs. With this, it's almost everything you need is in the handbooks, and it's easily available on their website.

Thud: Yeah, I have to agree with that. I think that all the FreeBSD project, in general, have much better documentation than any of the Linux distributions, but FreeBSD, by far, has probably the best. They cover everything in extreme detail. It makes it very, very easy to learn how to use their system.


Thud: For show notes or other details, please visit our website at runyourownserver.org.


If you would like to send us feedback or have questions you would like us to answer on the show, please send us an email to podcast att runyourownserver.org.


The intro music, "I Like Caffeine" is by Tom Cote. This song, "Down the Road" is by Rob Costlow. Please visit our website for links to their websites.


This podcast is covered under a Creative Commons license. Please visit our website for more details.


Transcription by CastingWords