Episode 5, Fedora

PodCast Feed


Links:
http://fedoraproject.org/wiki/
ryos-fedoraC5-install movie
http://www.tldp.org/HOWTO/LVM-HOWTO/
http://www.nsa.gov/selinux/
http://www.netadmintools.com/art94.html
http://www.netfilter.org/
http://www.logwatch.org
http://en.wikipedia.org/wiki/TCP_Wrapper
http://fedoraproject.org/wiki/Tools/yum?action=show&redirect=Yum

RYOS, Episode 5 - Fedora

Thud: The RunYourOwnServer podcast for July 9th, 2006.


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


This episode's reverse sponsor is Logwatch. Logwatch is a customizable log analysis system. Logwatch parses through your system's logs for a given period of time and creates a report, analyzing areas that you specify in as much detail as you require. Logwatch is easy to use and works right out of the package on most systems. For more details, please visit logwatch.org.



Thud: OK, Gek, tell us a little bit about the Fedora project.

Gek: Well, the Fedora project started when Red Hat actually stopped doing their free distribution. They still release all the source code under the GPL, but they stopped doing the Red Hat desktop version of Linux. They wanted somewhere where they could incubate projects and still give back to the Linux community, and have a place where the community could also contribute more, because in an enterprise setting, it's hard for them to just accept volunteers. There's usually a lot of paperwork. So they branched off that part of their distro and made the Fedora project.

Thud: OK, so then the main goal, then, of the Fedora project is kind of to be Red Hat beta?

Gek: Well not exactly. It is its own thing. Red Hat is just part of the group of people that runs it. It's a collaboration between the Fedora community and Red Hat. I don't think Red Hat is truly the driving force behind it, although sometimes I've wondered what would happen if the Fedora project started trying to compete with Red Hat and extended their development cycle, say, because now they seem to do a new release every six months or so, and Red Hat keeps support for I believe it's five years on all of their enterprise products.


I've wondered what would happen if Fedora tried to challenge Red Hat, if Red Hat would pull its support of the Fedora project. But that discussion, as far as I know, has not been had yet.

Thud: OK, so then the Fedora project is really just an incubator where Red Hat can monitor some more the cutting edge software packages to try and see if people really like them and then later on incorporate them later on in their commercial packages, is that the way it seems to work?

Gek: It seems to be that way, yeah.

Thud: So Red Hat really just supplies some of the funding and some of the people, what exactly is the connections as far as the project and Red Hat are concerned?

Gek: Red Hat has developers that are working as part of the projects, and they also have seats on whatever the governing entity is that controls the Fedora project. I don't know if they have the majority of control, but they definitely have a say in where the project goes.

Thud: OK. Well, let's move on to the installation. What can you tell us about the installation?

Gek: The installation of Fedora is very similar to Red Hat. There are a few differences. Most of the stuff that you'll see different in Fedora will be implemented later in Red Hat, so it's kind of a sneak peek at what Red Hat will look like in two or three versions, usually.


They have many of the same screens. It's going to look almost identical for the most part. What you'll notice is that certain options get turned on, like Fedora included SELinux before Red Hat did. They also had the firewalling feature turned on before Red Hat did. I think Red Hat, by default, has had it off, historically, and Fedora has it enabled, and you can select what you want to open. That did make it into Red Hat 4, I believe, I don't think it was in Red Hat 3.


Really it's not much different. You pick the same options, you go through the same wizards, and every now and then you might get a new screen, but even from version to version, the Fedora installer hasn't changed a whole lot.

Thud: You'll notice in the install video that we have on the website, one of the things we did is change the default partition types. By default Fedora and I believe the latest version of Red Hat use LVM, which is the Linux Volume Manager format. It allows you to have a lot more control over what you do with your partitions. You can expand them on the fly and things like that, but for most servers, you don't really need it. So that's the only gotcha that I know of on the standard Fedora install. You can use it if you want, you can not use it if you prefer. It's really up to what you want to do. It's nice later on, especially if you are doing a file server, to be able to expand a partition without having to reformat or loose any data or copy stuff around. It's just nice to expand it on the fly.


But that's the only thing that I personally do different on a Fedora install. Is there anything else that you do, Gek?

Gek: I usually do turn off SELinux and the firewall because I write my own firewall scripts and I prefer to use those. But I do make sure that as soon as I get the box up, one of the first things I do after the install is complete is turn on my firewall so that the box is protected.

Thud: Well, since you mentioned it, what is SELinux, and why do you turn it off?

Gek: SELinux is Security Enhanced Linux. It was developed by a government agency and it basically is a way of telling the operating system, "I want this application to only be able to do these certain things." You might limit its permissions to what directories it can write in, or what other applications it can use, or I think you can even restrict things like how much memory it takes up, things like that. It's just a way of controlling applications, and the idea is that you restrict file permissions to users and to programs, but if you can restrict application permissions as well then that's another level of security that you can put on your box.


