1. Home
  2. Training Library
  3. Linux Security and Hardening | CSL4 A3.1 |

Physical Security Concepts

Physical Security Concepts
Overview
Difficulty
Beginner
Duration
3h 21m
Description

In this section, you’ll take a deep dive into Linux security. You’ll build your knowledge and skills through a comprehensive overview of the key areas that you need to know to secure Linux systems.

You’ll begin with Linux security in general before moving on to physical security and the countermeasures you can employ to protect your hardware. From there, you’ll explore authentication systems and the various account types on a Linux system, and how to secure each one. You'll also learn how to enforce strong passwords and manage account and password expirations.

In the networking section, you'll learn how to secure network services that run on Linux systems. You'll also learn how the local firewall works in Linux and how to configure it. You’ll learn about file system security and how permissions work in detail, including special modes, file attributes, and ACLs. You'll also discover what rootkits are, how to detect them, and how to remove them.

You’ll also find several security resources you can use to continue your security education and stay on top of the latest security issues for Linux distributions.

There are several knowledge checks as you go through these resources. These will help you identify any areas that you might need or want to review. At the end you’ll find a final exam, where you can test yourself on what you’ve learnt.

Learning Objectives

  • Get a general view of Linux security including roles, network services, encryption, accounts, and multifactor authentication
  • Learn specific strategies for mitigating physical security risks and protecting your Linux systems against the most common physical attacks
  • Learn about data encryption and how to implement it on new Linux systems, as well as those that are already in service
  • Understand the different types of accounts you'll find on a Linux system and the special precautions you need to take with each account type
  • Learn how to enforce good password security practices on your Linux systems
  • Learn about multi-factor authentication and how it can be implemented in Linux
  • Learn techniques and strategies to secure network services
  • Learn how to secure your files and directories on Linux through permissions, data sharing, special modes, file attributes, ACLs, and rootkits
Transcript

Linux security starts with physical security. If someone has physical access to your Linux system, meaning that they can physically touch your system with their hands, then they can bypass almost any other type of security in place. For example, if you have extremely tight network security on your Linux server, but don't protect physical access to your server, then the network security doesn't matter because it can be bypass by simply pressing the power button on the server, interrupting the boot process, and entering into single user mode. Now the attacker has unfettered access to the system, where they can disable the network security, install their own software on your system, or do anything else they want to your system. We'll be talking about ways to protect against some of these types of attacks in this section of the course, but even with these countermeasures in place, it's important that you restrict physical access to your system to only those that need access and to those that you trust. Before we get into the Linux-specific parts of physical security, I want to talk about physical security in general and share some guidelines that you should consider. At the most basic level, physical security involves keeping your systems out of the reach of potential attackers. If your servers are under your control, then you want to keep the data center and/or computer rooms locked at all times. Only give keys or key cards to people that need access. You want to keep your computer rooms locked because you don't want just anyone, any employee of your company or guests, to wander into your computer room. Even if they don't have malicious intent, they could accidentally power off the system or disconnect the system from the network. So in general, it's not a good idea to allow people access to your systems, even if you don't take into account the security implications. If the computer rooms are unlocked, then someone could enter the building and then get access to the computer room. This could be an existing employee, a former employee, or even someone who does not work at the company but gained access to the building. Be sure to stay on top of the access. As people's roles change and their needs change, their access may need to change as well. When someone leaves the company or no longer needs access, be sure to get their key or disable their key card. If you have multiple computer rooms, limit the access by each computer room individually. For example, if the Windows servers are in one computer room and the Linux servers are in another, then only give the Windows administrators access to the Windows computer room, and only give the Linux admins access to the Linux computer room. All servers should be in a locked data center or computer room. So don't keep servers laying under your desk, for example. Only allow visitors access to your data center that need access. For example, if your company gives tours of its facilities, don't let people into the locations where your servers are located. It's probably even best to not mention where your server room is located. When visitors are given access, they should be escorted and accompanied. Types of visitors that have a legitimate reason to be in your computer room include electricians, heating and cooling technicians, and computer repair personnel. Let's say that a power supply failed in one of your servers, and someone is sent from the hardware vendor to replace that power supply. That person should be accompanied while they are in the computer room or data center. They should be taken directly to the server with the issue. Ideally, you want to watch to make sure that they only replace the power supply and not perform any additional actions. Also, keep a log. When a user logs into a Linux system, there is a record of that access. Likewise, you should keep a log of who and when someone accesses a computer facility. If you have a badging system in place, then a log may be kept on that system. In any case, there needs to be a log of visitors. Maybe your company isn't large enough to have its own data center and computer rooms, or maybe your company doesn't want to be in the data center business. In these cases, here are some things to consider when your servers will reside at a location that is not under your direct control. You can think of data centers, or co-location facilities, like a bank. A bank is a place where large amounts of money is stored. And likewise, a data center is a place where large amounts of data is stored. One way to get access to large amounts of money is to rob a bank. Likewise, one way to get access to large amounts of data is to gain physical access to a data center. Since you don't have direct control of the data center, you wanna make sure it has physical security processes, procedures, and controls in place to protect your valuable data. Here are some things to look for in a data center. These are some of the same considerations for your own data center or a third party data center. Does it have access controls in place? Do they have security guards, gates, and checkpoints? Do they have video surveillance systems? Do they use intrusion detection technology or alarm systems? Do they employ the use of multi-factor authentication? For example, they employ the use of key cards and some sort of biometric scanning, such as a fingerprint reader. Do they have a need-based access policy? Do they revoke access when needs change? Do they use ID badges for employees, and are they photo ID badges? Do they do background checks on their employees? Is there another layer of security around your servers? For example, if you have an entire rack, does that rack lock? Or if you have a group of racks, are they separated from the rest of the data center, in a locked cage? Is the data center in a nondescript facility? Here's a picture of an actual data center. It's a fairly plain building. You can't really tell what's inside it. Here's another picture of an actual data center. In this one, you can see some security cameras on the building if you look towards the top right of this image. Again, this is a rather nondescript building. If the data center looks more like this, then maybe you should consider looking for another facility. Obviously, this is fake, but you get the point. Let's talk about the cloud. The important thing to realize about the cloud is that even though many things are virtualized, such as virtual machines, virtual CPUs, virtual memory, and virtual storage, it all runs on real actual hardware. As an end user of cloud technologies, you don't need to know about the underlying hardware. However, from a security perspective, you need to know about real world physical security in addition to securing the virtual components. If you are hosting your servers in the cloud or running virtual machines on some other company's hardware, then you need to determine what their physical security policies are, just like you do when you're looking for a data center to house your own servers. Remember, once you strip away all the layers of virtualization, you end up with actual physical hardware that makes cloud computing possible. In addition to physical security, you need to consider that your data resides on their storage platform. For example, what looks like a physical disc to your virtual server could be as simple as a single file on a disc on your cloud provider server. Since the cloud provider owns the physical host and has access to all the storage, then they have access to your disc image and your data. Potentially, they could look at or even alter your disc images. If your cloud provider has a disc encryption service, consider using it. If you don't, then do the encryption yourself inside the virtual machine or accept the risk. We'll be talking about data encryption in more detail in just a couple of minutes, but for now, just know that it's a potential attack surface.

About the Author