Crowdsec not banning

peter1 · March 24, 2024, 5:43pm

I sent 30 failed login attempts through a vpn to cluster-admin, and 15 failed dovecot authentications within a few minutes without ban. What are some things I can do to test further and fix this?

OS Rocky 9

davidep · March 24, 2024, 6:03pm

There’s a bug filed here

github.com/NethServer/dev

Crowdsec SYSLOG_IDENTIFIER is blind

opened 11:49AM - 18 Mar 24 UTC

stephdl

bug testing

**Steps to reproduce** - Install crowdsec - check the log you can see some …journald filtering ``` time="18-03-2024 11:33:58" level=info msg="Running journalctl command: /usr/bin/journalctl [journalctl --follow -n 0 SYSLOG_IDENTIFIER=dokuwiki2]" src="journalctl-SYSLOG_IDENTIFIER=dokuwiki2" type=journalctl ``` and for services ``` time="18-03-2024 11:33:58" level=info msg="Running journalctl command: /usr/bin/journalctl [journalctl --follow -n 0 _SYSTEMD_UNIT=sshd.service]" src="journalctl-_SYSTEMD_UNIT=sshd.service" type=journalctl ``` **Expected behavior** I expect that crowdsec is able to read log from journald **Actual behavior** In fact `SYSLOG_IDENTIFIER` is no more used ``` [root@R4-pve ~]# journalctl SYSLOG_IDENTIFIER=mail1 -- No entries -- [root@R4-pve ~]# ``` this drives that crowdsec is fully blind we could uses the UID instead `journalctl _UID=$(id -u mail1)` **Components** ghcr.io/nethserver/crowdsec:1.0.6 **See also** https://mattermost.nethesis.it/nethesis/pl/pgogitpypfb57kyn5p56w13asc ---- thank davidep

stephdl · March 25, 2024, 10:32am

hello @peter1

Maybe you could help the NS8 development by performing a QA

to install it on a VM, enable the testing repo, or update the module

api-cli run update-module --data '{"module_url":"ghcr.io/nethserver/crowdsec:1.0.7-dev.1","instances":["crowdsec1"],"force":true}'

stephdl · March 25, 2024, 10:33am

if you agreed I can give some guidances on what to test

mrmarkuz · March 25, 2024, 3:20pm

Tested the crowdsec upgrade to 1.7.0-dev.1 and ssh bruteforce gets banned now and it’s all viewable in the crowdsec web app.

stephdl · March 25, 2024, 3:54pm

Can you follow the other QA please

github.com/NethServer/dev

Crowdsec: ipset rules does not survive a firewalld reload

opened 04:54PM - 19 Mar 24 UTC

stephdl

bug testing

**Steps to reproduce** - Install crowdsec - once installed check if the ipv4…/ipv6 sets of ipset are in iptables ``` [root@R1-pve ~]# ip6tables -L Chain INPUT (policy ACCEPT) target prot opt source destination DROP all anywhere anywhere match-set crowdsec6-blacklists src Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ``` ``` [root@R1-pve ~]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- anywhere anywhere match-set crowdsec-blacklists src Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ``` reload the firewall like agent.add_public_service after it has added opened services firewall-cmd --reload **Expected behavior** I expect that my sets are loaded **Actual behavior** The sets are not loaded anymore and obviously crwdsec can ban, the drop is not honored ``` [root@R1-pve ~]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ``` ``` [root@R1-pve ~]# ip6tables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ``` however if I restart crowdsec-firewall-bouncer.service the sets are back `systemctl restart crowdsec-firewall-bouncer.service` I tried to make permanent the set to the drop zone of firewalld or with also a rich-rule of the public zone but we face to a strange behavior with two kinds of sets, crowdset wants to use the set that you can see with `ipset -L -n` and since I want to make `permanent` the set to firewalld, it looks like there is a conflict **Components** crowdsec 1.0.6

stephdl · March 26, 2024, 11:42am

thanks a lot @mrmarkuz

stephdl · March 29, 2024, 4:16pm

One step more in the world of container, now the bouncer itself is a container, no more deb or rpm installed on the host

github.com/NethServer/dev

Crowdsec ipset rules do not survive a firewalld reload

opened 04:54PM - 19 Mar 24 UTC

stephdl

bug testing

**Steps to reproduce** - Install crowdsec - once installed check if the ipv4…/ipv6 sets of ipset are in iptables ``` [root@R1-pve ~]# ip6tables -L Chain INPUT (policy ACCEPT) target prot opt source destination DROP all anywhere anywhere match-set crowdsec6-blacklists src Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ``` ``` [root@R1-pve ~]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- anywhere anywhere match-set crowdsec-blacklists src Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ``` reload the firewall like agent.add_public_service after it has added opened services firewall-cmd --reload **Expected behavior** I expect that my sets are loaded **Actual behavior** The sets are not loaded anymore and obviously crwdsec can ban, the drop is not honored ``` [root@R1-pve ~]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ``` ``` [root@R1-pve ~]# ip6tables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ``` however if I restart crowdsec-firewall-bouncer.service the sets are back `systemctl restart crowdsec-firewall-bouncer.service` I tried to make permanent the set to the drop zone of firewalld or with also a rich-rule of the public zone but we face to a strange behavior with two kinds of sets, crowdset wants to use the set that you can see with `ipset -L -n` and since I want to make `permanent` the set to firewalld, it looks like there is a conflict **Components** crowdsec 1.0.6

Please some braves to break it

mrmarkuz · March 29, 2024, 11:31pm

I did an update on 2 nodes of a Debian NS8 cluster and it’s just working and banning IPs as expected.