Solved The .htpasswd file is not working on any server anymore and is readable!

[Richard G]

I don't know since when, maybe last apache update, but I'm not 100% sure.

I'm using a self-made (so not via DA) .htaccess file in a subdirectory and a .htpasswd file and this has been working for years.
I didn't change anything and now it's not working on *any* server anymore.

And mod_htscanner2 is installed for a long time already.

Checked every logfile, also domain logfiles, not a single error or warning or even a get request for the .htpasswd or anything.

Need to fix this urgently.
And no I do -not- want to use the DA systems way, it has always been working with self made .htaccess files so should work now too.

 

[Richard G]

Just got confirmation from a collegue that is indeed not working anymore, it does via GUI, but not the self made ones.

Causing a security risk ofcourse because the self created (and existing) .passwd files are world readable!!
I send in a ticket for this #64434, because this is too important.

 

[Wanabo]

Just got confirmation from a collegue that is indeed not working anymore, it does via GUI, but not the self made ones.

Causing a security risk ofcourse because the self created (and existing) .passwd files are world readable!!
I send in a ticket for this #64434, because this is too important.

As I mentioned elsewhere, I was testing DA+OLS and had this issue as well. Fixed it by using the DA procedure using the DA-gui.

 

[Richard G]

Fixed it by using the DA procedure using the DA-gui.

Yes well that is no fix but a wordaround. It should work anyway, even without GUI.

 

[Wanabo]

Indeed. When people are not aware of this, directories that once where protected are unprotected.

 

[johannes]

Richard are you on OLS?

 

[Richard G]

Hello @johannes
No I'm on just plain default Apache, nothing special and the issue just also got confirmed in the ticket that it's not working with self made .htaccess and .htpasswd files.
The being readable of the .htpasswd file depends on having modsecurity installed or not, when installed, it can not be read.

However lots of people do not have that installed so for these people it's a big security issue too.

 

[Richard G]

Just wondering why these files are readable because in the httpd.conf file:

<Files ".ht*">
Require all denied
</Files>

should prevent the reading of these files. So no clue yet as why this is happening.
Still.... that does not explain that working of .htpasswd suddenly stopped.

 

[Richard G]

Found a server on which it is working as designed. I have to check for differences between those servers.

 

[Richard G]

Found it.

On almost all servers I used a custom httpd-includes.conf file like mentioned in this post here:

H

Post in thread 'Block IP addresses which overload server'

Mar 20, 2025

Zhenyapan has right. it is better to put all bots in a conf file to block globaly.

you have thing it's like this. .htaccess it is like plugin each time have to hook it from apache
if you use .htaccess (each sites) for each time have to hook it. this can be negativ effect of site speed,
if you have long list of bots or uri on .htaccess file

you can also add the bots name or uri in Apache custom files like Zhenyapan make in nginx to block spieder or uri.

for Apache test this
open your /etc/httpd/conf/extra/httpd-includes.conf file

add following lines. i put some exampel...

• Hostmavi

• 

However, for some reason, the "require all granted" overrides the httpd.conf setting for ht* files, causing .htpasswd not only not to work but even to get readable.

I always thought the httpd-include.conf would add things, did not expect it to override the ht* permissions from httpd.conf.
When making the httpd-includes.conf empty and restarting apache, everything is working as designed again.

I will use another method and post in that thread better not to use that option.

 

[johannes]

I always thought the httpd-include.conf would add things, did not expect it to override the ht* permissions from httpd.conf.

good point to remember. thx for sharing it!

 

[Richard G]

@Wanabo You had the same issue as I had. Did you also use the same method to block bad bots?

 

[Wanabo]

No, I don't block bad bots in .htaccess or httpd.conf. I made a custom bad bot file (based on User Agent) that is blocked with Mod Security. And I've booby trapped some scrips that write to the apache log and get blocked by (lfd) Mod Security. So pure ipv4 and ipv6 bots are blocked as well.

I believe my problem was specific to DA+OLS (yes even after restarting the server). The solution was to use the "protect directories" from DA itself. On DA+httpd/nginx servers I did not have this problem. I can drop a single .htpasswd file in for example /home and put a .htaccess file in any directory I want protected. This works much faster than using the feature from DA.

 

[johannes]

I've booby trapped some scrips that write to the apache log and get blocked by (lfd) Mod Security. So pure ipv4 and ipv6 bots are blocked as well.

Would you mind to share this solution, or elaborate a little bit more, please? This sounds interesting to me.