Encryption and software updates
Launching your EC2 instance is just the first step to becoming an AWS professional: securing your cloud resources is something you just can't ignore. In this course the experienced Linux System Administrator David Clinton will share some common best practices to enhance your infrastructure security.
You'll learn how to manage access to your instances with IAM and Multi Factor Authentication, how to encrypt your storage, how to keep your Linux instance updated with security patches, how to monitor your system and your network to ensure that nobody unauthorized is using your resources, and finally, the basic principles of penetration testing and how to use nmap to ensure that your security group is properly configured.
Who should take this course
This course is aimed even at beginners with little or no experience with cloud security. Some basic knowledge about Linux system administration, TCP/IP, and security topics are recommended.
Hi and welcome to cloudacademy.com's video series on cloud security. We've discussed controlling user access through IM or password policies, but it's also important to ensure there's ongoing monitoring of system processes. We're going to explore some specific methods for doing such monitoring. Any system activity on a Linux based operating system leaves some record, some evidence of what took place, when it took place, which user might have been involved. One way to get a quick view of the most active processes alive right now on the system is through top. Top will display those processes which were using the highest percentage of CPU of your processing resources and have the highest percentage of memory, system memory. In this particular case, the two most active programs seem to be Kazam and PulseAudio which happen to be the software tools that I use to record this video. Hit q to stop Top from refreshing and let's run ps. Ps will list with certain arguments all the processes currently alive on the system. We can scroll up and you see there is quite a number and it's really too much to absorb in one screen or even in one sitting, so let's try to narrow it down. Let's type ps aux.
You can produce this vertical bar by typing shift and the backslash key at the same time. Then grep which will select from the total output of the ps command only a string that you specify. So let's specify Kazam and we can now see more details associated with the Kazam process.
Now, of course, were not worried about Kazam. We know why it's running. We know who's running it. It's a perfectly legitimate process. The usefulness of top and the monitoring system processes is when you notice a process that doesn't seem to belong. Then you can use ps and and grep to focus in more on the system itself. Who's it's owner? In other words, who is the user who initiated this process? Is it being run under sudo or not? When was it initiated? How long has it been running? Where is it's base? You could, using these tools, uncover some software that doesn't belong that was maliciously installed on your system and has been running under the surface in a way that you weren't meant to discover.
It's also important to keep track of system logs. Most of the system logs on a Linux distribution are stored in the directory var/log. Type ls to list all the files in this directory and there are quite a few. The items in this directory are displayed using three different colors. Those that are white are simple text files. Those that are red are compressed files. And those that are blue are directories in which more log files are found that are associated with a specific program or process.
The white files, let's say on the left, halfway down the left column is auth.log. This keeps track of all changes or attempted changes in user permissions.
That is a user might want to temporarily make himself an administrator using sudo perhaps. The attempt to make himself administrator will be recorded in auth.log along with the time it happened at what was going on at the time. Let's take a look at auth.log. It's a large file so lets type less, which is a file viewer, auth.log. And we get one screen at a time, the data included in auth.log. Typing q will escape that file. Why would we want to look at auth.log while were monitoring system events? Because it might reveal to us there's a user who perhaps shouldn't exist who's been playing around on the system and changing his permission status at a time you wouldn't anticipate. Taking a look through auth.log or writing a script that will monitor auth.log for unusual events is an excellent way to keep track of system events. It's also a good idea to keep track of who's on now. Which users are on your system now and which have been on the system on the last day or week. An easy way to do that is simply to type in last, which will record the last logins and the duration of each login recorded on the system that have occurred on this system over the past month or within the past 30 days, at any rate.
So, in our system if we scroll up in just a little bit, you will see that I am logged in. I am actually logged in three different times. I'm currently logged in three different times through the main login to the GUI and also to the two terminal shells. We also see when the system was rebooted and if there were other users who were present on this system, we'd see them. It's a great way to visually track the users that should be on the system and users that are on the system who have no business being here.
Finally, AWS itself provides a number of logs that track user activity and important system changes. It's called CloudTrail. Let's a take a look at what's there. This is the screen you will access to, as it says at the button, get started in saving data to these log files and then accessing the files or having the files periodically sent to you for your monitoring. If your system is open to API calls, it's a good idea to keep track of any access to your system by way of API's and the AWS CloudTrail system seems to be a great way to do that.
David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.
Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.
Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.
His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.