CrowdSec•7mo ago

Chaining bouncer inside access_by_lua_block

Hi everyone! I'm setting up an OpenResty bouncer but I need it chain it before a different module (which is a custom DDoS protection script) so that the module that follows after the bouncer is the final one that completes the request. My access_by_lua_block is roughly as follows:

-- snip

local bouncer = require "lua/bouncer"
bouncer.bounce()

-- DDoS protection script is called here and must be called last

-- snip

local bouncer = require "lua/bouncer"
bouncer.bounce()

-- DDoS protection script is called here and must be called last

The contents of bouncer are as follows:

local function bounce() {
  local cs = require("crowdsec")
  cs.Allow(remote_addr)
}

local function bounce() {
  local cs = require("crowdsec")
  cs.Allow(remote_addr)
}

In a configuration like this, the bouncer processes the request so the visitor reaches the page without DDoS check ever being triggered. My question is -- is it possible to intercept/override the behavior of the bouncer to allow the request to continue? Thanks in advance!

3 Replies

CrowdSec•7mo ago

Important Information

Thank you for getting in touch with your support request. To expedite a swift resolution, could you kindly provide the following information? Rest assured, we will respond promptly, and we greatly appreciate your patience. While you wait, please check the links below to see if this issue has been previously addressed. If you have managed to resolve it, please use run the command /resolve or press the green resolve button below.

Log Files

If you possess any log files that you believe could be beneficial, please include them at this time. By default, CrowdSec logs to /var/log/, where you will discover a corresponding log file for each component.

Guide Followed (CrowdSec Official)

If you have diligently followed one of our guides and hit a roadblock, please share the guide with us. This will help us assess if any adjustments are necessary to assist you further.

Screenshots

Please forward any screenshots depicting errors you encounter. Your visuals will provide us with a clear view of the issues you are facing.

blotus•7mo ago

Allow will call ngx.exit to let nginx know about our decision, which will stop the processing of the block. We do have allowIp that is used internally that will return a boolean based on whether the IP should be blocked or not: you can try calling it directly but Allow also takes care of the logic for handling captcha requests + return the error page if there's a decision, so you'll need a bit more code to display the error page if there's a decision/handle the captcha/have appsec support. Keep also in mind that we do not consider the LUA api to be public, so it may change from one release to another (for example, there's this PR that will refactor a huge part of the code: https://github.com/crowdsecurity/lua-cs-bouncer/pull/80/files). That being said, I'm not against exposing a different version of Allow that would take care of everything but return a boolean instead of exiting directly (you would still need to handle this and return the error page yourself).

GitHub

Build software better, together

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

pokeghostOP•7mo ago

Interesting option, thank you!

Gaming

Programming

Chaining bouncer inside access_by_lua_block

Did you find this page helpful?