I want to take just a few minutes here to talk about some security guidelines. Some of these are Linux-specific and some are more general in nature. These ideas can act as your guiding principles when making security decisions. If you encounter a specific situation that isn't covered in this course, you can use these ideas to guide you. I won't be getting into the details of how to implement each one of these ideas on a Linux system in this lesson, but we'll be covering these later in the course. First off, minimize the amount of software installed on the system. If you don't intend to use a piece of software, then don't install it. If you don't intend to use a service, stop that service and uninstalling it. If you no longer need a piece of software, uninstall it. Any software or services installed on your system make the attack surface larger. Anything on the system could potentially be used as part of an attack on that system. If possible, run each network service on a separate system to minimize the risk of one compromised service being used to compromise another service. For example, if you're running a file sharing service and a web server on the same system, and the web server was exploited, the attacker could potentially gain access to the data used by the file sharing service. If the file sharing service was running on a different system, it would not be vulnerable to attacks on the web server. encrypt all data transmitted over the network. This can prevent eavesdropping and man-in-the middle attacks. Always encrypt authentication information, such as passwords. Here are some examples of insecure protocols that you can replace with secure protocols. 

For example, instead of using FTP, use SFTP. Instead of Telnet, use SSH. Instead of SNMP versions one and two, use SNMP version three or higher. Instead of HTTP, use HTTPS. This is not an exhaustive list by any means. Just keep in mind that if you're transmitting data over network, be sure that the data is encrypted. Do not use shared accounts if at all possible. Each person should have their own individual account, and each application should have its own individual account. If multiple people have access to one account, then you may not be able to determine which person was responsible for which actions. Using shared accounts make security auditing difficult, if not impossible. Also, people don't treat shared accounts like they do their own. They often are more lax about security with a shared account because they know that they probably can not be individually held accountable for actions associated with that account. Do not log directly into the root account. This goes for any shared or application account as well. Do not let users log in directly as the web server user, for example. At least require them to log into their individual accounts first and then switch to the route or other shared account user. When someone switches to another account, a log entry is created, and that can help with auditing. It's a best practice to restrict access to shared accounts with sudo. sudo allows a user to temporarily escalate or change their privileges to another account, such as the root account. 

Instead of switching to the root account, simply run the commands with sudo. This creates a log of who ran the command, the time the command was run, exactly what the command was, and what user the command was executed as. We'll be covering sudo and how to configure it later in the course. Maintain accounts by creating and enforcing strong password policies and deleting, or at least locking unused accounts. It's important to have a process for deleting or disabling user accounts when a person no longer requires access to a system. This process should be followed when someone changes a role in your organization and no longer needs access to a system or leaves the organization altogether. For public-facing systems or systems that warrant a high level of security, use multifactor authentication if possible. Multifactor authentication requires at least two things in order to gain access to a system. Most often it's something you know, such as a password, combined with something you have or something you are. An example of multi-factor authentication would be, when you connect to a system with a password, it sends a message that includes an additional password or code to the phone associated with your account. If you reply with the appropriate code, then you are granted access. In this example, it takes something you know, your password, and something you have, your phone, in order to authenticate to the system. Another example would be combining a password with a biometric scan. 

In order to access the system, you could be required to provide a password and your fingerprint. Use the principle of least privilege, which means use the minimal amount of privileges required to accomplish a task. This is also known as the principle of least authority. We've already touched on this with a root account. The principle of least privilege in this context means that for normal everyday operations, use your personal account and only escalate to route privileges when you need to perform a system administration function. Unless absolutely necessary, do not run a service with root privileges. If a service can operate under an application account, then use an application account for that service. There is no need to run a database server with root privileges, for example. Only give users access to what they need in order to do their job, and no more. If a user does not need root privileges to do their job, then they should not have the ability to access the root account. If a user does not need access to some data stored on the system, use file permissions to block their access to that data. Said another way, use the most restrictive permissions possible that allow people and services to perform their jobs. Monitor system activity. Routinely review system and application logs. 

If possible, send logs to a dedicated log server in real time. Even if an attacker deletes logs and covers his tracks on the local system, a copy of the logs will reside on your logging system, allowing you to detect and investigate the attack. Use a firewall. The Linux kernel has a built-in packet filtering framework called Netfilters. The IP tables tool is used to communicate with net filters in the kernel, which implements packet filtering. You can use iptables directly from the command line to create firewall rules or you can use other utilities that use iptables and Netfilters in the background for you. Going back to the principle of least privilege or a principle of least authority, only allow network connections from sources that require it. For example, if you have a system on the public internet that requires SSH access from within your company, then only allow SSH traffic from your company's network and drop all other connections. Even if your system is behind your company's firewall, this same concept applies. Since Linux makes it easy to create local firewalls, take advantage of this extra layer of security. Encrypt sensitive data. We've already talked about encrypting data when it's transmitted over a network. This provides a layer of protection where the data is in transit, but what about when it's at rest? For example, what about when it's stored on a disc? If you want the same level of security for your data when it's at rest, encrypt it. If your data is un-encrypted and an attacker were to get direct access to that data, they could easily read or alter that data.