add filter to catch env lookups in nginx logs

[bensig]

Before submitting your PR, please review the following checklist:

• CHOOSE CORRECT BRANCH: if filing a bugfix/enhancement
  against certain release version, choose 0.9, 0.10 or 0.11 branch,
  for dev-edition use master branch
• CONSIDER adding a unit test if your PR resolves an issue
• LIST ISSUES this PR resolves
• MAKE SURE this PR doesn't break existing tests
• KEEP PR small so it could be easily reviewed.
• AVOID making unnecessary stylistic changes in unrelated code
• ACCOMPANY each new failregex for filter X with sample log lines
  within fail2ban/tests/files/logs/X file

[bensig]

This filter checks nginx logs for anyone searching for .env files. Simple, but powerful.

It has been massively successful in blocking scans. Banned 1000's of addresses with this filter - would be good to include in fail2ban master so others can use.

In many cases, webhackers are able to find sensitive info in these .env files that are left exposed on servers. Discovered an increase in probes for .env files and have been running this on production for about a year now.

[sebres]

Hmm...
this RE looks a bit vulnerable to me (too many catch-alls), let alone dot-char in .env matches any character, so I guess it's not really what you want. E.g. \.\w*env is better file-pattern.

[sebres]

Sorry, but I don't think we really need filter for the env-lookup only.
Maybe some generalized filter to search unexpected requests?...
Something like this:

[Definition]
_file = [^"]*
_uri = /(?:[^/]*/)*%(_file)s
_bad_req = [^"]*(?=" %(_bad_code)s)
_bad_code = 4(?:00|44)
_req = (?:%(_bad_req)s|[A-Z]+ %(_uri)s [^"]*)
_code = (?!401)[45]\d\d
failregex = ^<ADDR> - \S+ [^"]*"%(_req)s" %(_code)s\b

Pros:

• it is a good and safe generalized solution matching also bad (400) and rejected (444) requests.
• one can simply customize it to match specific uris or files, for instance:

filter = nginx-unexpected-req[_file='\.\w*env']

would match what you're suggesting here, but safe against false positives (different .env only and only for expected http-codes, e. g. like not found etc).

Just since monitoring of access-log is not recommended (see wiki :: Best practice, especially "Reduce parasitic log-traffic"), I'm unsure such general jail is good idea.
Better would be special nginx-location or conditional access-log (see the wiki), logging only failures, so the jail would monitor almost bad traffic only.