They use SELinux, and I actually found a bug with samba on SELinux two years ago. They SELinux on Fedora because they want people to test out the permission sets that they're going to release with Red Hat. So it's a way for them to see, if I turn these permissions off, what am I breaking?


For me personally, I don't allow people onto my box that I don't trust and I don't run applications that I don't need to. So for the most part I don't feel I get a big benefit from using SELinux so I just turn it off.

Thud: Yeah, I've actually had a couple of bad experiences with SELinux getting in the way of applications. So generally I turn it off on the systems that I install as well. It's a little bit different if I were installing a system where I've got, 10 or 15 different people logging in, each doing their own thing. Then maybe SELinux would be good. But for the most part, if you're the only one managing the box, the only one that's going to have root level access, it doesn't really help it that much.


It's cool though. It's a system level firewall for applications.

Seg: It should also be noted that you can set SELinux to three different modes. You can have it enabled, disabled, or what I believe they call warning. And what warning will do is that anything it would have blocked, it will put an error in messages, it will put, I don't remember what the line begins with, but it's a specific line that tells you that, "I would have blocked this," or, "This just passed over this permission," so that you can test to see what will break without actually turning SELinux on and breaking your box.


Also, if you were running a web head, something that was public facing where you were really worried about security, then SELinux may not be a bad idea. If your application doesn't have issues or if you're comfortable enough with SELinux to change the rules then running it, it's not a bad idea, it's just not something I'm comfortable enough with to really use.

Gek: Yeah, it definitely adds to security. But it's just one of those things, if you have an application you've written yourself or if you've written your own PHP scripts, for example, you may be blocking system calls with SELinux and if you want to use it you just have to remember you'll need some extra time in order to debug all the rulesets to make sure that you actually have permissions on the box in SELinux to run those applications.


It definitely adds to security. I think a few years down the road it's going to be something that's on by default just about everywhere.

Thud: OK, since we've already covered SELinux, which is kind of a lock-down, you know it has to do with security, let's go on and do the lock-down section. What are a few of the lock-downs that you do, Gek, on a newly installed Fedora box?

Gek: What I usually do, after I've rebooted the box and logged in as root, is I run chkconfig. I take a look at the services that are currently running for runlevel 3. If you're running a server, never ever, ever have it go into runlevel 5. I don't recommend running X-Windows on any server that you care about. You can run it on your desktop, that's fine, but don't run it on the server.


But I'll go and look at chkconfig --list and that will tell you all the services that you have installed and what runlevels they'll start on and what runlevels they're off on. If you look through that list, one of the things I don't like about Red Hat or Fedora, is, by default, there's a lot of things on that you don't need. There's stuff like PCMCIA support is on, I believe in the most recent version of Fedora it actually does check to see if you have PCMCIA support on your machine. By default, the PCMCIA daemon was always running and that's not something you need. It doesn't really pose a security risk because it only affects your local box, but it does use up resources, memory and CPU. So any of the services that you know for sure you don't need, you can go in there and turn off.


Now the command you can run to turn off services is chkconfig --level 345 the name of the service and then on or off, depending on whether you want to turn it on or off for those runlevels. You're basically telling, for runlevel 3, 4, and 5, I want the service on or off. There's a lot of things in there that you can turn off. Any service that you see listed that you're not familiar with, you should definitely research it, find out what it is and determine is it something that you need to be running.


If you're not going to be doing any of the things that the smart hard drive technology allows you to use, you might not want to be running the smartd, which allows you to pull that information off the hard drive.

Thud: So other than chkconfig, what else can you do on a Fedora box?

Gek: One thing I like to do is restrict who can actually access the box on port 22. Just because I want to make sure, as best you can, that the only people who have remote control of this box are the people I want to have remote control of the box. So usually I will use iptables and I'll set up a rule to simply say, "Block anything that isn't from this IP address." Or a series of IP addresses, if I'm allowing more than one person to the box.


But in some situations you can't do that. There's sometimes where iptables, if you've got a firewall script that you normally use, for some reason, say you're running a game server like Quake, that firewall script won't work because you block some things too restrictive, and rather than go through the hundreds of rules in your firewall script, you just want to turn off ssh access, you can do it with two files that are called hosts.allow and hosts.deny. They're part of TCP wrappers and they're compiled into a lot of the older UNIX daemons. Ssh is one of them and if you go in there, you can go into hosts.deny and tell it you want to deny all hosts. Then you can go into hosts.allow and say, "I just want to allow this specific host."


That actually works because anything in deny happens first and then allow overrides it. So that's one way to lock down the box. If you're not comfortable with iptables that would also be an easier way of restricting SSH access to the box.

Thud: That seems like an old-school firewall. What about something more modern like iptables?

