DOC: enhance development doc to show how CVE-2013-2178 was done

DEVELOP

@@ -56,13 +56,21 @@ Filter Security
 Poor filter regular expressions are suseptable to DoS attacks.
 
 When a remote user has the ability to introduce text that will match the 
-filter regex such that the inserted text matches the <HOST> part they have the
+filter regex, such that the inserted text matches the <HOST> part, they have the
 ability to deny any host they choose.
 
-So the <HOST> part must be anchored on text generated by the application and not
+So the <HOST> part must be anchored on text generated by the application, and not
-the user. Ideally this should anchor to the beginning and end of the log line
+the user, to a sufficient extent that the user cannot insert the entire text.
+
+Filters are matched against the log line with their date removed.
+
+Ideally filter regex should anchor to the beginning and end of the log line
 however as more applications log at the beginning than the end, achoring the
-beginning is more important.
+beginning is more important. If the log file used by the application is shared
+with other applications, like system logs, ensure the other application that
+use that log file do not log user generated text at the beginning of the line,
+or, if they do, ensure the regexs of the filter are sufficient to mitigate the
+risk of insertion.
 
 When creating a regex that extends back to the begining remember the date part
 has been removed within fail2ban so theres no need to match that. If the format
@@ -99,7 +107,7 @@ The fix here is that the command can be anything so .* is approprate.
 
 Here the .* will match until the end of the string. Then realise it has more to
 match, i.e. "from <HOST>" and go back until it find this. Then it will ban
-1.2.3.4 correctly. Since the <HOST> is always at the end, end the regex witha $
+1.2.3.4 correctly. Since the <HOST> is always at the end, end the regex with a $.
 
     ^Invalid command .* from <HOST>$
 
@@ -110,7 +118,28 @@ Note if we'd just had the expression:
 Then provided the user put a space in their command they would have never been
 banned.
 
-2. Applicaiton generates two identical log messages with different meanings
+2. Filter regex can match other user injected data
+
+From the apache vulnerability CVE-2013-2178
+( original ref: https://vndh.net/note:fail2ban-089-denial-service ).
+
+An example bad regex for apache:
+
+    failregex = [[]client <HOST>[]] user .* not found
+
+Since the user can do a get request on:
+
+    GET /[client%20192.168.0.1]%20user%20root%20not%20found HTTP/1.0
+Host: remote.site
+
+Now the log line will be:
+
+    [Sat Jun 01 02:17:42 2013] [error] [client 192.168.33.1] File does not exist: /srv/http/site/[client 192.168.0.1] user root not found
+
+As this log line doesn't match other expressions hence it matches the above
+regex and blocks 192.168.33.1 as a denial of service from the HTTP requester.
+
+3. Applicaiton generates two identical log messages with different meanings
 
 If the application generates the following two messages under different
 circmstances:
@@ -119,7 +148,7 @@ circmstances:
     client <USER>: authentication failed
 
 
-Then its obvious that a regex of "^client <HOST>: authentication
+Then it's obvious that a regex of "^client <HOST>: authentication
 failed$" will still cause problems if the user can trigger the second
 log message with a <USER> of 123.1.1.1.