How to Protect your Webserver from Directory Enumeration Attack ? Apache2 [Guest Diary]

Published: 2023-12-20
Last Updated: 2023-12-21 02:44:10 UTC
by Guy Bruneau (Version: 1)
0 comment(s)

[This is a Guest Diary by David Thomson, an ISC intern as part of the 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. 

Get Ubuntu Server | Download | Ubuntu
How To Install the Apache Web Server on Ubuntu 20.04 | DigitalOcean

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:

<Files "filename">
  Order Allow,Deny
  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


Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

0 comment(s)

Increase in Exploit Attempts for Atlassian Confluence Server (CVE-2023-22518)

Published: 2023-12-20
Last Updated: 2023-12-20 15:31:05 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

Today, exploit attempts for CVE-2023-22518 cross the "significant" threshold for our "First Seen URLs" list. The URL being accessed, "/json/setup-restore.action?synchronous=true", can be used to bypass authentication [1]. Due to a failure to properly control access to this path, the attacker can execute the "setup-restore" feature, which restores the database using attacker-supplied data and can lead to system command execution.

Attacks for the vulnerability started early in November, shortly after the vulnerability was announced. At the time, the attacks were more targeted to specific hosts. Now we are seeing more widespread scans typical for attackers trying to "clean up" instances earlier attacks may have missed.

graph of attack volume from early november to late december 2023 for the atlasian auth bypass URL

One IP address has been particularly active: This IP address, hosted with Digital Ocean, appears to specialize in Confluence vulnerabilities, with sporadic activity back to October 2023. 

Interestingly, and somewhat concerning, the IP address is associated with the hostname based on DNS and hostnames in certificates offered by the system. On port 443, a Jira instance is responding. This may indicate that the system itself is compromised. is an employee health/wellness company, according to their website. I will be reaching out to notify them.


Johannes B. Ullrich, Ph.D. , Dean of Research,

0 comment(s)
ISC Stormcast For Wednesday, December 20th, 2023


Diary Archives