Skip to content
Alexander K edited this page Feb 5, 2018 · 36 revisions

Temepsta FW implements a lightweight WAF (Web Application Firewall). Tempesta FW's core works in OS deferred interrupt context (softirq), so only quick security checks can be done. More features will come with the Kernel-User Space Transport. Nevertheless, Tempesta FW should be considered as a WAF accelerator which can offload many checks from more advanced WAFs and protect them from DDoS attacks or usual overloading.

Password crackers

If your web application works with user accounts, then typically it requires a user authentication. If you implement the user authentication on your web site, then an attacker may try to use a brute-force password cracker to get access to accounts of your users. An attacker can try many passwords for each known user name (i.e. you'll see many authorization requests for the same user name, but with different passwords) or use a database with user name and password pairs (now you'll be seeing many different login/password pairs - just like many users are trying to authorize). The second case is much harder to detect. It's worth mentioning that unsuccessful authorization requests typically produce error HTTP responses.

Tempesta FW provides limiting facility for efficient blocking of all types of password crackers (read more at Frang configuration page), e.g.

    http_resp_code_block 401 403 10 3

blocks an attacker's IP address if a protected web application return 10 error responses with codes 401 or 403 within 3 seconds.

Injection attacks

The most famous injection attacks are XSS and SQL injections. A classic example of passive XSS attack (requiring a client to click a malicious link) is

http://www.site.com/page.php?var=<script>alert('xss');</script>

It worth to mention that XSS attack also can use Cookie, Referer or Host headers, e.g. famous WordPress XSS vulnerability in RSS Feed Generator.

Tempesta FW verifies URI and all HTTP headers against allowed by the RFC alphabet. In particular, characters < and > aren't allowed by the RFC, and so a request containing such URI will be blocked by Tempesta FW. For the WordPress example

$ curl -H "Host: \"><body onload=alert(String.fromCharCode(88,83,83))>" http://www.example.org/blog/feed

all the special symbols, such as >, <, =, (, ) are blocked by Tempesta FW's Host header parser.

In next release Tempesta FW is going to implement even stronger and flexible mechanism for custom alphabets for HTTP fields.

HTTP Response Splitting

HTTP Response Splitting is also a type of injection attacks, so it can be mitigated by strong alphabet validation. Besides the input validation Tempesta FW counts number of requests and responses and warns a system administrator if they don't match, i.e. the attack took place.

Race conditions

Attacks exploiting race conditions in a Web application require many concurrent requests, so it's recommended to use rate limiting to prevent the attacks.

DNS rebinding

Host header must be validated to prevent DNS rebinding attack, so it's recommended to use sched_http_rules even if only one domain name is serviced by Tempesta FW, e.g.

listen 192.168.100.4:80;

srv_group test_grp {
        server 127.0.0.1:8080;
}

sched_http_rules {
        match   test_grp        host    suffix  ".test.com";
}

, now any request out of test.com domain in Host header will be blocked by Tempesta FW.

Clone this wiki locally