Documentation of filter flags in regex patterns in filter.conf/ directory

[remd]

Hello, is the purpose of the filter flags present in the /etc/fail2ban/filter.conf/ files documented somewhere? I am referring to these flags:

F-MLFID
F-MLFFORGET
F-NOFAIL
F-USER

In /etc/fail2ban/jail.conf the following section appears:

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode   = normal

So I looked at /etc/fail2ban/filter.conf/sshd.conf to try and understand what the difference between the different modes for the sshd jail are. The flags inside of the regex patterns makes it very unclear what will happen for preauth failures like the following:

Aug 29 13:55:05 knox sshd[794]: Connection closed by 92.222.1.40 port 58920 [preauth]
Aug 29 13:55:07 knox sshd[827]: Connection closed by 112.65.170.186 port 49833 [preauth]
Aug 29 13:58:53 knox sshd[3775]: Connection closed by 112.65.170.186 port 38428 [preauth]
Aug 29 14:00:06 knox sshd[4714]: Connection closed by 92.222.1.40 port 36348 [preauth]
Aug 29 14:02:40 knox sshd[6669]: Connection closed by 112.65.170.186 port 55252 [preauth]

In looking at /usr/lib/python3/dist-packages/fail2ban/tests/files/logs/sshd I got even more confused. It looks like the test cases seem contradict one another, but I am likely misinterpreting them.

# failJSON: { "match": false, "desc": "Should be forgotten by success/accepted public key" }
Nov 28 09:16:03 srv sshd[32307]: Connection closed by 192.0.2.1 [preauth]
# failJSON: { "time": "2004-11-28T09:16:05", "match": true , "host": "192.0.2.111", "desc": "Should catch failure - no success/no accepted public key" }
Nov 28 09:16:05 srv sshd[32310]: Connection closed by 192.0.2.111 [preauth]

Which one is true? Should this kind of message result in a Found match? What mode do I need to set my sshd jail to in order to ban these preauth attempts?

Thank you.

[sebres]

I am referring to these flags...

Some of this tags are used to implement new single line processing of multi-line handling in the filter (to replace old behavior with scanning using buffer containing multi-lines), see #1698, #2239, #2090 etc for more info.

