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

Securing SSHD - 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

Whenever possible, use the SSH2 version of the SSH protocol. It contains several improvements over SSHv1. Some of those improvements include a different set of improved and stronger algorithms for encryption and authentication. Use the protocol configuration directive in the SSHD config file followed by two to force version two of the SSH protocol. By default, SSH will listen on all addresses on the system. If you want to control what IP address SSHD binds to, use the listen address directive and specify the IP to listen on. If you want to listen on multiple IP addresses, use multiple listen address lines. You can use this in situations where you have a system that is connected to both a public and a private network. This way you can force SSH to only listen on the private network and reduce your attack surface. By default, SSH runs on port 22. If you want to change the default port, supply the new port number to the port directive in the sshd_config file. Changing the port that SSH listens on can reduce the number of unwanted connections. However, if an attacker is specifically targeting your system, it would be a rather simple task for them to do a complete port scan of your system and to find the port that SSH is now running on. If you do change the SSH port and you're using SELinux, you need to update the SELinux policy to include the new port. Run semanage port -a -t ssh_port_t -p tcp followed by the new port number. To check that the port was added, run semanage port -l and you can grep for ssh Avoid unnecessary information leakage. You can use the banner directive to display the contents of a file to a remote user before they are allowed to authenticate. Historically, that file has been /etc/issue.net. If you're using such a banner, try not to disclose any more information than you have to. I've seen some people put the distribution name and version, the kernel version and other random information that can be used by an attacker. If you have to use a banner per company policy, follow the policy, but keep in mind that anyone who attempts the connection will see that information. To disable the banner, set banner to none. It's important to note that any changes you make to the sshd_config file will not take effect until the SSHD process rereads the configuration. On a system that is using systemd, you would run systemctl reload sshd to force the configuration to be reloaded. In this video, you learned some ways to secure your SSH connection. This was by no means an exhaustive treatment, and you may have special considerations for your specific environment. Be sure to refer to the ssh, sshd and sshd_config man pages for more information.

About the Author