This chapter is not meant to be a complete guide to cloud security, but merely to point you in the right direction. Security is more of a process and way of thinking than it is a series of steps, so this chapter will focus on how you need to think to protect your servers’ integrity and your data’s integrity.
13.1 The Basic Considerations
How can I mitigate the risks of being connected to the Internet?
What is the minimum set of services I can run on my system and still have it function?
How can I limit access to the server for services that are not needed by everyone?
Is all of my software patched with the latest security patches?
What are ways that someone could abuse the services that are deployed on the server, and how can I mitigate that?
The key to security is to identify what the server is used for and then to remove anything that does not directly contribute to that function in order to prevent unwanted consequences. Every service that you have running is a potential security hole—it is something that someone may one day find out how to exploit. Therefore, you don’t want exposure on points that do not contribute directly to function.
13.2 Examining Your Current Server
Every line that says LISTEN is a service that is listening for an IP connection. If the “Local Address” is 127.0.0.1, ::1 (for IPv6 addresses), or the node’s private IP address, that means that the service is protected—only applications on the machine itself can see the service (on on the private network, in the case of the private IP address). However, if the local address is *, 0.0.0.0, or :: (for IPv6 addresses), that means that it is available for anyone to connect to.
The items that are listed under “services” and “ports” are what the firewall is letting through. The services that you should allow are dhcpv6-client (used by the cloud for configuring networking), ssh (so you can log in), http (for non-SSL HTTP connections), and https (for SSL-enabled HTTP connections).
Even though the firewall will prevent connections to anything not listed, if you have any service running that is listening for connections that you don’t specifically need running, you should disable the service. Additionally, you should periodically check your firewall to make sure it is configured correctly.
Additionally , you should take inventory of all of the running processes, even if they aren’t listening for connections. The best way to do this on Linux is using the command ps -afxww. Note that everyone has their own favorite way of calling ps, but this is mine.
I can’t give you a list of everything that should/shouldn’t be running. However, it is best to learn what each piece does and turn off the pieces that you don’t need. The fewer services running, the better.
You can also list out all of the packages that you have installed using the command rpm -qa. As you become more experienced, you should be able to uninstall programs that you don’t need.
13.3 The Root User
The most dangerous part of a Linux installation is the root user. It is dangerous for two reasons. First, it is the superuser, so it has power over everything else. Second, everyone knows its username, which makes it easier for automatic hacking tools to breach.
- 1.
The root password should be secure (i.e., difficult even for a computer to guess). In fact, the passwords of every user should be secure.
- 2.
The server should not permit remote direct root logins. To prevent direct root logins via ssh, modify /etc/ssh/sshd_config. If there is already a line that says PermitRootLogin, change the value from yes to no. If there is not a line there, add a line that says PermitRootLogin no. After saving the file, do systemctl restart sshd and the change will take effect. After this, you will need to log in as an ordinary user and use the su command to switch user to root.
- 3.
Services should rarely run as the root user unless there is an overwhelming reason to do so. If a service must do something as root, the part of the service which directly talks to remote computers should not be root.
- 4.
Users should not spend much time as the root user. In this book, most of our time has been spent as the root user. Instead, users should log in under their own accounts and then switch to the root user using su or sudo for temporary root privileges.
- 5.
You should install some sort of service denial program such as fail2ban, which disables logins from particular IP addresses after a certain number of failed attempts .
By preventing people from becoming the root user, running services that don’t run as the root user, and by protecting the root account from outside access, the ability of an intruder to do damage is greatly diminished.
Now, the fred user can run any command as the root user by just prepending sudo to the beginning of the command. For instance, if fred wanted to display the file /etc/sudoers (the configure file for the sudo command), Linux would not normally let him. If he did cat /etc/sudoers , the operating system would give him an error. But, if fred is in the wheel group, and he issued the command sudo cat /etc/sudoers, the operating system would ask him for his password and, after reauthenticating him, would run the command for him.
13.4 Installing a Web Application Firewall
A web application firewall is a piece of software that sits between your web application and the Internet. The purpose of a web application firewall is to check incoming traffic for patterns that are known to be consistent with malicious intent, and then block those requests. A web application firewall does not make up for bad programming in a web application, but it will often prevent automated hacking tools from finding holes.
However, with our test site, the web application firewall will likely block requests that use the IP address in the URL, as that is a characteristic of many hack attempts! In fact, I have found that for many production systems I have to disable several individual rules to get the web application firewall to work with my application. This can be painful, but on the whole it is worthwhile to do.
The web application firewall will log which rule denied the request in the log file /var/log/httpd/error_log. Therefore, you can find the rule ID number in the log and then disable it in the configuration. Just add the line SecRuleRemoveById IDNUM to the file /etc/httpd/conf.d/mod_security.conf to disable unwanted rules.
13.5 Checking for Rootkits
A rootkit is a piece of software installed by someone who has broken into your server that makes it easier to control your server for nefarious deeds. If your server is secure, it is unlikely that someone will break in, but nonetheless it is good to periodically check.
To run the program, just do rkhunter --check. Be aware that it can generate false warnings and false positives, so be sure to check the logs to see what, specifically, it found when it was looking at an issue .
13.6 Other Security Software
There are a host of other security packages that you can install and use. The important thing is to know what measures are available, and to see whether or not they are cost-effective for your needs.
logwatch: This tool analyzes log files and e-mails administrators when suspicious activity is recorded.
fail2ban: This program looks for repeated login failures and other suspicious behaviors and will block IP addresses that look like they are attempting to break in.
SELinux: Security-Enhanced Linux is an operating mode where the Linux kernel gives very fine-grained access control to programs, limiting what each program and user can do significantly more than normal. SELinux can provide a lot of risk mitigation, but it is fairly complex to set up, and it is easy to accidentally block your own applications from doing what they need to do. We have disabled SELinux in this book because of the amount of configuration issues it entails.
FirewallD : This is the standard firewall administration application used in this book.
AuditD: This program looks for and logs suspicious activity by application programs.
Remote Syslog: This is not a program, but the system logger can be configured to log to a remote server, so that intruders cannot cover their tracks by modifying log files.
13.7 Application Security
- 1.
Code defensively.
- 2.
Verify every piece of data from the user.
- 3.
Properly escape everything sent to the user.
- 4.
Always double-check the privilege of a user before performing an operation or showing data. Make sure that simply knowing a URL or a parameter doesn’t automatically give a user undue power.
- 5.
Be very careful about anything that is sent to an external command or program. Double-check that you have properly escaped or filtered everything.
- 6.
Always imagine what would happen for every piece of data and every request if someone were maliciously manipulating it.
- 7.
Always try to code using “best practices” (e.g., https://phptherightway.com/). Using best practices when coding can save you from security problems that other people introduce, including those that you accidentally introduce yourself later down the line as your application grows and turns what is currently safe code into unsafe code due to changes elsewhere in the codebase.
Also be sure to check the list of common vulnerabilities at www.owasp.org
- 1.
Securing PHP Apps by Ben Edmunds: This is a short and to-the-point guide to secure practices in PHP.
- 2.
Pro PHP Security by Chris Snyder, Thomas Myer, and Michael Southwell: This is a more comprehensive guide to security and security principles with a PHP focus. It is an older book, but the core security principles have not changed.
- 3.
Mastering Linux Security and Hardening by Donald Tevault: Writing secure PHP code won’t help you if your server isn’t configured properly.
- 4.
Practical Information Security Management by Tony Campbell: This book will help you understand at a higher level what is being secured, what is being protected, how to manage tradeoffs, and what the ultimate goals of security are.
The most important thing, however, is to always be thinking about how your application could be abused and always be learning new ways to proactively guard against those things.