Keep Server Online
If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.
or
A donation makes a contribution towards the costs, the time and effort that's going in this site and building.
Thank You! Steffen
Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
| |
|
 Topic: HOWTO: Securing Windows filesystem for Apache |
|
| Author |
|
tangent
Moderator
Joined: 16 Aug 2020
Posts: 461
Location: UK
|
 Posted: Tue 21 Jul '26 15:39 Post subject: HOWTO: Securing Windows filesystem for Apache |
 |
|
Windows security is a constant cause for concern, with new issues and vulnerabilities being unearthed on a regular basis. However, one potential problem area that has been around for a long time is platform filesystem security (NTFS), and of interest to Apache Lounge users, how that relates to Apache installations.
This brief HowTo document discusses options for restricting access to the Apache installation, to circumvent unwanted access to the configuration and content.
By default, Apache Lounge builds are created and configured with a target directory of C:\Apache24, and it's left to the individual to create that directory and extract the binary distribution from an appropriate download archive.
One issue here is that by default, Windows grants modify access to Authenticated Users, to directories created under the C:\ root, so depending on your server platform, its configuration, and who can log on to your server, you may want to restrict access rights to Apache files, and limit them to local Administrators.
When you create a new C:\Apache24 directory, you can check the Discretionary Access Control Lists (DACLs) assigned to that object (in a command window) using the icacls command:
| Code: | C:\>icacls C:\Apache24
C:\Apache24 BUILTIN\Administrators:(I)(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(I)(M)
NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
Successfully processed 1 files; Failed processing 0 files |
This output shows there are 5 Access Control Entries (ACEs) on the directory, each one comprising a named system user (SID) with corresponding permissions. There is one relating to "BUILTIN\Users" (for members of the local Users group), and two for "NT AUTHORITY\Authenticated Users" (for anyone who has successfully authenticated, be they a local or domain user).
The permission details are described at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls, but in relation to the above output, in summary we have:
• (I) - Inherit. ACE inherited from the parent container.
• (OI) - Object inherit. Objects in this container inherits this ACE. Applies only to directories.
• (CI) - Container inherit. Containers in this parent container inherits this ACE. Applies only to directories.
• (IO) - Inherit only. ACE inherited from the parent container, but doesn't apply to the object itself. Applies only to directories.
• (F) - Full access.
• (M) - Modify access.
• (RX) - Read and execute access Note, on a standard Windows platform, this directory can be created by an Administrator OR an Authenticated User, since the default permissions allow Authenticated Users to create new objects off the root directory. Perhaps surprisingly, Authenticated Users are granted modify permissions, as well as a number of inheritance rights, the icalcs help command (icacls /?) revealing just how complicated NTFS permissions can be (for example try "icacls C:\Windows").
The concern here is, for best security (file ownership aside), we need to revoke the Access Control Entries (ACEs) for Authenticated Users, specifically the Modify permission. This will prevent users other than Administrators being able to change the Apache files.
The remaining "BUILTIN\Users" read and execute (RX) permission is of relevance here too.
If you revoke the ACE for this class of user as well, then basically everything concerning Apache will have to be done as an Administrator from the command line. Windows Explorer (for a logged in local user) will no longer be able to access the Apache files, but moreover if that local user happens to be an Administrator, then when you do try to access them, it will offer to "permanently get access" to them, and what it does is then grant "BUILTIN\Users" FULL access rather than the Read/Search they previously had. Not advisable.
So the recommendation is to leave the "BUILTIN\Users" ACE unchanged, so that local users can at least see the Apache files through Windows Explorer. If that user also happens to be a member of the local administrators group, then they'll be able to modify file permissions through Windows Explorer, should they need to change the content of a given file.
In summary, the recommended DACL changes can be made using the following icacls commands:
| Code: | C:\>icacls C:\Apache24 /inheritance:d /T /L
C:\>icacls C:\Apache24 /remove:g "Authenticated Users" /T /L |
The first command breaks inheritance from the parent directory, whilst the second command removes all explicit grants for "Authenticated Users".
The /T option applies the command recursively, whilst the /L option relates to symbolic links or directory junctions that may have been created or added below the Apache root.
The revised DACL for C:\Apache24 should look like this:
| Code: |
C:\>icacls C:\Apache24
C:\Apache24 BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Users:(OI)(CI)(RX)
Successfully processed 1 files; Failed processing 0 files |
Note these icacls commands can be applied to secure an existing installation or archive extraction below C:\Apache24, or equally to a new directory before extracting Apache. The only issue is once applied, you will need to be an Administrator to modify or create new files.
Optionally, should you really need to grant read and execute (including list/search) access back to Authenticated Users (for domain accounts say), you could then apply:
| Code: | | C:\>icacls C:\Apache24 /grant "Authenticated Users":(OI)(CI)(RX) /T /L |
Should your Apache installation be in a non-standard location, you will of course need to revise the directory reference in the above icacls commands.
Additionally, for non-standard locations we recommend you also set the OPENSSL_CONF environment variable, to point to your revised OpenSSL configuration directory, for the Apache process owner. For Windows services, that would need to be done as a system-wide environment variable, since Windows doesn't support per service environment variables.
Summary
• The steps to secure an Apache installation should be the same for both standard and non-standard locations.
• Having extracted the Apache files into the required directory, then ideally you should set up your configuration files, site content, etc.
• As an administrator, configure Apache to run as a service as required.
• If using a non-standard location, set the OPENSSL_CONF appropriately as a system-wide environment variable.
• Apply the required above icacls commands to restrict access.
• Start the Apache service and check the log files as necessary. Performing the above steps should help secure your Apache installation against unauthorised modification.
Comments and further recommendations are welcome. |
|
| Back to top |
|
|
|
|
|
|
