This course covers the security features that you can use in order to secure your files and directories on Linux. We look at permissions, data sharing, special modes, file attributes, ACLs, and rootkits. You will also have the chance to follow along with guided demonstrations which will give you a practical understanding of the concepts covered.
- Learn how Linux file and directory permissions work and how to apply the proper permissions to files and directories
- Learn how to share data securely with groups and multiple users on a Linux system
- Understand how special modes add extra security to file systems
- Learn how to make files unchangeable even by the root user and how to secure the log files on a Linux system by making them append-only
- Learn how to secure files and directories using ACLs
- Learn about rootkits and how to discover and remove them
This course is intended for anyone who wants to understand how to secure their Linux systems.
To get the most out of this course, you should already have a good working knowledge of Linux. If you want to brush up on your Linux skills, consider taking our Learn Linux in 5 Days learning path first.
Some distributions include RK Hunter in the list of supported packages. For example, if you're on an Ubuntu system, you can simply run aptgetinstallrkhunter. But for this example, I went ahead and downloaded rkhunter from the rkhunter website. I'll start off by extracting the contents of the archive. I'll run tar z since it's compressed, x to extract v for verbose, f means do these actions on the file name that follows and I'll supply that file right there. So next thing I'm going to do is run the installer. Now I'll get in the directory, look at the installer at supply some help and so I just need to run --install if I wanna use the default layout. Now that it's installed, let's update the rules that it uses to detect root kits. Do that by running rkhunter --update. And you can see that it updated one of the sources that it uses to detect root kits. The others who are already up to date and included in the package as we downloaded it from their website. This is a new system that I installed from a trusted source. So I'm going to tell rkhunter to remember the file properties as they exist now and consider those the ideal state. So we'll run rkhunter --propupd, and it updated the file properties database. So now we're all ready to check for any root kits. So to do this, we'll run rkhunter -c and it starts performing some checks. And as it gets going here, you can see there was a warning there but it kind of scrolls by pretty quick. There's another warning. Luckily this creates a log file that we can examine later. Here, it asks you to press Enter to continue, and I'll do that again. So running rkhunter -c is an interactive process. It expects you to be here, watch the output and respond to its requests. Now that it's finished running, it says you can look at the log file located at var/log/rkhunter.log and we'll go ahead and do that. So we'll cut the contents of that file. And again, there's a lot of information there. So what we're primarily interested in, are the warning. So I'm just going to grep for Warnings and /var/log/rkhunter.log. There are a few warnings here, but let's just take one and work through it. For example, rkhunter is expecting the bin which program to be a binary and not a text file or not a shell script. I'm pretty sure that's correct because this is a newly installed system but let's check it anyway. Let's work through it. So first let's find out which package of the which command belongs to. On an Ubuntu based system or Debian, you can run dpkg -S and then the file you're looking for. This supports that bin which is part of the debian and utils package. If I were on a red hat based system or an rpm based system, I would run rpm -qf to query what package the following file was in. So now let's verify the contents of that package. We can do that by dpkg -V for verify and the name of the package which is debianutils. No output was reported and the exit status is zero. And on an rpm based system you would have used the verify option.rpm which also happens to be capital V. Now, if something was wrong, the dpkg command or rpm command would have reported a difference between what's installed on disc and what's listed in the package file. So now that we know this is not an issue, we'll go ahead and add it to the rkhunter config file as an exception. I'll go ahead and edit the config file, and I'm going to WHITELIST this SCRIPT. Again, it was /bin/which. And while I'm in here, I could set MAIL-ON-WARNING. So for example I could set my email address in here, and this way when a warning is found, it will get emailed to me. I'll go ahead and save these changes. Since I changed the file on the system, that rkhunter monitors, I'm going to update the file properties database. I would do this anytime I installed new software, installed patches, or as in this example updated rkhunter.com. I'll run rkhunter --propertyupdate like so. It's been updated. Now, let's run rkhunter again. And this time we'll only report warning. So we can use rkhunter -c for check --rwo which stands for report warnings only. It says the MAIL_CMD is not found. Let me go ahead and edit the rkhunter config file again. And this system has a MAIL x installed, so we'll go ahead and use that, update the properties file again and now we're ready to do the check. Now you can see that we don't get a warning about the which command. You would make exceptions for everything that you know is good and then you could schedule a cron job to make sure things stay the same and if they don't have it warn you. Let's go ahead and create a cron job here, we'll do crontab -e for edit and I'm going to use bi because that's the editor that I like. Let's run it, let's say at midnight. A minute, zero, hour zero, every day, month date of the week and then actually, which rkhunter user local bin. This was installed in usr/local/bin/rkhunter. We'll use the cronjob option here and we can use the --update to have rkhunter check for new rules that have been published about potentially new root kits that it's discovered and how to detect and that sort of thing. There shouldn't be any output due to the --cronjob option, but just in case, I'm going to redirect that output to say /var/temp/rkhunter. cronlog I'll call it and I'll redirect any standard error into standard output. In that way all output no matter if it's standard out, standard error, we'll go to /var/temp/rkhunter.cronlog. And that sets up our cron job that will run each and every night to check for any root kits and email us if it finds anything suspicious.
Jason is the founder of the Linux Training Academy as well as the author of "Linux for Beginners" and "Command Line Kung Fu." He has over 20 years of professional Linux experience, having worked for industry leaders such as Hewlett-Packard, Xerox, UPS, FireEye, and Amazon.com. Nothing gives him more satisfaction than knowing he has helped thousands of IT professionals level up their careers through his many books and courses.