Hi fail2ban team!
I need help with failregex for django log!
My log line is for example:
2021-02-10 16:50:31,096 WARNING AXES: New login failure by {username: "xxx", ip_address: "5.169.172.125", user_agent: "Mozilla/5.0 (Linux; Android 10; M2007J20CG) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.101 Mobile Safari/537.36", path_info: "/amministrazione/login/"}. Creating new record in the database.
2021-02-10 16:51:01,426 WARNING AXES: Repeated login failure by {username: "xxx", ip_address: "5.169.172.125", user_agent: "Mozilla/5.0 (Linux; Android 10; M2007J20CG) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.101 Mobile Safari/537.36", path_info: "/amministrazione/login/"}. Count = 1 of 10. Updating existing record in the database.
Thanks!
failregex = ^. login failure . ip_address: "<host>"</host>
In case the tags in info structure (JSON5?) are always given in this order (and there are no other tags in-between) you can use this one:
Otherwise you could use something like that:
If
AXESis some dynamic data (may deviate depending on context) replace it either with\w+or with\S+.In case you have some old fail2ban version (<= 0.9), remove both tags
<F-USER>and replace<ADDR>with<HOST>.Diff:
Thanks!
IT ALSO WORKS:
it is OK?
Thanks!
Last edit: selena 2021-02-10
No! This regex is vulnerable, since due to 2 catch-all's and unanchored matter can match the IP everywhere (e. g. in foreign input too). So it has several issues starting with performance and ending with certain vector for an injection on forign input.
And
^.*is not an anchor at all (it can be removed and would change nothing), because this 2 regex are quasi equivalent:last help:
then also this regex is vulnerable?
sorry ... I'm not familiar with the regex
Last edit: selena 2021-02-10
Fewer than that from django (since the host takes place before any foreign input), but yes, it is.
Because 301/400/404 could be theoretically everywhere in string (part of URI, agent etc), so a false positive for legitimate requests would be possible. To avoid that it must have no catch-all before response code, for instance like this:
And you don't need 3 RE's here (just enclose deviating parts into
(?: ... ), separated by|).Last edit: Serg G. Brester 2021-02-10
Thanks so much.
I didn't want to study the regex in depth.
Good life.