ITS 3250 - Securing Systems

Security Strategies in Linux...
Chapters 1 and 2

This lesson introduces our text on Linux. Objectives important to this lesson:

  1. Background on Linux
  2. Open source concerns
  3. Distributions
  4. CIA (again)
  5. Some applications

  6. The Linux Kernel
  7. Secure boot
  8. Overview of other security issues
  9. Security updates
  10. Red Hat Vs Ubuntu

Chapter 1

Chapter 1 begins with two stories about attacks on systems running UNIX or Linux, and it observes that two thirds of the devices on the Internet are probably running an OS based on UNIX. In case you don't know, Linux is descended from UNIX. History notes:

  • MIT, GE and Bell Labs invented Multiplexed Information and Computing Service, Multics, a time-sharing multi-user operating system in the late 1960s.
  • Dennis Ritchie (who also invented the C language) and Ken Thompson worked for Bell Labs. They invented Unics, a simplified version of Multics, not meant to accommodate multiple users. It was meant to be simpler, still used a branch and leaf file structure, and still used a user shell, but wound up having a lot of small commands. It became known as UNIX.

    As you can see in the image above, UNIX spawned a lot of versions. The green ones are open source systems, while the pink ones are closed source systems. (Click the image to see a larger scale version of it.)
  • UNIX eventually led to people making more personal versions of it, such as MINIX and Linux. The text mentions that there are many versions of Linux, each of which is called distribution. There is more about that later in the chapter.

    More details about each of those operating systems are available in the pages their names link to above.

The text tells us that Linux, unlike the ATT versions of UNIX, was created as a open source operating system. Unlike Windows, users are free to add to it and to submit their additions for consideration by the governing bodies that publish the various distributions. Open source code means that the actual programs can be examined by users. This is also unlike the closed nature of Windows, Some versions of Linux are available to download at no cost, others require a fee to use them. Both sorts can be open source, but that is not always the case. The text wants us to know that open source software may not be as secure or as fully tested as closed source, commercially available software.

The text moves on to discuss a few Linux distributions that are commonly available:

  • RedHat and Fedora are two closely related distributions. Fedora is the free version that is always being developed and modified. RedHat is the commercially available version of the same product. RedHat distributions are meant to be stable versions for businesses, where Fedora distributions are more for students and people wanting to tinker with an OS.
    • Fedora is easy to say, easy to install, but it has frequent updates and releases, which make it a little unstable for an enterprise solution. We can think of it as the tryout operating system that often has its best features adopted by Red Hat. It is more cutting edge, so more likely to have problems than Red Hat. This is kind of like "Red Hat Experimental".
    • Red Hat Enterprise Linux is often referred to as RHEL, mainly to save typing. Our text refers to it as RedHat, but Red Hat is also common. The main differences about this one are that it costs money to install and use it, and it is meant to be more reliable, less buggy, and more ready to be used as an enterprise solution than the other Linux versions in this family. This is "Red Hat Official".
    • CentOS can be said a number of ways, and there seems to be little agreement about which is correct. This video clip seems pretty definitive, and it explains that CentOS is made by the people who make Red Hat, it has fewer features, and it is free, in the sense that does not cost the user anything. I know, that's what most people would think the word free means with regard to a product, but Linux is also free in the sense that it can be modified by the user. They should use another label for that concept. User configurable, perhaps? The text mentions that CentOS is unsupported, which means that it is provided as is, and the publisher offers no warranty to users. This could be considered "Red Hat Light".

  • The text briefly mentions Debian, and praises it for "being around for a long time" and for being very stable. Linux distributions are not generally noted as being stable as much as being under constant development.
  • The text says even less about Mint and Ubuntu. It merely says that they were based on Debian. According to the pages on Wikipedia, it may be more correct to say that Mint is based on Ubuntu, which is based on Debian. Each of these distributions has been famous for their available GUI interfaces, something that was not always an option in a Linux OS.

In case you need to hear about other Linux distributions, take a few minutes to look at the ten on this video.

