[This is a Guest Diary by David Thomson, an ISC intern as part of the SANS.edu BACS program]
This post is correlated with my attack observation 04, which details an interesting series of directory requests to the dshield honeypot system. The attack is categorized as Network Service Discovery from the MITRE | ATT&CK Framework.
In this attack we observe a series of directory requests to Honeypot. The directory requests include a series of different words in the first sub-directory.
For the purpose of this blog post, I installed apache2 on a Ubuntu server machine.
This blog post will analyze the attack and go through how to protect an apache2 system.
Below is a snippet of the logs generated from this attack, which took place on 11/18/2023:
In the URL category we observe a series of http requests, arbiter, corsair among others. These are the requests from the attack in the hopes of gathering information that would potentially be stored in these locations. This is the same as requesting any directory from a site. An example would be requesting the robots.txt file, see the following example:
In the image above by manually appending robots.txt to the VirusTotal URI I’ve essentially sent an http request for /robots.txt. In this case the information stored here is intentional and meant to inform webcrawlers what directories and files they should ignore. The potential problem with this attack is what if you have something stored that clients should not be able to access but they can? Examples include configuration files, files with PII information, the options are limitless.
So how do we protect ourselves against incorrectly allowing end users access to directories and files they should not have access to?
Well by default Ubuntu has already locked down web browser access to the /var/www directory. When setting up the Apache server the default file located in this directory is the index.html, which if you read the documentation is just for testing purposes and should be replaced after the test is completed. I have added another file that I don’t want users to see but I left it unprotected! Let’s look:
Here is the added file:
Here is what happens when an end user requests this document:
Now how to prevent this type of activity?
One method is to utilize the .htaccess file. First, we create this file in the directory where the file is located:
Then we edit the file and add the following information:
Deny from all
Now we test to see if it worked:
Success! The only thing that’s left is to expand this to any files you are trying to protect. Additionally, the method above restricts access to the file for all users, however this file can be edited to include permissions so only certain users have access by appending the following statement:
Allow from userA userB
Finally let’s speak about WAF or Web Application Firewalls. These are another top-notch option to protect your webserver, key word “web”. They protect your web applications by filtering, monitoring, and blocking packets outbound and inbound. One option for WAF is ModSecurity. ModSecurity is an open-source Apache module designed to help protect your Apache webserver against many attacks just like the ones observed above!
Installation is relatively easy:
Download the module:
Enable the ModSecurity module:
Always make sure to restart services:
Next up, just like with any service we have a .conf file or configuration file that allows customization. The default conf file is located: /etc/modsecurity/modsecurity.conf it looks like this:
However, there is also a configured conf file already at /etc/modsecurity/modsecurity.conf-recommended. You can mv it to enable the file by using the following command:
sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
Here is what the new configuration file looks like:
More information can be found here: OWASP ModSecurity Core Rule Set | OWASP Foundation
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.