Apache Web Server Hardening
In this course, we teach about Apache web server hardening. We cover what web server hardening is and why it plays a crucial part in the process of running a web server. We go over several configurations we can perform to help secure our Apache web server as much as possible. In addition, we talk about the different kinds of vulnerabilities Apache is susceptible to. Apache HTTP Server is a free open-source web server that runs approximately 45% of today’s websites, which is why learning how to properly secure it is extremely important.
Web servers are in many cases located at the edges of networks, so they are exposed to attacks more frequently than other parts of networks. Web servers are always targeted with requests, both manually and automatically, through scripts. At the beginning of this course, we provide an introduction to web server hardening and teach how to properly install and configure an Apache server. All steps will be performed on Centos7, but we could use the same commands for other Linux operating systems. Keep in mind that the installation process is precisely where the process of server hardening begins. It is very important to conduct a proper installation and configuration in order to protect the server and make it less vulnerable. Remember that default settings are easily bypassed.
Moreover, we also cover how to configure a firewall correctly. We share some basic firewalld concepts and terms like zones, instances, firewalld commands, and blacklists. Subsequently, we present several other topics. For example, we dive into Security-Enhanced Linux (SELinux) and see why it is important to use it with Apache and how it benefits us. SELinux represents mandatory access controls (MAC), allowing fine-grain access controls for resources such as files, devices, networks, and inter-process communication. In many cases, administrators disable SELinux because it causes complications with Apache and there is not enough time to configure everything correctly in the system. This usually results in decreased security.
Some practical skills this course imprats are how to create automated scripts, manage apache directory access, perform log examination, and exploit a server using a well-known vulnerability: ShellShock. Automated scripts enable us to perform server and SELinux checks automatically, which is necessary when handling thousands or even millions of Apache instances at once. We create our own automated script for our needs, but we can always incorporate scripts written by others as well. We also create a capture file using the tcdump tool so we can recognize if there's anything suspicious going on in the system. If something suspicious is detected, we will then inspect the traffic in Wireshark.
Another covered is logs. Logging is essential in any system. We share how to configure our own log level for both general and specific traffic. By the end of this course, you will have a better understanding of the Apache server and be more aware of the dangers it's exposed to. You will also be able to set up and configure various parts of the system more securely, as well as search for potential threats.
This video gives an overview of the intended audience for this course and what kind of knowledge this course provides. The course covers several topics such as Apache configuration, modules, firewalls, logs, directory access, encryption, vulnerability scanning, SELinux, and more.
About the Training Architect
In this video, we introduce the instructor for this course, Ermin Kreponic.
How to Get Help
Here we teach how to get all the help Linux Academy provides in its Community section. The Interact with Students, Slack, and Instructor/Site Support pages enable interaction with the instructor and other users that can help with any problems or questions.
In this video, we go over all the skills recommended in order to follow the course without any larger difficulties. It is recommended to have a basic knowledge in several areas such as working with the Linux command line, bash scripts, firewalls, and some other skills. Prior knowledge of the Apache Web Server also grants an advantage for this course.
Apache Server, Exploits, Attack Vectors, and Automation
Secure Access to the Apache Server
General Configuration and Setup Part 1
In this video, we start with the general configuration and setup for our course. The goal is to have a real application set up and running with a fully functional front end and back end. In the context of that application, we secure and harden the Apache web server’s configuration and the configuration of the system running Apache. Here we install the Apache server and start the Apache web server. After that, we download and run our application.
General Configuration and Setup Part 2
Continuing from where we left off, this video configures a firewall for Apache and SSH. This is necessary because we need to open up certain ports and setup the firewall to work with SSH and Apache. We install and start the firewall, and then install and apply all needed rules. After that, we enable the firewall. The next step is to configure SELinux for index.html as well as our app’s back end. In order to configure the back end, we have to create an app folder and install Python.
General Configuration and Setup Part 3
Here, we continue with the installations of all other requirements and dependencies for our application. We install the pip packet management system, the Flask framework, as well as all other essential tools and utilities like
tcpdump. Port 65535 must also be opened. After that, we configure our Flask service. We also provide an overview of the Apache web server directory structure.
Securing Access to the Apache Web Server OS Part 1
We need to secure access to the OS of the Apache web server. In order to do this, we first need to configure SSH. This includes changing the SSH port, configuring SELinux, reconfiguring the firewall, and applying changes in the
Securing Access to the Apache Web Server OS Part 2
Here we create a public-private key pair so that we can log in with a key rather than a password. This includes generating the key combo and setting some permissions on the client side, as well as configuring the
ssh_config files for the server side.
Apache Exploits, Attack Vectors, and Automation
Vulnerability Scans and Cloud Provider Policies Part 1
In this video, we provide insight on how to do broad general scans and how to detect exploitations when they occur. We talk about the importance of being aware of what is permitted and what is not. Every server has their own policies and rules. SAP, Azure, and Google Cloud all have different policies. Some like Azure and Google Cloud are more open to penetration testing while others are less so. We talk about various vulnerability scanning tools, some for narrow and some for broad services. Some of them are Nessus, Nmap, Metasploit (for creating custom scripts), Netsparker, Acunetix, and others. We also mention some vulnerability-scanning examples.
Vulnerability Scans and Cloud Provider Policies Part 2
In this video, we give a few examples of some broad scans used to search for all known server vulnerabilities that can be present. Nmap is used to to perform these scans. We scan for open ports, running services, service versions, and OS version. We will also demonstrate using Nmap script to scan for a specific vulnerability.
Vulnerability Scans and Cloud Provider Policies Part 3
Here we continue with vulnerability scanning examples. We download the databases and use them to get an exact listing of all the known vulnerabilities. We set up a process to update those databases so we can always stay secure. New vulnerabilities show up all the time, so it is important to set up a vulnerability scanner to update automatically. First, we go to the Nmap script folder and download
vulnscan. Then, we update vulnerability databases by navigating to the
vulscan/utilities/updater folder and give execute permission for
updateFiles.sh, which we use to run the update.
Apache Exploits and Attack Vectors Overview Part 1
Even if our Apache configuration is proper, the server is vulnerable if the OS is vulnerable. So it is important to secure the OS. Generally speaking, it's not really possible to prove something is secure. Instead, we can only prove that it is not. It is important to know how to inspect traffic and see what is going in and going out, assuming we are going to be attacked. In this video, we perform a demo where we are going to exploit the server using a well-known vulnerability: Shellshock. First, we conduct a scan to determine the kernel version of the target operating system. After that, we confirm the result by making some semi-safe assumptions. If the version of the kernel is old, we can assume the server has not been updated. Therefore, it is likely using an older version of BASH that could be vulnerable to Shellshock. After that, an investigation will be performed where we check logs and examine the requests in order to determine how the attack was conducted.
Apache Exploits and Attack Vectors Overview Part 2
Continuing on where we left off in the last video, this video starts with creating a capture file. This can be done in many different ways. We demonstrate this by using the
tcpdump tool. The goal is to watch out for anything out of the ordinary. If something suspicious is spotted, it is automatically separated so it can be analysed further. This process is repeated until we figure out what is going on.
One of the first things to check is if the IP address comes from an internet service provider, from some cloud service provider, or somewhere else. We can also inspect access and error logs for clear records of all the requests made and all the errors that happened. Later on, when we generate the capture file and copy it to our workstation, we open it up with Wireshark and begin the inspection of traffic contained therein.
Capture files can be enormous in size and going through all the records would require a tremendous amount of time, so we won't do that. Instead, we apply filters to display specific requests, namely GET requests, then proceed to examine their structure. We show how the header of a particular GET request contains inappropriate data. Due to the nature of the content of the header, we are able to conclude that this is in fact an active exploitation of the Shellshock vulnerability via the HTTP headers.
Writing Automated Scripts
This video teaches how to write an automated script for performing server checks. If we are dealing with hundreds or even thousands of Apache instances, it is very difficult to perform checks manually without making mistakes. This is why automated scripts are created and used. We can always use scripts that someone else has made or create our own custom scripts by designing our own set of checks. We can customize our scripts to perform any operation necessary. For example, we can write them so that checks are executed remotely or in a way where outputs are saved to a file. Scripts can be written in many different ways, but their essence is the same. The script we create is written in Python. Our script is written in a way where it will perform several checks such as checking the Apache server version, the status of SELinux, the status of the firewall, and perform a vulnerability sweep with Nmap. After that, it prints out the results of the check.
Firewall and SELinux
Firewall Configuration Part 1
Here, we talk about some basic firewalld concepts. The very first thing is how to install a firewall. After the installation, the firewall needs to get started. Of course, from time to time, we need to check its status. Preferably we wouldn’t want to manually start it every time the machine boots, so we need to configure it to start at boot as well. When we get past these basics, we explore the relationship between zones and interfaces. In essence, zones are predefined sets of rules that we assign interfaces to. Then all traffic that comes to a particular interface will have to go through a specific zone and be subject to the rules of that zone.
Firewall Configuration Part 2
In this video, we take a look at some basic firewall commands important for listing out the current configuration of our firewall. These commands allow us to obtain information such as a list of services in the current or a specific zone, a list of supported services, and a list of service files. We also cover the
add service and
remove service commands. Upon adding a service, we must always be sure to reload the firewall. After covering the service commands, we talk about some other useful commands related to rules and ports. We see how we can list all rules, list specific rules, and open, close, or list ports.
Firewall Configuration Part 3
In this video, we configure firewalld to allow access on port 65535 to the back end of our ourApp application. The bottom line is that we need to open port 65535 via firewalld. Now we can go ahead and just open the port, which we will do. But then again, there is a better way at going about this, and that is via a firewall service definition. We create an xml
ourAppBackend.xml which contains the service definition. In it, we include the name of the service, the description of the service, and of course we need to specify both the protocol and the port we wish to use for this service. Once we have created a firewalld service definition, we close the previously-opened port 65535 and enable the newly-defined service.
Firewall Configuration Part 4
At the beginning of this video, we see which commands we can use to obtain a listing of tcp and udp ports, as well as how we can get information about a process listening on a specific port. For our project, we need to find the PID of the service listening on port 65535. A firewall can be used to restrict access to a specific port, and we can configure it to our liking to fit our needs. We can give the firewall a range of IP addresses that can access a port. Alternatively, we can specify a source and destination port where only a specific IP address can establish connections on that port. For our project, we configure our firewall so only we can access our back end.
Firewall Configuration Part 5
Blacklists are awesome. They allow us to ban a large number of IP addresses and networks. We can expand them continuously and create our own custom blacklists, or we can download preconfigured sets of IP addresses from the Internet sorted by country or region. Now an obvious question comes into being. Why wouldn't we just create a rule for every IP address or network we wish to ban? The simple answer is that it's very inefficient. First of all, we would actually write out a rule for every IP address. The second problem is that the firewall would have to inspect each one of those rules, as opposed to quickly going through a hash set.
Firewall Configuration Part 6
In this final video regarding firewalls, we talk about logs. We teach how to configure our own log level both for general traffic and for specific traffic. A log level is basically the degree of logging that determines how much information we want to view. It's important not to forget to restart the firewall after configuration. We create a configuration as such that we deny accessibility to our site. We close the port so that packets are dropped and access is denied. At the end of the video, we say a few more words about firewalld and give some pointers on where to do some further reading about it.
SELinux Configuration Part 1
SELinux is short for Security Enhanced Linux, and that is the topic of this and the next few videos. More precisely, we talk about SELinux with Apache. SELinux represents mandatory access controls (MAC), allowing fine-grain access controls for resources such as files, devices, networks, and inter-process communication.
In this video, we teach what exactly SELinux is, why it should be used and how to configure it. We talk about SELinux modes (enforcing, permissive, and disabled) and show how we can edit the
/etc/selinux/config file which controls the state of SELinux on the system. We also talk about SELinux security context of Apache and where we can find official documentation about SELinux basic concepts. Lastly, we talk about SELinux log files.
SELinux Configuration Part 2
Here we continue our talk about SELinux logs. We mention a few different record types such as AVC, USER_AVC, SELINUX_ERR, and several others. We show how to convert the content of the log files in a way that it is much more readable than otherwise. Then we search through the log file. We try out a few commands such as
ausearch that allows us to search log files for specific strings and specific record types. We analyze SELinux log entries and see what kind of information we can extract from them.
SELinux Configuration Part 3
In this video, we change the SELinux security context. In order to do that, we have to change the
DocumentRoot for Apache. For this to be done, we have to change the path in the configuration file. It's important that SELinux gets taken into consideration in this situation. When the
DocumentRoot is changed, the same SELinux context must be applied to that directory.
SELinux Configuration Part 4
SELinux can have certain properties of a firewall, but it does not act like nor does it function as a firewall. SELinux generally has a predefined set of ports for a particular label for a specific service. If we change the port of that service, and that port doesn’t belong to a predefined set of ports, we have to inform SELinux of this change as well. Otherwise, the service will not work properly if at all.
Apache Modules, User and Group Setup, and Apache Directory Access
In this video, we talk about modules. We go over what they are, what they do, and how we manage them. In general, modules provide an easy way of expanding the functionalities of Apache. They allow for easy scaling of Apache. We show how we can search for modules as well as install, load, and remove them. We also take a look at some modules we can use such as
Mod_Security Part 1
Here we talk about
mod_security, which is basically an intrusion detection system. In truth, it is more like an engine providing the interpretation of the rules we can implement. We can also download other sets of rules and instruct
mod_security to use them. A lot of malicious traffic can be mitigated this way. In this video, we show how to install
mod_security in two different ways. One way is installing
mod_security with a predefined core rule set (CRS). The other is by just downloading the OWASP CRS. After that, we configure everything necessary for it to work, such as copying or renaming the provided example file and informing Apache we'd like to use the
Mod_Security Part 2
Continuing on from last time, here we finish enabling the
mod_security module, check if it is working properly, and check the log files for any problems. We see which are the most relevant file paths, such as the paths to the configuration file, debug log, audit log, and rules. Afterwards, we run some tests and confirm that
mod_security is properly working and blocking traffic that needs to be blocked.
The topic of this video is the
Mod_evasive is generally used to mitigate DOS and DDOS attacks. It's also capable of being used as a detection tool and can report abuse or problems via mail. First, we install
mod_evasive, after which we inform Apache that we will be using this module. We take a look at the contents of the
mod_evasive.conf file and explain some of the definitions there such as
DOSSiteCount, etc. We perform our own
mod_evasive configuration and see how it practically blocks access to a page if too many requests are made.
Apache Directory Access
Directory Access Part 1
Here we will talk about file access, directory access, authentication and similar topics. We will start with the .htaccess file. We will see what it is and when to use it. Htaccess is a distributed configuration per directory file. We create a .htaccess file, then write directives in it. Those directives are applied to that directory. It is important to know that the .htaccess file is used when we need to test something and when we do not have access to the main configuration file. It should not be used in production at all and generally should be used as little as possible. Furthermore, we will see how we can rename an htaccess file, how to allow any directive in .htaccess by using AllowOverride, how to ignore .htaccess directives with AllowOverride as well as provide an Override example.
Directory Access Part 2
In this video, we will rename our .htaccess file back to its original name. Afterwards we will focus on learning how to configure authentication with .htaccess. First, we will set AllowOverride AuthConfig in the main configuration file, and then we will proceed to edit the .htaccess file. When everything is set we will just need to save and restart Apache.
Directory Access Part 3
In this last video regarding directory access, we will first take a look at the ‘Require all granted’ line of our authentication configuration. You will see the difference when the line is enabled and disabled. After that you will be introduced to the tags and see how you can allow, deny and override access of certain directories. After that, the tags will be presented, that are used to apply a set of directives to a file. Lastly, we will go over the tags.
Apache Security Best Practices
Apache Logs Part 1
Systems have many aspects that perform information logging of some kind. Firewalls, SELinux, the system itself, other services running on the system, etc, all create their own types of logs. Apache is no different here. In this video, we are going to talk about Apache logs and its way of logging. Apache has two types of logs - access logs and error logs. Access logs log all requests that do not cause any errors. If there are errors, they get logged in the error log. We will start with access logs and take a look at what information can be found there. We will talk about the different directives that exist and see how to define the path to the log files and to the log file name, as well as how to specify a log format. It is important to learn how logs are written and be able to customize the writing of a log and specify which data will be logged.
Apache Logs Part 2
Last time we talked about access logs, this time we will go over error logs. Error logs log all errors that happen, unless otherwise specified. We will take a look at an error log example and see how to define the path to the error log files and specify a log format for error logs. After that we will say a few words about log levels, which dictate how detailed of a log file we want to have. There are sixteen different log levels that can be configured such as emerg, alert, error, warn, crit, debug, etc.
Apache Logs Part 3
In addition to error logs and access logs, there are also forensic logs in Apache that differ greatly from the other two log types. If this type of logging is enabled, it generates verbose log files for debugging purposes and it also allows us to examine log files in more detail. They are a type of log file that contains two entries per request which are distinguished by using the ‘+’ and ‘-’ symbols. With the help of forensics logs we can detect incomplete requests for security purposes. Throughout the video you will be given an example of a forensic log and see what kind of information can be found there.
Encryption Configuration Part 1
In the next few videos we will deal with the subject of configuring encryption. In this video we will begin with defining our virtual host. We will create a virtual host and as we go through the process slowly we will close off more and more loopholes and take many preventive measures in order to tighten the configuration and make it less susceptible to some kind of malicious activity. We will first create an html directory for our domains. After that you need to create a new directory for logs, as well as set ownership and permissions. When everything is configured you need to save and close.
Encryption Configuration Part 2
Now that we have configured our virtual host in the last video, we still need to inform Apache of what we are doing and what we are going to do. After we have informed it, we need to apply that configuration by reloading Apache. That is when we can then verify that we have made the initial configuration. We will create two directories - sites_enabled and sites_available. That is where our files for virtual hosts will be located. Then we will create another file whose name will be the domain name of our virtual host. That is where we will define our virtual host. Upon doing that, we will need to provide a link between our domain definition for the virtual host in sites-enabled and sites-available in order for it to work.
Encryption Configuration Part 3
Now next on the list regarding configuring encryption is that we need to configure SELinux firewall and get the certificate. First of all you will set proper SELinux labels for httpd_sys_content and httpd_log_t. After that you will enable EPEL repos, install cerbot and run cerbot for our domain. Cerbot dependencies will allow us to request a certificate. Lastly, we will need to configure a firewall on port 443, in order to get our base skeleton of a virtual host ready.
Encryption Configuration Part 4
In this last video we will finish up with all necessary configurations. We will open port 443 and reload our firewall. Furthermore, we will add a VirtualHost definition for port 443. Actually, since we are installing the certificate by using cerbot we do not need to create a separate configuration for port 443. Cerbot will already do that for us. Certbot will also configure HSTS for us. HSTS is something that protects you from attacks such as dns hijacking. It also prevents the stripping of encryption via wireless. Lastly, we will set up certificate auto renewal where we will see all the different configuration options we have regarding these auto renewals.
DDoS Protection and Server Side Includes (SSI) Part 1
In this video we are going to talk about DoS (Denial of Service) and DDoS (Distributed Denial of Service) attacks. The most focus will be put on their mitigation and how to prevent these attacks from affecting our servers as much as we can. If you are gonna run a web instance anywhere, the likelihood of you facing some sort of a DDoS attack is pretty high. DoS and DDoS attacks send a large amount of requests to your server. Every device has a limited amount of bandwidth, and if there is too much traffic coming in and out, it will take a long amount of time for requests to be processed, hence it will be like a traffic jam on your server. We can configure our server to be less susceptible to DDoS attacks and to limit the amount of bad traffic that is going to go into processing. We are going to implement several directives - LimitedRequestBody, TimeOut, KeepAliveTimeout and MaxClients, that will create certain restrictions to help us protect the server.
DDoS Protection and Server Side Includes (SSI) Part 2
Continuing on from where we left off, in this video we will proceed with getting introduced to some very useful directives that will help us protect our Apache server from DoS and DDoS attacks. Here we will talk about and configure the LimitRequestFields and LimitRequestFieldSize directives. Afterwards we will talk about Server Side Includes (SSI) and how to prevent others from injecting any kind of script into any of our HTML pages. This is done solved in a simple manner using the Options directive. To do this we will exclude Includes and ExecCGIs, restart Apache and verify the server status.
Server Banner and Entity Tag (ETag)
This time we will configure our Apache server in a way where we will prevent volunteering a certain type of information to the visitors of the server. This is configured in the main config file. We set the FileETag, ServerSignature and the ServerTokens to specific values. The FileETag can reveal the potential location ownership of the file and the date last modified, which is why we will set it to ‘none’. The server signature can reveal what version of Apache or what version of the operating system is that you are using, which is why we will set it to ‘off’. Lastly, by setting ServerTokens to Prod, it removes additional information that we are volunteering to whoever is visiting our site.
HTTP Request Methods
Here we will talk about HTTP request methods and request size. There are many different request methods such as GET, UPDATE, TRACE, MOVE, PUT, LABEL, etc. When the Apache server is running, there is a small chance that the application it is serving is using all the methods served by Apache. That is why you should not allow requests with methods the application does not have a way of processing. If you allow all methods, you are just exposing the server to unnecessary risks. In our example, we will configure the server to only allow POST and GET request methods.
Setting Up Cookie with `HttpOnly` and `Secure` Flag and X-XSS Protection
In this video, we will see some other ways how to secure our server, more specifically, how to mitigate a large amount of cross-site scripting (XSS) attacks. Here we will enable cross site scripting protection. We will also set up two flags (HttpOnly and Secure Flag). These types of protection are something that is usually done on the application side that the web server is serving, however we want to be able to stop anything that can be stopped before it reaches the application. If it cannot be stopped, then we will let the application deal with it.
The Clickjacking Attack
As we know by now, web servers are exposed to numerous kinds of attacks. The topic of this video is one of those attacks - clickjacking. Clickjacking is a kind of attack that attempts to hijack people’s clicks. Throughout the video, we will learn what it means to hijack a click and how to perform some configurations to secure the server better from them. Even though clickjacking does not harm our servers directly, it does use them to exploit other people. The servers serve as mediators for the attacks to get through to others. This is why it is important to protect our web servers as much as possible from those kind of attempts.
Disabling HTTP 1.0 Protocol, HTTP Trace, Apache Following of Symbolic Links and `HostnameLookups`
In this video we will continue with configuring our Apache server in various ways to make it less susceptible to exploitation. We will disable the HTTP 1.0 Protocol and we will use a rewrite engine to rewrite the requests onto HTTP 1.1. After that we are going to disable trace by turning TraceEnable off. Furthermore, we will disable the following of symbolic links by putting a ‘-’ sign in front of it in the Options directive and disable HostnameLookups by setting it to off. By turning HostnameLookups off, we mitigate DoS and DDoS attacks because more resources are going to be available to handle any sort of DoS attacks.