The text goes into a short discussion of the CIA triad (Confidentiality, Integrity, and Availability) which we have covered enough in this class. It also refers to an expansion on the triad by Donn Parker, who added Possession or control, Authenticity, and Utility to the mix, making it the Parkerian Hexad. Possession points out that a hacker can steal an asset, and it is compromised even if the hacker has not used it or sold it yet. Authenticity is what we have previously discussed as Nonrepudiation. Utility means that an asset is useful. This actually means more than you may think. This quality is lost if encrypted data can no longer be decrypted, due to a lost password. It can also be lost if data is stored on a hardware device that can no longer be read. I think Mr. Parker has a point, but we should recognize that there may be no limit to the number of ways a state of security can be lost.

The text tells us that there is no real difference between the Linux versions that you put on a workstation and the ones you put on a server. The distributions that offer server versions may be offering us versions that are more hardened: no GUI, management oriented applications, or nothing more than a server might need. This article on the makeuseof web site, discusses several distributions that it recommends for server use, then continues with recommendations for distributions for workstations. Note that there is no real requirement that the devices on a given network should be running the same versions of Linux. However, from the perspective of the network administrator, it makes more sense to have fewer operating systems and more familiarity with the ones you are using. Also note that the distributions all seem to have pretty interfaces, so the idea of a server interface being harder to use is not always used.

The text discusses some Linux applications that provides various services:

  • Snort - Yes, lots of Linux programs have silly names. Putting that aside, Snort is recommended as a working intrusion detection system. Follow the link I put on its name, and you will see that it is readily available for Linux and for Windows. Follow the other link in this bullet point, and you will see a short article about several intrusion detection products available on multiple operating systems.
  • Apache - Apache is a very popular web server, partly because it is free and it runs on a free operating system.

The chapter closes with more general discussion about hacking, but it is not of much interest.

Chapter 2

Chapter 2 begins with a discussion about the Linux kernel. It is the heart of the operating system, regardless of which kernel (which distribution) we are considering. The kernel may actually have several components. The core component contains the code and drivers needed to boot the system, while modular components contain other code and drivers that may be needed by various processes and applications.

Page 21 presents a description of one method of applying a kernel patch. It is different from patching a computer running Windows.

  1. Download the patch. This description assumes the patch is distributed in source code.
  2. Apply the patch source code to the current source code for your kernel.
  3. Compile the source code to make an executable kernel.
  4. Replace the old kernel with the newly compiled kernel.

This method of patching is likely to be the first method available for any given patch. For users not interested in or comfortable with compiling code, a compiled version of the kernel may be available for download later in the life of the patch. Major distributions may offer this patch method as their only, user friendlier choice.

On page 24, the text returns to security options in Linux. Three firewall options are mentioned, but not much information is offered. A fuller discussion can be found in the article this link points to. For the moment, here is some information about two products built into Linux, iptables and firewalld:

firewalld is both the name of a service and the name of the daemon concerned with providing that service. It is a replacement for iptables service, which needs to be reloaded every time it changes. Connections are broken during the iptables reload. This is a problem, because iptables has to be reloaded each time a virtual server is brought up or down. firewalld does not have this drawback.  No doubt, iptables is an acceptable solution for networks that rarely change, but the problem that comes from using virtuals makes firewalld a better choice.

Feature comparison:

  • iptables requires that firewall rules be stored in tables which must be loaded
  • firewalld can be updated live
  • iptables can be managed with a GUI (system-config-firewall) or a CLI (iptables).
  • firewalld can be managed with a GUI (firewall-config) or a CLI (firewall-cmd).
  • Although both systems use rules tables, iptables cannot be used to manage firewalld rules.
  • Both systems update the netfilter service, which runs in the kernel. It manages network traffic with rules from its tables.
  • Netfilter runs in kernelspace, but the four management interfaces named above run in userspace.

It is important to know that you can implement a change in firewalld in the running configuration, in the configuration files read at startup, or both. This allows you to change the system without a reload or a reboot, change it at the next reload/reboot, or make sure that today's change will be in effect at the next reload/reboot as well.

