ip triggering multiple scenarios with different type (ban, captcha, customtype) only see last alert type in blocklist map

[aderumier]

Hi,

Today, I had an attack from an ip triggering multiple scenarios.

Currently, I have some custom profiles, for some scenario (mainly http scan) , to use use "ban" type, but a custom "logononly" type

filters:
 - Alert.Remediation == true && Alert.GetScope() == "Ip" && Alert.GetScenario() in ["crowdsecurity/http-crawl-non_statics", "crowdsecurity/http-probing"]
decisions:
 - type: logonly
   duration: 4h

Like it, I'm able to manually analyse this attack (as I can have false positive), and manually block the ip.

The problem, is that the blacklist sync only see last alert type.

So, the ip was triggering logonly,ban,longonly,ban,.....

#  echo "show map /var/lib/crowdsec/lua/haproxy/community_blocklist.map" | socat unix-connect:/var/run/haproxy.socket stdio |grep 103.123.169.94
0x7f9830cb1570 103.123.169.94 ban
~#  echo "show map /var/lib/crowdsec/lua/haproxy/community_blocklist.map" | socat unix-connect:/var/run/haproxy.socket stdio |grep 103.123.169.94
0x7f9830cb1570 103.123.169.94 ban
#  echo "show map /var/lib/crowdsec/lua/haproxy/community_blocklist.map" | socat unix-connect:/var/run/haproxy.socket stdio |grep 103.123.169.94
0x7f9830cb1570 103.123.169.94 logonly
#  echo "show map /var/lib/crowdsec/lua/haproxy/community_blocklist.map" | socat unix-connect:/var/run/haproxy.socket stdio |grep 103.123.169.94
0x7f9830cb1570 103.123.169.94 logonly
#  echo "show map /var/lib/crowdsec/lua/haproxy/community_blocklist.map" | socat unix-connect:/var/run/haproxy.socket stdio |grep 103.123.169.94
0x7f9830cb1570 103.123.169.94 ban

and it's wasn't correctly blocked.

Is is possible to sync only some specific "type" in the haproxy map ?
Or Configure some kind of type priority ? (I an ip is already ban, it shouldn't be overrided with captcha for example)

[aderumier]

maybe for my usecase, can I simply use

BOUNCING_ON_TYPE=ban

? (currently it's BOUNCING_ON_TYPE=all)

I'm not sure about the case where you want to use ban && captha at the same time, I think I'll trigger the same flapping problem. (I have looked at the lua code, the api call on decision take the last decision type, and replace it the haproxy map). Maybe for this specific case, if we se a "captha" type in decilist, but that ip is already in haproxy map with a "ban" decision, we shouldn't override it.

[LaurenceJJones]

Yes, however, take note if the bouncer support a FALLBACK_REMEDIATION=ban type also if you change it to none or something the bouncer doesnt know it should not do any fallback

Edit: Also to note, Does you profiles.yaml entry have a on_success: break line if not it will fall downwards into the next scope