Linux Security and Hardening
General Linux Security
Physical Security for Linux
Network Security in Linux
Additional Security Resources
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.
- 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
I'm logged into a Linux box here and I have a web server running on this system. Let's create a simple set of rules that allows anyone to connect to the web service and only people on my private network to connect via SSH, and we'll go ahead and block all the other packets. First, let's just start out by looking at what's in the filter table. So I can do iptables -L to list the rules. And as you can see, there are no rules defined. Let's go ahead and create that rule that allows anyone to connect to the web server on port 80. Use the iptables command. I'm going to use A, for append, you can also use I for insert, since there's no rules at this point, it really doesn't matter. I'm going to use A for append, I'm going to put this rule in the input chain. We're gonna look for TCP connections that are destined for port 80, and we aren't going to do any other type of processing. We're gonna go ahead and jump to, or go to the Accept target, we're just gonna accept these packets right away. So now let's look at what we've done here, and you can see that the rule has been added to the input chain, accept TCP packets from anywhere that are destined to any address on the HTTP port. So as you can see that the port 80 was translated into its name of HTTP. If we wanna just use numbers or see numbers, we'll use the -n option. So I'll run iptables -n, -L. And then now you can see that the source and destination are listed in a numeric notation. And then also the port of 80 is listed versus the name, which is HTTP. Okay, let's go ahead and accept SSH connections from the 10.0.0.0 network. So we'll do an append to the input table. Again, we're concerned with TCP protocol, the destination port would be 22. The source is going to be 10.0.0.0/24. /24 network is also the same as 255.255.255.0, and that's the subnet mask for a /24. So you can use either type of notation here. I'm just gonna stick with a /24. And again, I don't wanna do any more processing on these packets, I wanna accept them as well. So we'll use a -j ACCEPT to go to the Accept target. And we'll look at our rules again. So rule number one is accept packets that are bound to port 80, and rule number two is accept packets if they originate on the 10.0.0.0/24 network that are destined to port 22 which is the SSH port. Let's go ahead and drop every packet that doesn't match one of those two rules. We'll do this with the iptables command, - A to append in the input chain. And I won't specify any match criteria because we wanna match all the packets and we'll send that to the Drop target. Since we didn't specify any match rules, like the protocol, or ports, or anything like that, any packet will match that rule. Let's go ahead and test this. In this tab, I have a system that's on the 10.0.0.0/24 network. And if I attempt a connection to port 80, it should succeed. So I'll do nc for netcat, -v 10.0.0.8 which is the IP address of our server system and port 80. And then you can see that the connection succeeded there so that nc command, it's also known as netcat, and it can be used for a variety of things. Here it's just attempting to connect to the IP address of the port specified on the command line. Now let's do the same thing, but to the SSH port. Okay, again, the connection succeeded. So let's go back to our original server system and remove the rule that allows port 80 connections. I'm going to do a listing here that includes inline numbers, so I can delete rules by line numbers. So I'll use iptables -D for delete. I wanna delete a rule out of the input table. And the rule number I want to delete is one. Now you can see that that rule was deleted and we are left with the other two rules in our chain. So let's go back to our system and test this. The -w option of the netcat command lets you specify a timeout. Here I used two seconds because I know it was going to time out and I didn't wanna wait the entire time. So our connection timed out because the firewall simply drops the packets. Instead of dropping packets, let's see what happens if we reject those packets. Let's go back to our service system. All right, I'm going to delete the second rule out of the input table. And then I'm going to append a new rule that rejects packets. All right, there is our new rule. Let's go back to our client's system and test this time. So immediately we get a "Connection Refused" message. So if you want someone to know that they're being blocked by the firewall, use Reject as the target. If you want to silently drop their packets and ignore them, use the Drop target. Let's get back on the server here, clear our rules, and start over to an iptables -F to flush our rules, and we run -L, you can see all those rules are gone. Let's do -A INPUT, protocol TCP, destination port 22. If it comes in on the 10.0.0.0/24 network, let's go ahead and accept those packets. Let's create a new table, a custom name table here. We'll call this new table "LOGNDROP". Let's go ahead and add some rules to this table. We'll use the limit module and we'll limit packets to, let's say, five a minute and we'll log those packets. And there's an additional option you can use here, called --log-prefix. And this is what's gonna show up in our system log and I'll just use iptables BLOCK, and a space at the end there. Now, after we log the packet, we're gonna go ahead and drop the packet. And let's go ahead and append the destination, or let's jump to this new chain that we've created from the input chain. Okay, let me look at the rules here. So the packet will come in and traverse the filter table, go through the input chain. And if it's destined to port 22 and originates from 10.0.0. something, then it will be accepted. In all other cases, the packet will be made to traverse the log and drop chain. This chain has two rules. The first rule is a logging rule. Here we've used rate limiting, so we don't fill up our disc with blocked messages from IP tables. Let's go ahead and send some packets over here to block. Let's also tail the messages file. So, var/log/syslog here. I'll just send packets here, like we've done just a second ago. So it timed out, so that means our packet got dropped. Let's go over here. And then now you can see that we have some log messages. Here is the log prefix that we specified. This packet came in eth0, and this is the Mac address. This was the source address, 10.0.0.6. The destination was the IP address of this system which was 10.0.0.8. And there's some other information in here. Here's the source port from the source machine, the destination port, which was port 80 for the web server. And again, this got blocked, and if you log every single message that blocks, again, you'll fill up your desk. So that's why we're using rate limiting in this instance. Okay, I'll go ahead and quit out of that. So if you don't wanna lose your changes after a reboot, remember to save the running configuration. Now this will vary from distro to distro but for this Ubuntu system I can run netfilter-persistent, followed by the word "save".