Drop HTTP session on security events

[vankoven]

Linked with #598

When a security event happens TCP connection between Tempesta and client is closed. Optionally source ip is blocked.

How about HTTP session? Shall we mark HTTP session as expired to stop client from reaching us via proxies, and make him to pass java script challenge once again?

Testing

• Drop HTTP session on security events. See #88

[krizhanovsky]

Good question. Ideally we should provide a configuration option for a system administrator: whether to block a [probably] malicious client on IP layer or challenge them next time on HTTP layer. So it's linked with #934 (Filter unification with nftables and/or XDP) and I move it to 1.2 milestone.

Linked with #598 (comment) : #1115 has introduced client differentiation by HTTP headers - such clients can work through the same TCP connection established by a proxy and we need to drop their HTTP sessions separately.

[krizhanovsky]

UPD.

1. L7 IP blocking #934 updated not to block clients on IP layer since client IP on our, application HTTP layers, is very different and we don't know it on lower layers. So we do differentiate clients and won't block all clients behind the same anonymous forward proxy.

2. With one in mind I believe there is no need to keep session for malicious user and we should evict the session. Just mark the session as expired for a blocked client, no need any additional configuration options.