The previous video focused on system security, that is, maintaining the integrity of locally-running processes and resources. This lecture is about protecting your system from network-based threats. With that in mind, you might wonder why we're going to start by talking about passwords and the files used to store them, when it would seem to be something we should already have discussed. I believe the LPI placed password files together with network security because securing key system data, like passwords, is an important part of maintaining control over network access.

How? Because, if a hacker manages to break into your system for various reasons, he's more likely to do it as a regular non-admin user. But if he can easily access a file containing user passwords, even if they're encrypted, then he's a step closer to getting the keys to the castle. And it's for that reason that many Linux distributions stopped keeping encrypted passwords in the /etc/passwd file. Let's take a look. Notice first of all, that we can view the file without sudo, which is what makes it so vulnerable. Now take look at how the data is arranged. Each field is separated by a colon. The first field is the Username, Steve, in this case. The second field is just an X. Once upon a time, this would've been the encrypted version of Steve's password. But that's now been moved somewhere else, which we'll get to in a minute. While we're here however, we might as well explain some of the other fields.

The User ID and Group ID come next, followed by Steve's Home directory, and finally, his default shell. So, where have all the passwords gone? If you can still log into the system, they've got to be somewhere. The answer is, they are now usually kept in /etc/shadow file. Note that we can't read the file without sudo.

That, obviously, is to protect the contents from non-admin users. But with sudo, we've got full access. Now we can see the encrypted version of Steve's password. With enough time and compute power, it might be possible to decrypt the string, but it's not a trivial matter. And the fact that everything is here in the shadow file protected by admin permissions, makes it just that much more secure. If your system ever becomes vulnerable or unstable and requires emergency care, and you can bet that at some point it certainly will, you can easily shut down access to everyone but the root user by creating an empty file in the /etc directory with the name nologin.

As long as this file exists, users won't be able to login to new sessions. You should be careful with this. If you create the nologin file, then logout yourself, since you're not the root user, even if you're part of the sudo group, Linux won't let you log back in. You may find yourself having to mount your filesystem from a different machine and removing the nologin file manually. Let's review. Encrypted records of user passwords are usually kept in the /etc/shadow file which is restricted to access by admin users. The /etc/passwd file contains only basic user account details, but no passwords. Adding an empty file named login to the /etc/ directory will prevent non-root logins.

Now we can turn our attention to some more obvious network security considerations. When a remote client requests a network connection, your server has to know how to respond. Normally, local requests for some services cause system daemons to start, and once a service is no longer needed, stop. However, it wouldn't be very secure to allow remote requests to directly spawn local daemons. So, a class of daemon manager, or a super-daemon, was created.

Originally called inetd, for internet service daemon. Inetd manages local daemons on behalf of remote clients. By the way, be careful not to confuse the various inet files and directories with the similar sounding init and inittab files and directories that we discussed earlier. Those services control system boot and run levels, and had relatively little to do with security. What's important for us right now is to be aware that inetd can be configured to accept or reject remote requests according to your instructions. On Debian systems, until very recently at least, inet configurations were kept in the /etc/inetd.conf file. Over time, security concerns caused most distributions to replace inetd with more sophisticated super-daemons like xinetd, which would be controlled by the /etc/xinetd.conf file, or by files in the /etc/xinetd.d/ directory. In this case, xinetd.conf contains nothing more than a pointer to the /etc/xinetd.d/ directory where individual service config files are kept.

Let's take a look at an xinetd file, the one called time. The value of the service line is the service name, time, in our case. By default, network access to time is disabled as we can see from the yes value of the disabled line. We can also see both tcp and udp versions. To provide real-time protection, the tcp.d daemon, otherwise known as a TCP Wrapper, can be invoked before a requested service is actually started up. Tcp.d will then check the client host against lists of allowed or denied addresses, and if everything's okay, drop out, allowing the service to start. The files tcp.d reads are both in /etc, hosts.deny and hosts.allow.

Hosts.deny is a blacklist, meaning any host addresses listed will be blocked from making requests, while requests from everywhere else will be allowed.

Hosts.allow, on the other hand, is a whitelist, so that only those domains actually listed will be allowed access, and all others will be denied. If there are entries in both files, matches from hosts.allow will be acted on, and anything from hosts.deny will be ignored. To review, the super-daemon controls remote client requests according to configurations found in the /etc/inetd.conf or /etc/xinetd.conf, or files in the /etc/xinetd.d/ directory. The tcp.d daemon will check the origins of remote requests against the entries in the hosts.allow whitelist file and the hosts.deny blacklist file. As we've briefly seen in previous videos, a lot of the access control for resources living in Amazon's AWS cloud is handled by security groups and access control lists, or ACLs.

You can therefore open up a port, like https port 443, for traffic from a specific range of sources, either using the ACL at the virtual private cloud level, or within the security group at the resource level. You can also precisely manage access by particular services using AWS' Identity and Access Management service, IAM. In this example, network access to a DynamoDB database table is restricted to only IAM users whose name matches the name of the table. By the way, Cloud Academy has a number of courses that deal with a AWS security in much greater detail.