Confusing vhost and defatult frang limits

[krizhanovsky]

Scope

I've spent about 1 hour trying to understand why if I use a configuration like

listen 192.168.100.4:443 proto=https;
listen 192.168.100.4:80;

srv_group default {
        server 127.0.0.1:8080 conns_n=4;
}

vhost default {
        tls_certificate /root/tempesta/etc/tfw-root.crt;
        tls_certificate_key /root/tempesta/etc/tfw-root.key;

        resp_hdr_set Strict-Transport-Security "max-age=31536000; includeSubDomains";

        proxy_pass default;
}

cache 0;

http_uri_brange 0x2f 0x41-0x5a 0x61-0x7a 0x30-0x39 0x2d 0x5f; # /a-zA-Z0-9-_

frang_limits {
        http_methods GET;
        http_uri_len 512;
        http_resp_code_block 400 403 404 3 10;
        client_header_timeout 20;
        client_body_timeout 10;
        http_header_chunk_cnt 10;
        http_body_chunk_cnt 0;
}

block_action attack reply;

http_chain {
        #-> debian;
        -> default;
}

and send many requests producing 403 response, Tempesta FW doesn't execute the http_resp_code_block limit. The reason is that I had to move frang_limits to vhost section - in this case the limit works perfectly. I'd expect that the configuration above applies as the default for all virtual hosts, but this doesn't happen. Also note that frang/test_http_resp_code_block.py test uses configuration as

server ${server_ip}:8000;

frang_limits {
    http_resp_code_block 404 5 2;
}

, i.e. w/o any vhosts at all and the test works fine.

We need either to fix the problem or explain the behaviour in https://github.com/tempesta-tech/tempesta/wiki/HTTP-security#frang-security-limits-enforcing-module

Testing

Please update frang/test_http_resp_code_block.py with the scenario,

[krizhanovsky]

Also the configuration from #1439 (comment) leads to misleading configuration error

[  131.755540] [tempesta fw] ERROR: configuration parsing error:
[  131.755540]   19:            client_body_timeout 10;
[  131.755540]       ^^^^^^^^^^^^^^^^^^^^^^^^^

instead of explaining that the limit must be in global section.

Maybe it's easier to run a configuration check in a user space script than to handle it in the kernel C configuration. Probably this is subject for cfg_upd daemon from #67.

[vankoven]

This is all about implicit directives and directive inheritance between sections. (Some times I hate that feature because of debugging complexity).

What is happening in this configuration. A top-level frang_limits section describes two type of Frang limits:

• connection-level applied to all vhosts (e.g. client_header_timeout), and
• message-level (e.g. http_resp_code_block)

Connection-level limits will be applied to all vhosts, because they works at lower levels, when HTTP information is not yet available. Since message-level limits are defined at top-level of configuration, they are not attached to any vhost instead they update default Frang values for vhost listed below top-level directive.

In your configuration explicit default vhost was listed before frang configuration was redefined, that it why you didn't see http_resp_code_block limit in action.

In the test the situation differ: default vhost is added implicitly after the whole configuration is processed. That is why it catches updated Frang defaults.

When we spoke about #862 and #67 we mentioned that Tempesta should have option to print current effective configuration in short (skipping implicit) and long (showing all implicit) forms. This will make understanding and debugging configuration much more easier and user-friendly.

[krizhanovsky]

OK, I added example configuration

listen 192.168.100.4:443 proto=https;

srv_group default {
	server 127.0.0.1:8080 conns_n=4;
}

vhost default {
	tls_certificate /root/tempesta/etc/tfw-root.crt;
	tls_certificate_key /root/tempesta/etc/tfw-root.key;

	resp_hdr_set Strict-Transport-Security "max-age=31536000; includeSubDomains";

	frang_limits {
		http_methods GET;
		http_uri_len 512;
		http_resp_code_block 400 403 404 3 10;
	}

	proxy_pass default;
}

cache 0;

frang_limits {
	client_header_timeout 20;
	client_body_timeout 10;
	http_header_chunk_cnt 10;
	http_body_chunk_cnt 0;
}

block_action attack reply;

http_chain {
	-> default;
}

to https://github.com/tempesta-tech/tempesta/wiki/HTTP-security#frang-security-limits-enforcing-module . I also added statement that the global limits must be specified before vhosts.

Also I missed a line of the log error, the whole error was:

[  131.753483] [tempesta fw] ERROR: Directive 'client_body_timeout' from 'frang_limits' group can be used only as top-level directive (outside of any 'vhost' directive).
[  131.755540] [tempesta fw] ERROR: configuration parsing error:
[  131.755540]   19:            client_body_timeout 10;
[  131.755540]       ^^^^^^^^^^^^^^^^^^^^^^^^^
[  131.757695] [tempesta fw] Warning: Configuration parsing has failed. Clean up...