Difference between revisions of "WAF 390702"
(Created page with "{{Infobox |header1= Rule 390702 |label2 = Status |data2 = Active |label3 = Alert Message |data3 = Atomicorp.com WAF Rules: Multiple/Conflicting Connection Header Data Found }}...") |
m (→Tuning Guidance) |
||
| (7 intermediate revisions by one user not shown) | |||
| Line 9: | Line 9: | ||
= Description = | = Description = | ||
| − | This rules detects when multiple or conflicting connection headers are found. For example: | + | This rules detects when multiple or conflicting connection headers are found. For example, multiple entrys such as below: |
| + | ''Connection: keep-alive, keep-alive'' | ||
| + | |||
| + | Or conflicting headers, for example: | ||
| + | |||
| + | ''Connection: keep-alive, close'' | ||
| + | |||
| + | The use of multiple, or conflicting behavior is not normal or common for actual clients, and is extremely rare in a legitimate client. It is seen in common with attacks. | ||
| + | |||
| + | Broken and/or malicous clients are known to use this method to try to trick a firewall or IDS using duplicate or conflicting headers. No client should submit an entry with multiple or conflicting entries. Unfortunately, some automated programs do not not obey the HTTP RFC, and malicious clients are known to use this method to try to trick intrusion detection systems and firewalls to allow the attack to pass through. A proper request should only contain one entry, for example: | ||
| + | |||
| + | ''Connection: keep-alive'' | ||
| + | |||
| + | If you see this rule being triggered you have either a malicious client connecting to your system, or a broken application or client. In either case, we do not recommend you disable this rule as it will detect potentially unknown attacks associated with this condition. | ||
| + | |||
| + | This has also been known to happen when a malicious client is proxying its connection through a system to hide its real IP. Real non-malicious proxy servers do not cause this behavior, this behaviour is best thought of as a bug the client is causing as its manipulating the session to hide its real location. | ||
| + | |||
| + | == Examples == | ||
| + | |||
| + | |||
| + | === Classic Example === | ||
| + | |||
| + | This is what an HTTP request looks like to the server. This is what the client sends to the server to request a resource, to post data, etc. The headers below are set by the client, not the server. | ||
| + | |||
| + | <pre> | ||
| + | GET /some/file HTTP/1.1 | ||
Connection: keep-alive, keep-alive | Connection: keep-alive, keep-alive | ||
| + | Accept: */* | ||
| + | Referer: http://www.example.com/someurl | ||
| + | Accept-Language: en | ||
| + | Accept-Encoding: gzip, deflate | ||
| + | User-Agent: Mozilla/4.0 | ||
| + | Cookie: somecookie | ||
| + | Host: http://www.example.com | ||
| + | </pre> | ||
| − | + | In the example above, the "Connection:" header has two entries "keep-alive, keep-alive". Per the HTTP RFC this header should only have one entry "keep-alive". This is used by some attackers to cause DOS attacks on servers, and is also an indicator that either a broken | |
| + | proxy or a broken client is attempting to connect to the server, both of which may indicate the client has malicious intent. | ||
| + | |||
| + | === Malicious proxy example === | ||
| + | |||
| + | <pre> | ||
| + | GET /someurl/ HTTP/1.0 | ||
| + | Host: example.com | ||
| + | Connection: close, close | ||
| + | Accept-Language: zh-cn,zh-tw, zh-cn,zh-tw | ||
| + | User-agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.2 (KHTML like Gecko) Chrome/15.0.860.0 Safari/535.2Chrome/15.0.860.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.20.25 (KHTML like Gecko) Version/15.0.860.0, Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.2 (KHTML like Gecko) Chrome/15.0.860.0 Safari/535.2Chrome/15.0.860.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.20.25 (KHTML like Gecko) Version/15.0.860.0 | ||
| + | Accept: */* | ||
| + | </pre> | ||
| + | |||
| + | The example above is a real attack that occurred on a honeypot. In the headers above there a number of errors and duplication caused by the attacker. For excample, the Connection header and Accept-Language headers are duplicated, a classic give away that the attacker is trying to proxy traffic through a compromised host. The attack has also sent a highly duplicated User-agent header, which contains numbers contradictory user agents (the client is reported to be using Chrome and Safari at the same time, which is completely impossible. | ||
= Troubleshooting = | = Troubleshooting = | ||
| Line 19: | Line 66: | ||
== False Positives == | == False Positives == | ||
| − | None. | + | None. This rule can not generate a false positive. If this rule triggers the client is sending duplicate Connection headers, which is both invalid and may indicate an attack is imminent or in progress. |
| + | |||
| + | The detection of bogus headers is an excellent way to detect new attacks and attack sources that may not otherwise be detectable. As this behavior is never normal, and does not occur with either a properly configured proxy server, or any web browser we do not recommend you disable this rule. | ||
== Tuning Guidance == | == Tuning Guidance == | ||
| − | None. This rule detects | + | None. This rule detects multiple connection header entries. If clients are connecting in this manner this is a bug on the client side, and the connection is invalid. |
= Additional Information = | = Additional Information = | ||
Latest revision as of 17:28, 14 November 2013
| Rule 390702 | |
|---|---|
| Status | Active |
| Alert Message | Atomicorp.com WAF Rules: Multiple/Conflicting Connection Header Data Found |
Contents |
[edit] Description
This rules detects when multiple or conflicting connection headers are found. For example, multiple entrys such as below:
Connection: keep-alive, keep-alive
Or conflicting headers, for example:
Connection: keep-alive, close
The use of multiple, or conflicting behavior is not normal or common for actual clients, and is extremely rare in a legitimate client. It is seen in common with attacks.
Broken and/or malicous clients are known to use this method to try to trick a firewall or IDS using duplicate or conflicting headers. No client should submit an entry with multiple or conflicting entries. Unfortunately, some automated programs do not not obey the HTTP RFC, and malicious clients are known to use this method to try to trick intrusion detection systems and firewalls to allow the attack to pass through. A proper request should only contain one entry, for example:
Connection: keep-alive
If you see this rule being triggered you have either a malicious client connecting to your system, or a broken application or client. In either case, we do not recommend you disable this rule as it will detect potentially unknown attacks associated with this condition.
This has also been known to happen when a malicious client is proxying its connection through a system to hide its real IP. Real non-malicious proxy servers do not cause this behavior, this behaviour is best thought of as a bug the client is causing as its manipulating the session to hide its real location.
[edit] Examples
[edit] Classic Example
This is what an HTTP request looks like to the server. This is what the client sends to the server to request a resource, to post data, etc. The headers below are set by the client, not the server.
GET /some/file HTTP/1.1 Connection: keep-alive, keep-alive Accept: */* Referer: http://www.example.com/someurl Accept-Language: en Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 Cookie: somecookie Host: http://www.example.com
In the example above, the "Connection:" header has two entries "keep-alive, keep-alive". Per the HTTP RFC this header should only have one entry "keep-alive". This is used by some attackers to cause DOS attacks on servers, and is also an indicator that either a broken proxy or a broken client is attempting to connect to the server, both of which may indicate the client has malicious intent.
[edit] Malicious proxy example
GET /someurl/ HTTP/1.0 Host: example.com Connection: close, close Accept-Language: zh-cn,zh-tw, zh-cn,zh-tw User-agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.2 (KHTML like Gecko) Chrome/15.0.860.0 Safari/535.2Chrome/15.0.860.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.20.25 (KHTML like Gecko) Version/15.0.860.0, Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.2 (KHTML like Gecko) Chrome/15.0.860.0 Safari/535.2Chrome/15.0.860.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.20.25 (KHTML like Gecko) Version/15.0.860.0 Accept: */*
The example above is a real attack that occurred on a honeypot. In the headers above there a number of errors and duplication caused by the attacker. For excample, the Connection header and Accept-Language headers are duplicated, a classic give away that the attacker is trying to proxy traffic through a compromised host. The attack has also sent a highly duplicated User-agent header, which contains numbers contradictory user agents (the client is reported to be using Chrome and Safari at the same time, which is completely impossible.
[edit] Troubleshooting
[edit] False Positives
None. This rule can not generate a false positive. If this rule triggers the client is sending duplicate Connection headers, which is both invalid and may indicate an attack is imminent or in progress.
The detection of bogus headers is an excellent way to detect new attacks and attack sources that may not otherwise be detectable. As this behavior is never normal, and does not occur with either a properly configured proxy server, or any web browser we do not recommend you disable this rule.
[edit] Tuning Guidance
None. This rule detects multiple connection header entries. If clients are connecting in this manner this is a bug on the client side, and the connection is invalid.
[edit] Additional Information
[edit] Similar Rules
None.
[edit] Knowledge Base Articles
None.
[edit] Outside References
None.
