Like many server admins who suffer from congestion, we decided to use a two-pronged approach. Http:bl to block spurious requests and spammers, and a caching proxy in front of our main services to speed up access times. Is there a way of running http:bl through something other than Apache or the web application itself? Because the ideal scenario here is that the caching proxy performs all of the operations related to access control, including querying project honeypot. But mod-security, which at one point was capable of using honeypot as a blacklist, isn't stable when run with nginx and keeps crashing. So afaik we're SOL for running http:bl on the caching server. We were running it on the main services instance using a drupal plugin, but then it blocked our proxy server. So that was awkward. I know X-FORWARDED-FOR can't be trusted, but surely it would be enough to give administrators an option to allow a specific IP and when connections originate from that IP, then and only then to trust the X-FORWARDED-FOR header?

So we have had to disable http:bl for now, unfortunately.

Comments

daniel4141’s picture

daniel4141 commented

Like many server admins who suffer from congestion, we decided to use a two-pronged approach. Http:bl to block spurious requests and spammers, and a caching proxy in front of our main services to speed up access times. Is there a way of running http:bl through something other than Apache or the web application itself? Because the ideal scenario here is that the caching proxy performs all of the operations related to access control, including querying project honeypot. But mod-security, which at one point was capable of using honeypot as a blacklist, isn't stable when run with nginx and keeps crashing. So afaik we're SOL for running http:bl on the caching server. We were running it on the main services instance using this drupal plugin, but then it blocked our proxy server. So that was awkward. I know X-FORWARDED-FOR can't be trusted, but surely it would be enough to give administrators an option to allow a specific IP and when connections originate from that IP, then and only then to trust the X-FORWARDED-FOR header?

So we have had to disable the plugin for now, unfortunately.

bryrock’s picture

bryrock commented
Status: Active » Postponed (maintainer needs more info)

This is a very confusing post. Are you referring to the Drupal module or the Apache module? This issue queue is only for the Drupal module, and does not require apache mods to work. If you need support for the apache mod, that should be addressed to project honeypot.

What exactly blocked your proxy server, what reason was given, and why do you feel that is a bug?

bryrock’s picture

bryrock commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Closing this. Never received any follow up to this to clarify exactly what the issuer was referring to or how to reproduce the issue.