Over the last 12 months I’ve added some “acceptable risk” IPv4 subnets to it (a bunch of our users have the ability to trigger it ‘just doing normal work’ - ie; they’re really bad at typing passwords, and they’re triggering BF scenarios on some servers)
As we move forward with all the speed of a glacier towards IPv6, I’ve noticed one IP keeps getting itself banned due to BF.
All of the IPv4 CIDRs in the whitelist page work as expected, an alert will trigger, but there will be no action.
However, none of IPv6 sections below will stop a ban from triggering:
However, the host keeps showing up in “cscli descisions list”
Am I supposed to be doing something different for IPv6? (or, is it broken?)
Now it best to understand that after you have implemented these and restarted the crowdsec service, crowdsec will not remove any active decisions if the IP has been whitelisted. You still need to remove these via cscli decisions remove command.
Now if the behaviour you are seeing is you added these and its still triggering a ban decisions then I would use cscli explain command to explain the line from the affected log source to see if it is being properly parsed and set.
So, first, cscli metrics show acquisition in 1.6.1 is awesome.
A little bit more about this setup: the ::54 device is a windows server. the logs are coming out of EventLog, so I don’t know how to plug that into an cscli explain just yet.
I am running LAPI server, which is linux, and where the whitelist yml file lives. It’s getting data from a couple of linux boxen and also a delivering decisions to a pair of opnSense machines. For IPv4 this is, and has been, working excellent for ~12 months.
Tailing the logs on the LAPI server, I do however get a small clue:
time="2024-05-22T05:44:17+10:00" level=debug msg=" [IpInRange(Alert.GetValue(), \"1.1.0.0/1\")] IpInRange(\"1.1.0.0/1\", \"2xxxxxxxx:188::54\") = " name=whitelist type=profile
[..snip..]
time="2024-05-22T05:44:17+10:00" level=debug msg=" [IpInRange(Alert.GetValue(), \"2.8.0.0/1\")] IpInRange(\"2.8.0.0/1\", \"2xxxxxxxx:188::54\") = " name=whitelist type=profile
time="2024-05-22T05:44:17+10:00" level=info msg="(6e35634ee49b46ebb5dfe7b748512dafhgXODySDE20kqwUP/crowdsec) crowdsecurity/windows-bf by ip 2xxxxxxxx:188::54 (AU/10143) : 4h ban on Ip 2xxxxxxxx:188::54"
In the list of IpInRange() calls, at no point does it check the IPv6 addresses/subnets, it just skips over them and pretends they’re not there!
What do we need to do to get the whitelist.yaml to properly whitelist IPv6 addresses/subnets?
The logs you provided are to do with a profile called whitelists not the whitelist thats in s02. Remember if you have multiple log processors then you need to provide all of them with the same whitelist if you are doing it via s02.
We don’t call any methods so you wouldnt see that debug information unless you put
I ended up finding some clues in /etc/crowdsec/profiles.yaml
Specifically, all of the actual white listing that had been setup and was taking place.
The whitelisting in originally article still does not seem to be taking place, but adding it to profiles.yaml seems to be working, and that got me going enough to forget about the problem again
