In this course, you'll learn some techniques and strategies to secure network services. You'll also learn how the local firewall works in Linux and how to configure it. We'll talk about information leakage and ways to prevent it. Next, you'll learn how to test for open ports and perform port scans. You'll also learn about xinetd, what it does, and how to secure it. We'll also cover how to secure SSH. This course includes some guided demonstrations so that you can see the concepts being used in real-world environments.
- Learn how to secure SSH
- Understand the fundamentals of Linux firewall security, including configuring a firewall from the command line and setting up firewall rules
- Learn how to use TCP wrappers to secure your Linux system
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.
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 220.127.116.11 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 18.104.22.168, 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.
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.