Forum

Hello Hugo,

Wanted to raise the useragent blocking again. Because lots of users are having Wordpress useragent attack and we are unable to filter it with hiawatha.

Blocking useragent on end user server is not the best idea, because it requires addition of the block to .htaccess file for Apache (in hiawatha reverse proxy mode), and apache is still having extremely high load during the attack.

It would be best if hiawatha had some way of blocking unwanted useragents at least.

10.71.9.109|Mon 22 Dec 2014 18:43:13 +0100|200|1337||GET /index.php/?627757=-664003 HTTP/1.0|User-Agent: WordPress/3.7.5; http://115.29.178.160/wordpress; verifying pingback from 217.78.6.99|Host: avocapitals.com|Accept: */*|X-Pingback-Forwarded-For: 217.78.6.99

Regards
Andrew

Ok, I'm gonna make you a deal. I'll place the reverse proxy code after the URL toolkit code, which allows you to block clients based on their User-Agent string before handing the request over to a webserver. This is a serious change, so in return you help me test this thoroughly. Deal?

@Hugo,

Is it mean 'ReverseProxy' inside 'UrlToolkit {}'?. If yes, I hope this feature implemented in next version (according to https://www.hiawatha-webserver.org/forum/topic/1768)

No, configuration stays the same. But when you now specify an URL toolkit rule and a reverse proxy in one (virtual) host, the URL toolkit is ignored because of the reverse proxy. What I want to change is that Hiawatha first does the URL toolkit processing and then look at the reverse proxy settings. I don't want the reverse proxy to depend on the URL toolkit.

@Hugo,

Imagine for this situation:

- init.conf

FastCGIserver {
	FastCGIid = fastcgi_for_admin
	ConnectTo = /opt/configs/php-fpm/sock/admin.sock
	Extension = php
}

ReverseProxyserver {
	ReverseProxyid = reverseproxy_for
	ReverseProxy !\.(pl|cgi|py|rb|shmtl) http://127.0.0.1:30080/ 90 keep-alive
}

UrlToolkit {
	ToolkitID = utk_fastcgi_for_admin
	UseFastCGI = fastcgi_for_admin
}

UrlToolkit {
	ToolkitID = utk_reverseproxy_for
	UseReverseProxy = reverseproxy_for
}

- domain.com.conf

VirtualHost {
	## set reverseproxy as default
	UseToolkit = utk_reverseproxy_for
}

- .hiawatha

## able to switch to fastcgi
UseToolkit = utk_fastcgi_for_admin

User able switch from reverseproxy to fastcgi (or vice-versa) using .hiawatha.

I understand your usecase, but I don't see it as a realistic one. Why would you want to make such a switch? Why split up a website like that?

The reason is most users familiar with apache and my share-hosting using hiawatha-proxy. If hiawatha possible declare reverseproxy inside urltoolkit, the advantage is user possible trying hiawatha alone easily with declare 'useToolkit=' inside .hiawatha. No 'restart' for hiawatha service with this approach.

Hello Hugo,

We will definitely help test it as we are using hiawatha on many servers and for many clients.

Regards
Andrew