Gek: iptables actually has a pretty easy to understand layout, but you do have to read up on the Netfilter part of the kernel to really understand how it's working. There's three main tables and they are nat, filter, and mangle. And really most of your work is only going to be on the nat or the filter tables. I think, by default, you're dealing with the filter table. That's INPUT, OUTPUT and FORWARD, where you can tell it, "I want to allow anything coming into port 80 or port 25," if you want to allow email, "Anything coming into those ports is fine, but I want to deny everything else."


And then that way you can just open up the parts that you need. The syntax is kind of confusing but well documented. If you look online you can also find a lot of example firewall scripts.

Thud: OK, so now that we've covered the installation and some lock-downs, what about updates? How would you keep a Fedora box updated?

Gek: Fedora uses a program called yum. They've made updating your box pretty easy. All you have to do is log in as root and do yum update, or as a user with sudo access, just run sudo yum update and that will download and install all the latest RPMs for the packages you have installed.


There are many, many repositories for Fedora that are not part of the actual Fedora project but make available other packages that are nice to install and they all will also update their packages and work through that same yum update mechanism as long as you have them set up in your yum.conf file.


If you are using Fedora something you have to watch out for is that because they release every six months, if you want to keep your operating system current, you are looking at reloading your operating system every six months. Like many distributions, they do have an upgrade path but I am a firm believer in not retaining the system that was previously on the box. Anytime I do an upgrade it may make it more of a headache but I think it saves me problems down the road. I always copy all the data off, erase everything on the box, format it, and then reload the OS from scratch. For a development cycle of six months that's kind of a pain. You end up doing a lot of reinstalling when really that's not what you want to be spending your time doing as a sys-admin. You want to be able to just update the box and know it's OK.


Fedora also end-of-life a product after two other versions have come out. So if I install a version today which I believe is Core 5, when Core seven comes out they drop support for Core five and I can no longer get updates for it. That's not a really big deal if it's just one box but if you've got a whole bunch of boxes that makes it a nightmare to maintain.

Thud: Yeah, you are forced to reinstall at the one year mark. It's best to reinstall at the six month mark, but at least you can get patches for another six months. At that one year mark you have to reinstall. That does complicate things especially in an enterprise environment.


All right for this episode's moment of sec, we are going to talk about the importance of log files. Gek, how important are log files?

Gek: Log files are the lifeblood of any type of troubleshooting or security or monitoring. You have got to have good log files and you have to be able to trust your log files. One of the things that Fedora, actually I think most Linux distributions include some form of it, one of the things they include is a process or script that will send you a copy of your log files on a daily basis.


Logwatch, which actually comes with Fedora and Red Hat, will also summarize those log files so that you are not just looking at hundreds of lines of code. It will actually say, "Someone tried to hit this port and iptables blocked it 589 times," or, "These people connected through SSH or these users used sudo and ran these commands," and that gives you just a very summary glance of, "Hey, these activities were going on my server yesterday." And that's great because then if something doesn't quite look right then you can go and examine the log file and actually take a look and see what really happened and not just, "Bob ran cron."


There are programs like swatch and sec that you can kind of use to set up your own rules. I personally use swatch on my firewall so that any time a snow snort alert that I consider critical happens, it shoots me an email just to let me know. So if it is something really serious and I am worried about somebody getting into my network at home, I can SSH into my stuff at home and firewall that IP address or take some kind of a countermeasure on the firewall. But for anything that you really want to do that is heavy-duty, I really recommend sec. It is a little bit more cumbersome to use but it is a lot more powerful and is a lot more robust.

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

Gek: Fedora is a good distribution if you want to see what the future Red Hat distributions are going to look like, what the the future versions of Red Hat Enterprise Linux will be in a year or two. Fedora is great for that that because that is what Red Hat had in mind when they sponsored the Fedora project.


It is not something I would recommend for a production server only because the development cycle is so short, but I've used it on my work station for a number of years. I haven't used I recently because I've switched to Mac and I'm pretty happy with that, but before that I used Fedora for two or three years and I was happy with it. It really does show you what the cutting edge of Linux looks like. It is not even bleeding edge. There are still versions beyond what you get with Fedora, but they do give you the latest KDE and the latest Gnome, the latest Postfix. You keep up with what's going on.

Thud: Yeah, I think Fedora is probably a good place to start learning some of the new technologies that will be out in the enterprise and the Red Hat enterprise versions later one. One of those being SELinux for example. Fedora had SELinux it a full year before Red Hat incorporated it into their products.


So it's a good place to be on the cutting edge of what Red Hat Enterprise will be and you can get used to the technology and get used to a lot of the features. They do end up taking out some of the features between Fedora when it gets built into Red Hat, but the base things like the LVM and things like that are included in the Enterprise and you get a at least six months head-start on playing with the technology and getting used to it before you really have to do it on your day job on production equipment with Red Hat Enterprise. Fedora is definitely a good testbed to see where Red Hat is going to go.


[music / outro, "Down the Road" by Rob Costlow]

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 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