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

Network Security - Part II

Start course
3h 21m

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

Avoid information leakage wherever possible. Some network services will report their exact name and version number. An attacker could use this information to look for security holes for that specific application and version. The common example of this is when a web server reports it's name, version and sometimes the operating system that it's running on in the server response field of an HTTP header. Another place information can be leaked is in the message of the day file /etc/motd which gets displayed when the user logs onto a system. Another place is the etc issue file, which is displayed before a login prompt on the Linux console. Although it's not commonly used today, there may be similar information stored in /etc/issue.net. Historically, this was used for Telnet sessions although you may find some SSH configurations that reference it. We've talked about services and only running the services that you intend to use. So how do you tell what services are currently running on your system and how do you disable them if you want to? If you're using system D, run the systemctl command and it will give you a list of the running services. Not everything listed as a network service but it gives you an idea of what's running on your system. Here's just a snippet of some systemctl output. It shows that a web server is running as well as an SSH server. If you want to stop a system decontrolled service, run systemctl stop followed by the name of the service. To disable a service run systemctl disable followed by the name of the service. Stopping a service stops it for now but if it's enabled, then it will start again when the system reboots. To prevent that from happening, disable the service. One way to find out which services are running on your system is to use the netstat command. You can see that I've supplied the nutlp options and displays the output in numeric format. No IP addresses will be translated into host names. U tells netstat to include the UDP protocol. Likewise T tells netstat to include TCP. The L option tells netstat to display only listening sockets. Finally, the P option displays the PID and name of the process that is doing the listening. You'll need to run this command with root privileges. The sample output on your screen shows that the SSHD program is listening on port 22 on all IP addresses. That's what represents. However, the master program is listening on the IP address on port 25. That process is part of the postfix mail server and it's listening on the SMTP port, which is 25. This service will only handle mail for the local system since it's listening on the loop back IP of This is a good practice and it's something I encourage you to do. If a network service is only going to be used by the local host, bind it to the loop back address so the service is not available over the outside network. Also, this output shows that the DHC client process is listening on UDP port 68. Another way to tell if something is listening on your system is to port scan it. One popular tool for doing that is nmap. If you are testing your system from the inside itself, you can port scan the local host or you can port scan your host from the outside. In the simplest form nmap is called with an IP address or host name as an argument. It will then scan for open ports and report back what it finds. Here's a sample run of nmap against the loop back address. It shows that ports 22, 25 and 80 are open. Those are ports for SSH, SMTP and HTTP. Here is some output from the nmap command run against the public IP address of the server. Notice that port 25 is not listed. That's because the mail service is only listening on the loop back address and not on the public address. Yet another way to look for services on your system is to use the lsof command. LSOF stands for list open files. To do this, use the lsof command with a -i option. Remember practically everything on a Linux system is represented as a file so we can list the network file, so to speak. So run lsof -i and it will display all the listening and established network connections. If you want to see if a specific port is reachable, you can use the Telnet command, supply the host name or IP address you want to connect to and then the port number. Historically Telnet was used to log into systems, but you can still use this tool to connect to a port. Once connected, you can even send data over that port by typing in text. You can test some plain text protocols like HTTP or SMTP using this method. You can also use the nc or netcat command to attempt a connection to an open port. Run nc -v followed by the host name or IP address to connect to and then what port to connect to. The -v option is for verbose and using it will cause netcat to clearly print out whether the connection succeeded or failed. Although it's less and less common, you may encounter a service that is controlled by xinetd. If you see an xinetd process listing on a port when a connection to that port is made, xinetd will actually start the process that is responsible for that port and hand the connection over to that process. To see a list xinetd supported services, look in the /etc/xinetd.d'directory. Each service will have its own configuration file. To disable one of those services, ensure that there is a disabled equals yes line in the file. To disable xinetd itself, stop the process and make sure it doesn't start on boot. For a system decontrolled system run systemctl stop xinetd and then run systemctl disable xinetd.

About the Author