crowdsecurity/cs-cloudflare-worker-bouncer

A CrowdSec Bouncer that syncs the decisions made by CrowdSec with CloudFlare's firewall using cloudflare workers. Manages multi user, multi account, multi zone setup. Supports IP, Country and AS scoped decisions.

cs-cloudflare-worker-bouncer's Issues

Bouncer gets LAPI delete decisions but doesn't actually delete them from Cloudflare

I've been running the bouncer for about a week and every ban is successfully initiated but only about 1/3 of them are actually deleted once the ban expires.

My log is filled with "Received x deleted decisions" but most are not followed up with "Deleted x decisions" account=xx

When I restart the bouncer, all the expired bans are deleted.

Any ideas? Screenshot of log below... there are no errors.

[Dependancies] node packages

We should add a dependabot configuration so we can monitor also node package.json as well as golang deps

https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file

README refers to the wrong doc

It should be : https://docs.crowdsec.net/docs/next/bouncers/cloudflare-workers

Bouncer generates/deletes workers & routes on a loop

Hi,

I am on a paid Workers plan. I followed the setup guide last night and installed the bouncer.

If I run crowdsec-cloudflare-worker-bouncer -s, it does everything correctly. I log in, my worker is there as are all my routes.

If I run systemctl start crowdsec-cloudflare-worker-bouncer, the bouncer turns on, deletes the worker and routes, creates them again, and then 10 seconds later does it all over. It's on an endless loop of creating and deleting the worker & routes.

Here's the loop from the bouncer's log — there are no errors.

time="02-05-2024 08:00:13" level=info msg="Done cleaning up existing workers" account=redacted
time="02-05-2024 07:59:48" level=info msg="Cleaning up existing workers" account=redacted
time="02-05-2024 07:59:46" level=info msg="Done creating turnstile widget" account=redacted zone=redacted
time="02-05-2024 07:59:44" level=info msg="Adding 24731 decisions" account=redacted
time="02-05-2024 07:59:44" level=info msg="Received 24731 new decisions"
time="02-05-2024 07:59:44" level=info msg="Received 3 deleted decisions"
time="02-05-2024 07:59:44" level=info msg="Done creating turnstile widget" account=redacted zone=redacted
time="02-05-2024 07:59:44" level=info msg="Creating turnstile widget" account=redacted zone=redacted
time="02-05-2024 07:59:44" level=info msg="Successfully deployed infra for all accounts"
time="02-05-2024 07:59:44" level=info msg="Successfully deployed infra for account redacted"
time="02-05-2024 07:59:44" level=info msg="Binded worker to route *redacted.com/" account=redacted zone=redacted
time="02-05-2024 07:59:40" level=info msg="Binding worker to route *redacted.com/" account=redacted zone=redacted
time="02-05-2024 07:59:38" level=info msg="Creating worker crowdsec-cloudflare-worker-bouncer" account=redacted
time="02-05-2024 07:59:37" level=info msg="Creating KVNS CROWDSECCFBOUNCERNS" account=redacted
time="02-05-2024 07:59:37" level=info msg="Done cleaning up existing workers" account=redacted
time="02-05-2024 07:59:30" level=info msg="Cleaning up existing workers" account=redacted
time="02-05-2024 07:59:29" level=info msg="Using API key auth"
time="02-05-2024 07:59:29" level=info msg="config is valid"
time="02-05-2024 07:59:29" level=info msg="Using API key auth"

Worker re-deployment at service restart causes worker settings to revert to defaults

I set up CloudFlare Logpush on the worker and was ingesting the worker logs to my local Elastic instance for statistics and log analysis. Was working great.

Restarted the system the worker was on, the worker re-deployed, CloudFlare Logpush is now disabled.

Looks like the worker re-deploys its infrastructure every time the service starts. Because of this, worker settings do not persist across service restarts.

Proposing one of the following solutions:

1. Workers only re-deploy when necessary (would have to figure out how to tell that?) and can use existing deployments, so customizations to the workers (and workers themselves?) persist across service restarts
2. Service reads existing worker settings prior to cleanup and sets them back after re-deployment
3. Service provides worker options management in config yml

I'm sure there are other ways to tackle this, these were just the first things that came to mind.

This impacted me for Logpush settings, but this probably impacts other worker settings: CPU limit, usage model, placement, etc.

Setup integration tests

The bouncer includes tests which need a real cf account. We need a separate CF account for it.

[pkg] Create a container version with CI

We can containerize this application as it simply updates a KV store, whilst polling LAPI which can be containerized.