Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE]: Maintain use of [INIT] defaults for jails using multiple actions. #3531

Open
coanghel opened this issue Jun 19, 2023 · 6 comments
Open

Comments

@coanghel
Copy link

coanghel commented Jun 19, 2023

Feature request type

Have Fail2Ban use the defaults specified in [INIT] of the action (both for defaults and custom actions) when configuring a jail using multiple actions.

Description

When there are multiple actions, such as:

action: iptables
    cloudflare

You need to further specify all required parameters, even if they are set in the an action.d/*.local file, i.e.

action: iptables[name=npm-docker,port=https, protocol=tcp, chain=DOCKER-USER]
    cloudflare[cfuser=<email>, cftoken=<token>, chain=DOCKER-USER]

This appears to be the case even if "port" and "chain" are specified in the jail.local on other lines or if cfuser and cftoken are specified in the cloudflare.local

@sebres
Copy link
Contributor

sebres commented Jun 19, 2023

I don't understand the RFE.

If for example there is a action.d/cloudflare.local with:

[Init]
cftoken = abcdefgh
cfuser = test

it will overwrite both init parameters from:

cftoken =
cfuser =

so if jail.local specify:

action = %(action_)s
        cloudflare

the action cloudflare gets both parameters cftoken and cfuser from action.d/cloudflare.local.
If they also get supplied in jail.local like

action_cf_mwl = cloudflare[cfuser="%(cfemail)s", cftoken="%(cfapikey)s"]

then both parameters get overwritten from jail.local.

So please describe more precisely what is basically the goal of this RFE?

@hitesh-pathak
Copy link

hitesh-pathak commented Feb 8, 2024

I have a related question, if I want to define a custom action that inherits from iptables-multiport.conf

Let's say iptables-custom.local, then how can I inherit [INIT] variables from iptables-multiport.conf like chain, port, ...

Will adding a line like before = iptables-multiport.conf work?

Also is it possible to inherit [Definition] variables like actionstart / actionstop ?

This will be very useful, because in my case I want the same actionstart / actionstop but want to override actionban and actionunban.

@sebres
Copy link
Contributor

sebres commented Feb 8, 2024

Let's say iptables-custom.local, then how can I inherit [INIT] variables from iptables-multiport.conf like chain, port, ...
Take a look at some action using includes, for instance:

[INCLUDES]
before = iptables.conf
[Definition]
type = multiport

Thus either:

iptables-custom.local:

[INCLUDES]
before = iptables-multiport.conf

# your own custom definitions in related sections

Or much simpler, make a iptables-multiport.local, without any additional include, only with your custom definitions that would overwrite all the iptables-multiport.conf parameters.

However normally one doesn't need to get parameters like port that are supposed to be set from jail.

Also is it possible to inherit [Definition] variables like actionstart / actionstop ?

Yes, it happens automatically with both variants, but better and sane using iptables-multiport.local.

This will be very useful, because in my case I want the same actionstart / actionstop but want to override actionban and actionunban.

Then create iptables-multiport.local and specify there own actionban and actionunban in Definition section.

This RFE seems to be about completely different thing and seeks for possibility to supply parameters to action(s) without to specify them in action declaration (comma separated within square brackets).

@coanghel
Copy link
Author

coanghel commented Feb 8, 2024

Sorry @sebres, I entirely missed the notification for your more info.

I have an /action.d/cloudflare-apiv4.conf which includes

[Init]
name = npm-docker
cfuser = <MY USERNAME>
cftoken = <MY TOKEN>

I then had an jail.d/npm-docker.local which includes

[npm-docker]
action = iptables[actname=HTTP, name=npm-docker, port=http, protocol=tcp, chain=DOCKER-USER]
         iptables[actname=HTTPS, name=npm-docker, port=https, protocol=tcp, chain=DOCKER-USER]
         cloudflare-apiv4[chain=DOCKER-USER]

But this did not work and I had to change to using

[npm-docker]
action = iptables[actname=HTTP, name=npm-docker, port=http, protocol=tcp, chain=DOCKER-USER]
         iptables[actname=HTTPS, name=npm-docker, port=https, protocol=tcp, chain=DOCKER-USER]
         cloudflare-apiv4[cfuser=<MY USERNAME>,cftoken=<MY TOKEN>, chain=DOCKER-USER]

This might be intended functionality, it just felt unintuitive to me when I originally opened the issue.

@sebres
Copy link
Contributor

sebres commented Feb 8, 2024

This might be intended functionality

Yes this is intended.
The reason for that - is the difficulty and/or possible conflicts by parameters of jails, filters and actions.

The settings will be loaded using following scenario:

  • f2b loads and interpolates jail.conf (+ overrides: jail.local and those includes) but only for enabled params
  • for all enabled jails it will then interpolate jail.conf (+ overrides) in order to obtain filter as well as actions related stuff, thereby per jail it will:
    • load filter.d/<filter>.conf on demand (+ its overrides inclusive those includes)
    • supply parameters specified in square brackets and interpolate the filter config to obtain filter related jail parameters, e. g. datepattern, prefregex, failregex, etc
    • set them in jail
    • for every action:
      • load action.d/<action>.conf on demand (+ its overrides inclusive those includes)
      • supply action parameters specified in square brackets and interpolate the action config to obtain action related parameters, e. g. actionstart, actionstop, actionban, etc.
      • add every action of jail with interpolated action config to the jail.
    • overwrite in jail specified filter related parameters like datepattern, prefregex, failregex, etc

Thereby the interpolation (of %(param)s and <param>) inside the action configs happens on demand, may be recursively and can affect and be affected by other parameters specified in action, its overrides and includes of action or its overrides. Additionally it must consider %(known/param)s and <known/param> as well as %(section/param)s and <section/param> correctly (related to load sequence of config-files).

Supplying of ALL parameters, that jail config has, as requested is too heavy and can seriously slowdown the init process as well as may conflict with some parameter in action or some of its include.
Supplying of parameters, that are specified in Init section of action only, could be indeed the outcome, however it is not so simple (would probably expect deeper integration in interpolation mechanisms of pythons config-reader module), can change the default substitution behavior, but also this parameters may introduce conflicts (however with reduced possibility). Additionally it may be not so simple if some of the parameters that must be supplied, so it is in Init section, contains a substitution to another one, which is not in Init section of action, so it must be interpolated earlier.

With other words it is really complex stuff.

it just felt unintuitive to me when I originally opened the issue.

Agree, but due to above-mentioned difficulty as well as possible parameter conflict it is hardly possible or rather may be too dangerous.

Although it is not necessary to specify action in every jail - you can set it (as well as predefine own action-declarations) in default section.

Also note the declarion for action_ :

action_ = %(banaction)s[port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]

Here is an example:

[DEFAULT]
my_cf = cloudflare-apiv4[cfuser="MY-USERNAME", cftoken="MY-TOKEN", chain=<chain>]
action = %(action_)s
         %(my_cf)s
banaction = iptables[type=multiport]
banaction_allports = iptables[type=allports]

[npm-docker]
port = http,https
chain = DOCKER-USER
enabled = true

[other-jail-wo-cf]
port = 1234
chain = MY-CHAIN
protocol = all
# single port ban-action:
banaction = iptables[type=oneport]
# no cloudflare needed here:
action = %(action_)s
enabled = true

[other-jail-cf-only]
chain = CF-SOME-SERVICE
# only cloudflare needed here:
action = %(my_cf)s
enabled = true

All parameters looking like %(port)s or <port> specified in square brackets of action will be substituted using port of corresponding jail.
Also you don't need to specify 2 iptables actions for 2 ports (iptables is multi-port capable action, so you could set 2 ports in parameter port).

@sebres sebres removed the moreinfo label Feb 8, 2024
@coanghel
Copy link
Author

coanghel commented Feb 8, 2024

Thank you! That explanation clarifies why the cf token and user need to be specified in the jail, not necessarily the action's INIT.

I agree this is much more complex than I initially perceived, and most definitely not truly an enhancement to the current process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants