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

Linux Firewall Fundamentals

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

A firewall is designed to block unauthorized network access while allowing authorized network access. The built-in Linux firewall is comprised of two parts. The first part is a Netfilter, which is a framework within the Linux kernel that provides a series of hooks in various points in a protocol stack. The second part is a packet selection system called IPTables, that gives you the ability to perform actions on network packets. The IPTables command line utility is used to interact with IPTables and Netfilter. Ultimately, you can use this command to create a set of firewall rules that allow you to control the network traffic destined to or originating from your Linux system. Here is the basic structure. Tables are comprised of chains and chains are comprised of rules. Each chain can contain multiple rules and each table can contain multiple chains, and there are multiple tables. As a matter of fact, there are five standard IPTables. These are the Filter table, the NAT table, the Mangle table, the Raw table and the Security table. The Filter table is the most commonly used of all the tables. This is the table where you can block incoming connections or deny outgoing connections. The NAT table is used for network address translation. NAT remaps one IP address space into another. NAT can be used to allow a single IP address to be shared. For example, if you were running virtual machines on a private network inside your Linux system, you would use NAT to control traffic to those virtual machines. The Mangle table is used to alter packets. You can do things like change the TTL which stands for Time To Live on a packet for example. The Raw table is rarely used, its primary purpose is to allow exemptions from connection tracking. The security table is used for mandatory access control networking rules. Mandatory access control is implemented by Linux security module, such as SE Linux. Mandatory access control is implemented by Linux security modules, such as SE Linux. Those are the tables you have to work with. Each one has a specific purpose and you can't create your own tables. Just like there are default tables, there are default chains and each table comes with a set of these predefined or built in chains. The five chains are INPUT, OUTPUT, FORWARD, PREROUTING and POSTROUTING. You might've had noticed that all these chains are capitalized. Just like most things in Linux, chains are case sensitive. So if you want to refer to the input chain, you'll have to do so using all uppercase letters. On your is a depiction of the built-in chains used by each table. The Filter table has INPUT, FORWARD and OUTPUT chains. The NAT table uses IPUT, OUTPUT, PREROUTING and POSTROUTING. Mangle uses all the five default chain types. The Raw table consists of the OUTPUT and PREROUTING chains and the Security table uses INPUT, OUTPUT and FORWARD chain. Here's another way to represent that same information. This diagram shows that the Filter table is made up of the INPUT, FORWARD and OUTPUT chains. Remember that each chain can have its own set of rules, but unlike tables and chains, there are no default rules. Unlike tables, you can create your own chains. This way you can create your own collection of rules in a centralized location. For example, you could have a chain called LOGNDROP that logs when a packet is going to get dropped and then actually drops that packet. This way, you can keep an audit trail, which can be used in further securing your systems or used in troubleshooting. Here's a diagram that shows the path a packet will take assuming there are no rules that stop the packet along the way. If a packet is inbound to the Linux system, it will go through any PREROUTING chains, then INPUT chains, and finally the packet will arrive to the local system. If an inbound packet is destined to another host, it will go through the PREROUTING, FORWARD and POSTROUTING chains before the packet leaves the system. For a packet that originates from the system, it will go through the OUTPUT and POSTROUTING chains before it leaves the system. If we combine this chain traversal order with the tables in which they're used, you'll get a complete picture of the path, the packet takes through the system. Since you probably won't be using the Raw, Mangle and Security tables, I've included this simplified diagram of that path. Any packet that comes into the system will start at the top of the diagram. It comes through the network into the NAT table and through the PREROUTING chain. From there, the packet is either destined to the local system or it's going to be forwarded. If it's destined for the local system, then the packet goes through the input chain in the Filter table. If a packet originates from the local system, then it will traverse the NAT output chain, followed by the Filter output chain. From there, it goes through the NAT POSTROUTING chain and finally leaves the system. Now that you know the path of packet takes, you can start creating rules and placing those rules in the appropriate tables and chains. Rules are comprised of a match, section and a target. You can match a packet in several different ways. You can match by protocol, source IP address or network, destination IP or network source port, destination port, or the interface that a packet comes in on or goes out on. You can make simple rules by using just one of these matching criteria, or you can create more complex rules that combine the criteria. For example, you could match TCP packets that originate from the 1.2.3.4 IP address and that are destined for port 80. If they don't match all three criteria, then the packet is not considered a match, it must be a perfect match. If the protocol was not TCP/IP or the IP was not 1.2.3.4, or the destination port was not 80, then the match fails and the packet is examined by the next rule in the chain. The target section of a rule determines what happens to a packet that is matched. The target can either be a name of a chain or a built-in target. This is not a complete list of built in targets, but they are the ones that you'll most often use and encounter. The ACCEPT target is used to accept a packet and to stop processing rules in the chain. The DROP target silently ignores the packet and stops processing the rules in the chain. The REJECT target is like the drop target, except that it notifies the sender that the packet was not accepted. Use the LOG target to log the packet using the system logger and continue processing rules in the chain. Using the RETURN target causes the current packet to stop traveling through the current chain. If this happens in a sub chain, the packet will return to the calling chain. If the packet is in the main chain, like an INPUT chain, the default policy of the chain will be applied to that packet. Also, if a packet reaches the end of a chain whether or not a return target was encountered, the default chain policy determines the target.

About the Author