The text turns to boot process security concerns in the second discussion on page 24.

  • Several Linux distributions offer the ability to boot and run the OS from a CD, a DVD, or an installation on a USB device, such as a memory stick. The text mentions that these options are readily available on Knoppix, CentOS, and Ubuntu. This is useful for recovery, and also for hacking. If a hacker boots your computer with his own copy of an OS, he will have whatever rights he wants to your system. Booting from these devices may be disabled in your BIOS settings, but a determined hacker can reset them unless the BIOS is password protected.
  • The text mentions two boot loader utilities, GRUB and LILO. Both can be used to allow the use to choose to boot one of several operating systems, can be very friendly, and can be password protected. You will want to know that GRUB comes with Ubuntu, Red Hat, and several other distributions.
  • The text also presents a virtual machine variant on the boot and run problem. If your computer is using virtual devices, it is less likely that you will notice that one of them has been set to boot from another source than it is to notice it happening in the real world.

On page 26, the text discusses security issues related to elements outside the OS.

  • processes/services - The text tells us that the number and types of processes that are automatically loaded during startup can vary from one distribution to another. We can expect that the SSH service daemon (sshd) will run to allow secure connections for administrators. The text also lists four other services that are commonly loaded on page 27, but not seem very dangerous. The author is concerned that any service that is run automatically and that is not maintained, may be exploited if there is a vulnerability in it. This is not a big surprise. The danger element comes from not being aware of the services that run by default on your devices, and not updating them even if you are aware of them.

    Further down in the same discussion, the text mentions more services that may run by default. Some of these may be worrisome: Apache, Samba file server (works across disparate hosts), Network File System (works across a network), an email server, and an FTP server. You should be able to see the potential for compromising some of these services.
  • GUI - The GUI in a Linux system sounds more hazardous than the one we are used to seeing in Windows. The author is mainly worried about machines being used as servers because the GUI can be run remotely, can be configured to run on a separate computer, and can spread infection from one computer to another because it is actually a client-server application that understands networks.
  • Authentication problems - Linux can use multiple authentication databases, which leads to the potential of compromising one and convincing the computer to use it. Linux can use pluggable authentication modules that control authentication. One of these being compromised is also a threat.
  • ACLs - The text gives us a couple of pages about ACLs which are very much like the ones we have learned about in Windows. They should be used with care to avoid granting rights that are too broad. You may also know about the basic file system rights available in Linux, explained on page 30. This system allows a user, the main group the user belongs to, and everyone else in the system to be given combinations of read, write, and execute permissions to files and folders.
  • Firewalls - The text discusses firewalls again, this time mentioning firewalld. I gave you some notes on this above, so we are fine for now.
  • Updates - Let's move on to page 35, where the text addresses security updates. Automatic updates are recommended for most users. It is no surprise that the customized systems of power users, and the elevated rights of administrators make their respective systems more attractive targets for hackers. A measure of control relating to false update may be obtained by configuring systems to update from a local repository, rather than one on the Internet. The local repository can be maintained by appropriate administrators, providing a curated experience for the other users on the system.

At the end of the chapter, the author spends a few lines comparing Red Hat Enterprise Linux to Ubuntu Server Edition, which he promises to revisit throughout the book.

  • RHEL uses Red Hat Package Manager (RPM) to build packages and put them in install files. It also uses Yellowdog Update, Modified (yum) to install RPM packages on computers running Red Hat.
  • Ubuntu is a descendant of Debian. It uses Debian Package Manager (DPM) to create and install packages.
  • Both of these distributions only have major updates every few years. Ubuntu has minor updates every six months. Support for major versions for both goes on for several years at a time.
  • Both use Apache for their web server, CUPS for their print server, and vsftpd (very secure File Transfer protocol daemon) for their FTP server.
  • Both use the GNOME GUI, but it has been customized to look different on each of their systems.



Assignments for this chapter will be found in Canvas. We will explore that in class.