• F-MLFID used to identify resp. store failure info for groups of log-lines with the same identifier (e. g. combined failure-info for the same conn-id by <F-MLFID>(?:conn-id)</F-MLFID>
  Shortly messages of same session (connection) will have some common prefix/value, which even identifying this connection (have same F-MLFID value across several messages).
  All message will be grouped by this value in order to find messages with IP/ID (but e. g. are not the failures) and assign it to message without IP/ID (that are failures).
• F-NOFAIL is helper identifies a message which is not a failure itself (if captured value not empty) but contains an identifier for ticket (message with IP).
• F-MLFFORGET says that this is last message of the connection (e. g. closed) so all cached data of possible failures (grouped by F-MLFID) but without an identifier (like IP) can be removed.
• F-MLFGAINED signals the success case like authorized or session established (mostly like F-NOFAIL, reserved for future purposes, see auth.log error messages not captured in fail2ban sshd.conf #2239)
• F-USER is a tag to capture user name from the message:
  • this is stored in the ticket (and database)
  • this allows better handling of multiple attempts (failures for different user-names recognized immediately), in order to recognize attempts of some (legitimate) user trying to brute-force another accounts (see sshd, multi-line failures, alternate groups capture, etc. #2090);
  • this can be usable in action (even via tag <F-USER>) to provide a user name that was used in last attempt.

In looking at /usr/lib/python3/dist-packages/fail2ban/tests/files/logs/sshd I got even more confused. It looks like the test cases seem contradict one another

Firstly, tests like tests/files/logs/sshd can have a kind of "sections" (e. g. filterOptions), so json tags allowing conditional evaluation of following tests (all tests "enclosed" in such sections).

So this one means that following tests (unless new section follow) will be executed two times, once without any options (default filter settings) and once with mode=aggressive (even to cover the rules for all modes):

fail2ban/fail2ban/tests/files/logs/sshd

Line 1 in a395361

# filterOptions: [{}, {"mode": "aggressive"}]

This one means that following tests running with modes ddos and aggressive only (so are not affecting in mode normal):

fail2ban/fail2ban/tests/files/logs/sshd

Line 263 in a395361

# filterOptions: [{"mode": "ddos"}, {"mode": "aggressive"}]

So some rules are using only if certain mode is selected in filter/jail.

Which one is true?
Should this kind of message result in a Found match?

Both are true.
It depends on the mode used to capture that (because there are 2 rules for that):

• in normal or extra it is rather a helper only (<F-NOFAIL>):
  

  fail2ban/config/filter.d/sshd.conf

  Line 60 in a395361

  ^<F-NOFAIL>Connection <F-MLFFORGET>closed</F-MLFFORGET></F-NOFAIL> by%(__authng_user)s <HOST><mdrp-<mode>-suff-onclosed>

• in mode ddos or aggressive there is also another rule matching this message but as failure, but would match only in case [preauth] is found at end of message:
  

  fail2ban/config/filter.d/sshd.conf

  Line 70 in a395361

  ^Connection <F-MLFFORGET>closed</F-MLFFORGET> by%(__authng_user)s <HOST>%(__on_port_opt)s\s+\[preauth\]\s*$

And if another scenario occurs: if some previous failure message was found (but for example it does not contain an IP), then also by <F-NOFAIL> marked rule (in multi-line filters) a Found can be produced indirectly by capturing of this line, because this helper is using to find IP, so this previous failure message without IP can be identified now, so an IP is regarded as producing a new failure (and this way it can indeed generate or extend a ticket with +1 attempt).

[remd]

Thank you very much for your reply. That information is very helpful.

I think I am still doing something wrong, though. I want fail2ban to ban the IPs associated with these preauth failures:

Aug 30 10:23:24 knox sshd[7065]: Connection closed by 92.222.1.40 port 54784 [preauth]
Aug 30 10:28:28 knox sshd[10870]: Connection closed by 92.222.1.40 port 60472 [preauth]

I have set my sshd jail to aggressive mode and still these are not banned:

In /etc/fail2ban/jail.local:

[DEFAULT]
bantime = 1d
findtime = 2h
maxretry = 3

[sshd]
enabled = true
mode = aggressive

fail2ban-client -d output:

['set', 'syslogsocket', 'auto']
['set', 'loglevel', 'INFO']
['set', 'logtarget', '/var/log/fail2ban.log']
['set', 'dbfile', '/var/lib/fail2ban/fail2ban.sqlite3']
['set', 'dbpurgeage', '1d']
['add', 'sshd', 'auto']
['set', 'sshd', 'maxlines', 1]
['set', 'sshd', 'prefregex', '^<F-MLFID>(?:\\[\\])?\\s*(?:<[^.]+\\.[^.]+>\\s+)?(?:\\S+\\s+)?(?:kernel: \\[ *\\d+\\.\\d+\\]\\s+)?(?:@vserver_\\S+\\s+)?(?:(?:(?:\\[\\d+\\])?:\\s+[\\[\\(]?sshd(?:\\(\\S+\\))?[\\]\\)]?:?|[\\[\\(]?sshd(?:\\(\\S+\\))?[\\]\\)]?:?(?:\\[\\d+\\])?:?)\\s+)?(?:\\[ID \\d+ \\S+\\]\\s+)?</F-MLFID>(?:(?:error|fatal): (?:PAM: )?)?<F-CONTENT>.+</F-CONTENT>$']
['multi-set', 'sshd', 'addfailregex', ['^[aA]uthentication (?:failure|error|failed) for <F-USER>.*</F-USER> from <HOST>( via \\S+)?\\s*(?: \\[preauth\\])?\\s*$', '^User not known to the underlying authentication module for <F-USER>.*</F-USER> from <HOST>\\s*(?: \\[preauth\\])?\\s*$', '^Failed \\S+ for invalid user <F-USER>(?P<cond_user>\\S+)|(?:(?! from ).)*?</F-USER> from <HOST>(?: port \\d+)?(?: on \\S+(?: port \\d+)?)?(?: ssh\\d*)?(?(cond_user): |(?:(?:(?! from ).)*)$)', '^Failed \\b(?!publickey)\\S+ for (?P<cond_inv>invalid user )?<F-USER>(?P<cond_user>\\S+)|(?(cond_inv)(?:(?! from ).)*?|[^:]+)</F-USER> from <HOST>(?: port \\d+)?(?: on \\S+(?: port \\d+)?)?(?: ssh\\d*)?(?(cond_user): |(?:(?:(?! from ).)*)$)', '^<F-USER>ROOT</F-USER> LOGIN REFUSED.* FROM <HOST>\\s*(?: \\[preauth\\])?\\s*$', '^[iI](?:llegal|nvalid) user <F-USER>.*?</F-USER> from <HOST>(?: port \\d+)?(?: on \\S+(?: port \\d+)?)?\\s*$', '^User <F-USER>.+</F-USER> from <HOST> not allowed because not listed in AllowUsers\\s*(?: \\[preauth\\])?\\s*$', '^User <F-USER>.+</F-USER> from <HOST> not allowed because listed in DenyUsers\\s*(?: \\[preauth\\])?\\s*$', '^User <F-USER>.+</F-USER> from <HOST> not allowed because not in any group\\s*(?: \\[preauth\\])?\\s*$', '^refused connect from \\S+ \\(<HOST>\\)\\s*(?: \\[preauth\\])?\\s*$', '^Received <F-MLFFORGET>disconnect</F-MLFFORGET> from <HOST>(?: port \\d+)?(?: on \\S+(?: port \\d+)?)?:\\s*3: .*: Auth fail(?: \\[preauth\\])?\\s*$', '^User <F-USER>.+</F-USER> from <HOST> not allowed because a group is listed in DenyGroups\\s*(?: \\[preauth\\])?\\s*$', "^User <F-USER>.+</F-USER> from <HOST> not allowed because none of user's groups are listed in AllowGroups\\s*(?: \\[preauth\\])?\\s*$", '^pam_unix\\(sshd:auth\\):\\s+authentication failure;\\s*logname=\\S*\\s*uid=\\d*\\s*euid=\\d*\\s*tty=\\S*\\s*ruser=<F-USER>\\S*</F-USER>\\s*rhost=<HOST>\\s.*(?: \\[preauth\\])?\\s*$', '^(error: )?maximum authentication attempts exceeded for <F-USER>.*</F-USER> from <HOST>(?: port \\d+)?(?: on \\S+(?: port \\d+)?)?(?: ssh\\d*)?(?: \\[preauth\\])?\\s*$', '^User <F-USER>.+</F-USER> not allowed because account is locked(?: \\[preauth\\])?\\s*', '^<F-MLFFORGET>Disconnecting</F-MLFFORGET>: Too many authentication failures(?: for <F-USER>.+?</F-USER>)?(?: \\[preauth\\])?\\s*', '^<F-NOFAIL>Received <F-MLFFORGET>disconnect</F-MLFFORGET></F-NOFAIL> from <HOST>: 11:', '^<F-NOFAIL>Connection <F-MLFFORGET>closed</F-MLFFORGET></F-NOFAIL> by <HOST>(?: \\[preauth\\])?\\s*$', '^<F-MLFFORGET><F-NOFAIL>Accepted publickey</F-NOFAIL></F-MLFFORGET> for \\S+ from <HOST>(?:\\s|$)', '^Did not receive identification string from <HOST>(?: \\[preauth\\])?\\s*$', '^Connection <F-MLFFORGET>reset</F-MLFFORGET> by <HOST>(?: port \\d+)?(?: on \\S+(?: port \\d+)?)?(?: \\[preauth\\])?\\s*', '^<F-NOFAIL>SSH: Server;Ltype:</F-NOFAIL> (?:Authname|Version|Kex);Remote: <HOST>-\\d+;[A-Z]\\w+:', '^Read from socket failed: Connection <F-MLFFORGET>reset</F-MLFFORGET> by peer(?: \\[preauth\\])?\\s*', '^Received <F-MLFFORGET>disconnect</F-MLFFORGET> from <HOST>(?: port \\d+)?(?: on \\S+(?: port \\d+)?)?:\\s*14: No supported authentication methods available(?: \\[preauth\\])?\\s*$', '^Unable to negotiate with <HOST>(?: port \\d+)?(?: on \\S+(?: port \\d+)?)?: no matching (?:(?:\\w+ (?!found\\b)){0,2}\\w+) found.', '^Unable to negotiate a (?:(?:\\w+ (?!found\\b)){0,2}\\w+)(?: \\[preauth\\])?\\s*$', '^no matching (?:(?:\\w+ (?!found\\b)){0,2}\\w+) found:', '^<F-NOFAIL>Connection from</F-NOFAIL> <HOST>']]
['set', 'sshd', 'datepattern', '{^LN-BEG}']
['set', 'sshd', 'addjournalmatch', '_SYSTEMD_UNIT=sshd.service', '+', '_COMM=sshd']
['set', 'sshd', 'addlogpath', '/var/log/auth.log', 'head']
['set', 'sshd', 'logencoding', 'auto']
['set', 'sshd', 'maxretry', 3]
['set', 'sshd', 'findtime', '2h']
['set', 'sshd', 'bantime', '1d']
['set', 'sshd', 'usedns', 'warn']
['set', 'sshd', 'ignorecommand', '']
['set', 'sshd', 'addignoreip', '::1']
...
['set', 'sshd', 'addaction', 'iptables-multiport']
['multi-set', 'sshd', 'action', 'iptables-multiport', [['actionstart', '<iptables> -N f2b-sshd\n<iptables> -A f2b-sshd -j RETURN\n<iptables> -I INPUT -p tcp -m multiport --dports ssh -j f2b-sshd'], ['actionstop', '<iptables> -D INPUT -p tcp -m multiport --dports ssh -j f2b-sshd\n<iptables> -F f2b-sshd\n<iptables> -X f2b-sshd'], ['actionflush', '<iptables> -F f2b-sshd'], ['actioncheck', "<iptables> -n -L INPUT | grep -q 'f2b-sshd[ \\t]'"], ['actionban', '<iptables> -I f2b-sshd 1 -s <ip> -j <blocktype>'], ['actionunban', '<iptables> -D f2b-sshd -s <ip> -j <blocktype>'], ['name', 'sshd'], ['bantime', '1d'], ['port', 'ssh'], ['protocol', 'tcp'], ['chain', '<known/chain>'], ['actname', 'iptables-multiport'], ['blocktype', 'REJECT --reject-with icmp-port-unreachable'], ['returntype', 'RETURN'], ['lockingopt', '-w'], ['iptables', 'iptables <lockingopt>'], ['blocktype?family=inet6', 'REJECT --reject-with icmp6-port-unreachable'], ['iptables?family=inet6', 'ip6tables <lockingopt>']]]
['start', 'sshd']

In /var/log/fail2ban.log:

2019-08-30 10:19:14,600 fail2ban.server         [1440]: INFO    Reload all jails
2019-08-30 10:19:14,601 fail2ban.server         [1440]: INFO    Reload jail 'sshd'
2019-08-30 10:19:14,601 fail2ban.filter         [1440]: INFO      maxLines: 1
2019-08-30 10:19:14,602 fail2ban.server         [1440]: INFO    Jail sshd is not a JournalFilter instance
2019-08-30 10:19:14,602 fail2ban.filter         [1440]: INFO      encoding: UTF-8
2019-08-30 10:19:14,602 fail2ban.filter         [1440]: INFO      maxRetry: 3
2019-08-30 10:19:14,602 fail2ban.filter         [1440]: INFO      findtime: 7200
2019-08-30 10:19:14,603 fail2ban.actions        [1440]: INFO      banTime: 86400
2019-08-30 10:19:14,603 fail2ban.server         [1440]: INFO    Jail 'sshd' reloaded
2019-08-30 10:19:14,603 fail2ban.server         [1440]: INFO    Reload finished.

No more messages follow after, so I do not think that the preauth connections are being marked as failures by fail2ban.

Any guidance you can provide would be most appreciated:

[sebres]

I do not think that the preauth connections are being marked as failures by fail2ban.
Any guidance you can provide would be most appreciated:

1. Check your fail2ban version (I guess 0.10 but which exactly) or your filter.
   I assume this is outdated, because your dump shows no port before \[preauth\] and newer version looks totally different (there are 2 rules in aggressive mode), here it's interpolated (as diff, red is yours green is latest version):

-^<F-NOFAIL>Connection <F-MLFFORGET>closed</F-MLFFORGET></F-NOFAIL> by <HOST>(?: \[preauth\])?\s*$
+^<F-NOFAIL>Connection <F-MLFFORGET>closed</F-MLFFORGET></F-NOFAIL> by(?: authenticating user <F-USER>\S+|.+?</F-USER>)? <HOST>(?: (?:port \d+|on \S+)){0,2}\s*$
+^Connection <F-MLFFORGET>closed</F-MLFFORGET> by(?: authenticating user <F-USER>\S+|.+?</F-USER>)? <HOST>(?: (?:port \d+|on \S+)){0,2}\s+\[preauth\]\s*$

2. You can also test your filter using this (without reload or check fail2ban.log):

# verbose (see all regexp with matches):
fail2ban-regex -vv /path/to/excerpt/or/log 'sshd[mode=aggressive]'
# or even grep by "closed":
fail2ban-regex -vv /path/to/excerpt/or/log 'sshd[mode=aggressive]' | grep closed

Anyway testing on your excerpt with the current version I got this:

...
Failregex: 2 total
|-  #) [# of hits] regular expression
| ...
|  25) [2] ^Connection <F-MLFFORGET>closed</F-MLFFORGET> by(?: authenticating user <F-USER>\S+|.+?</F-USER>)? <HOST>(?: (?:port \d+|on \S+)){0,2}\s+\[preauth\]\s*$
|      92.222.1.40  Fri Aug 30 10:23:24 2019
|      92.222.1.40  Fri Aug 30 10:28:28 2019
...
Lines: 2 lines, 0 ignored, 2 matched, 0 missed

[remd]

$ fail2ban-client --version
Fail2Ban v0.10.2

Copyright (c) 2004-2008 Cyril Jaquier, 2008- Fail2Ban Contributors
Copyright of modifications held by their respective authors.
Licensed under the GNU General Public License v2 (GPL).

Looking at the release changelogs it looks like I need to be on 0.10.3 or later?

ver. 0.10.3 (2018/04/04) - the-time-is-always-right-to-do-what-is-right
...
* `filter.d/sshd.conf`:
...
  - mode `ddos` (and `aggressive`) extended to catch `Connection closed by ... [preauth]`, so in DDOS mode
    it counts failure on closing connection within preauth-stage (gh-2085);

[sebres]

Looking at the release changelogs it looks like I need to be on 0.10.3 or later?

Sure.
You can also try to update the filter only, but I cannot promise you that this is necessarily compatible, because of many dependencies (in the code base and config includes).
And that shall work - if you append the missing regex (already substituted, like from above diff) in your sshd.local or jail.local, for example like this:

failregex = %(known/failregex)s
            ^Connection <F-MLFFORGET>closed</F-MLFFORGET> by(?: authenticating user <F-USER>\S+|.+?</F-USER>)? <HOST>(?: (?:port \d+|on \S+)){0,2}\s+\[preauth\]\s*$

Just don't forget to remove it later your version becomes updated.

[remd]

Thank you for your help. I removed the distribution installed fail2ban package and installed 0.10.4 from here. Everything worked perfectly on mode=ddos.

2019-08-30 22:32:39,692 fail2ban.filter         [9329]: INFO    [sshd] Found 92.222.1.40 - 2019-08-30
2019-08-30 22:32:39,693 fail2ban.filter         [9329]: INFO    [sshd] Found 92.222.1.40 - 2019-08-30
2019-08-30 22:32:39,884 fail2ban.actions        [9329]: NOTICE  [sshd] Ban 92.222.1.40

Thank you again for your guidance.

[hsvt]

Fail2Ban v0.10.5

fail2ban-regex -vv /var/log/secure 'sshd[mode=aggressive]' | grep 'Connection from'
| 31) [8] ^Connection from
| Feb 17 17:37:13 sshd[19615]: Connection from 10.10.8.10 port 62002 on 10.10.8.13 port 22
| Feb 17 17:40:12 sshd[19725]: Connection from 10.10.8.10 port 62004 on 10.10.8.13 port 22

/var/log/secure:

Feb 17 17:40:17 sshd[19725]: Connection from 10.10.8.10 port 62004 on 10.10.8.13 port 22
Feb 17 17:40:17 sshd[19725]: error: kex_exchange_identification: client sent invalid protocol identifier ""

and more....

I use aggressive mode, how can I block by such expressions like this?
As I understand it, they fall under F-NOFAIL, but nevertheless the bots "knock" on the port and such a log entry occurs. I turned on the versbose log for sshd.

[sebres]

Hmmm... looks like it this error https://github.com/openssh/openssh-portable/blob/415192348a5737a960f6d1b292a17b64d55b542c/kex.c#L1290 - so no SSH ident implicit after connect.
And indeed such simple port scanning was not detected (in ddos mode) yet.

Fixed now in ab3a7fc.

As long as not released (upgraded), following jail configuration could solve that for you:

[sshd]
enabled = true
mode = aggressive
failregex = %(known/failregex)s
            ^kex_exchange_identification: client sent invalid protocol identifier

[hsvt]

Sergey, thank you very much for the back reaction and response! I no longer even hoped that anyone would pay attention to this problem and I even thought that this problem had already been solved somewhere.

[hsvt]

How can I set ignoreregex for a particular jail?

[sshd]
enabled = true
port = 22
maxretry = 3
bantime = 600
findtime = 2d
banaction = nftables-multiport
action = %(action_mwl)s

[sshd-aggressive]
filter = sshd[mode=aggressive]
enabled = true
port = 22
maxretry = 1
bantime = 300
findtime = 2d
banaction = nftables-multiport
logpath = %(sshd_log)s
ignoreregex = ^Failed \b(?!publickey)\S+ for (?P<cond_inv>invalid user )?<F-USER>(?P<cond_user>\S+)|(?(cond_inv)(?:(?! from ).)*?|[^:]+)</F-USER> from <HOST>(?: (?:port \d+|on \S+)){0,2}(?: ssh\d*)?(?(cond_user): |(?:(?:(?! from ).)*)$)

I want to ignore these lines for aggressive mode, but so that everything else matches.

[sebres]

Exactly so you have set it for sshd-aggressive...
If it does not work for you, may be some interpolation does not work in jail (filter only), or your expression (you assume) is simply wrong.

Are you really understand what you're trying to ignore?
Expression \b(?!publickey) is a negative lookahead assertion, it would match all the messages excepting publickey. So if added to ignoreregex (meant negative over negative) all this will be ignored:

sshd[31602]: Failed password for invalid user ROOT from 192.0.2.1 ...
sshd[31602]: Failed password for gast from 192.0.2.1 ...
sshd[31602]: Failed keyboard-interactive for user from 192.0.2.1 ...

but for example this will be not ignored by this ignoreregex (but possibly in filter):

sshd[31603]: Failed publickey for git from 192.0.2.2 ...
sshd[31603]: Failed publickey for invalid user tester from 192.0.2.2 ...

You cannot simply negate (remove) a particular regex with negative lookahead or lookbehind via ignoreregex, because it depends.

And you could use short regex there, like:

ignoreregex = ^Failed \b(?!publickey)\S+ for\b

But better you provide an example line you want ignore.

[hsvt]

The idea is that the aggressive mode would not work on this expression, but at first the first mode would work (normal). [sshd]

Otherwise, in my example above, the [sshd] mode normal does not make sense, it is immediately blocked by an aggressive mode.

Example:

1. 1 mode captures normal mode [sshd]
2. 2 mode captures only aggressive attempts and sets for them an already tougher ban time [sshd-aggressive]

[sebres]

Otherwise, in my example above, the [sshd] mode normal does not make sense, it is immediately blocked by an aggressive mode.

You are wrong, because there are several scenarios where it absolutely makes sense, for example you can have 2 jails with different maxretry/findtime combinations:

[sshd]
mode = normal
findtime = 10m
maxretry = 3
bantime = 30m
enabled = true

[sshd-aggressive]
filter = sshd[mode=aggressive]
findtime = 20m
maxretry = 10
bantime = 5m
enabled = true

For example here jail with normal mode makes sense too, and is not immediately blocked by an aggressive mode due to different settings (it simply expects more attempts within a bit long time).

So if you really want to have both (why?), just increase maxretry in jail with aggressive mode.

2 mode captures only aggressive attempts ...

This is incorrect expectation too, because there is simply no such mode for "only aggressive attempts".

You're misinterpreting the usage of mode aggressive - it was introduced to find every attempt with a single sshd jail, so this combines all modes normal, ddos and extra.
The case is - to implement what you want, you have to create new mode combining ddos and extra only. But it is a bit complex because sshd is multiline filter (some of messages that are failures does not have IP, so it will be retrieved with other regex's that should be marked as <F-NOFAIL> perhaps). So it depends.

Although something like that could work:

[sshd-aggressive-without-normal]
filter = sshd[mode=ddos, mdre-aggressive="<mdre-ddos>
                                          <mdre-extra>"]

but it depends on internal (not public) parameters that may change in the next version so it could stop to work later. Or still worse it would work only partially (because ignoring something important).

Regarding ignore - as already said in previous comment, sometimes you cannot simply neglect some regexp's with an ignore, because they may be "half" positive (contain negative parts that would bother in negating case) or ignoring important regexp's which would be helper for other to find an IP of the session.
We should then introduce some new feature like excluderegex or disableregex for such reasons.
But I don't like both ideas (neither ignore for some positive case, nor exclude/disable regex what would make the concept still more complex as it already is).

[srulikuk]

Back to the original question, is there documentation for the various ?
I have multiple WAN IP's and would like to log the DST IP using actionban, is there a flag for this?

[sebres]

would like to log the DST IP using actionban, is there a flag for this?

What do you mean? The IP that gets banned is available in actionban via tag <ip> or also as <F-ID>.
If you mean something else as "flag", please provide a log line your fail2ban finds as failure and part you want to log from there, but...

Anyway every data enclosed in filter tag starting with F-* is saved to the ticket:

failregex = ^failure from <ADDR> for user <F-USER>\S+</F-USER>, agent: <F-AGENT>.*</F-AGENT>$

and available in action using same tag:

actionban = logger ... "banned <ip>, user: <F-USER>, aggent: <F-AGENT>"

Also see my answer to related issue - #1935 (comment)

[srulikuk]

If you mean something else as "flag", please provide a log line your fail2ban finds as failure and part you want to log from there, but...

I want to get the DST ip (i have multiple WAN ip's), from my log file the "DST=";
Mar 8 13:02:57 gateway kernel: Probe on closed port: IN=ppp0 OUT= MAC= SRC=x.x.x.x DST=x.x.x.x LEN=40 TOS=0x00 PREC=0x00 TTL=108 ID=256 PROTO=TCP SPT=37594 DPT=60001
Thanks

[sebres]

Well, as I described above change your failregex to something like this:

-failregex = ... SRC=<ADDR> DST=\S+ ...
+failregex = ... SRC=<ADDR> DST=<F-DST>\S+</F-DST> ...

and you can get it using <F-DST> in action.

[srulikuk]

So its not a set of F-FLAGS that I can use but rather I am creating them in the filter file, that's great.
Thanks