You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
| 5443 | Ip:::ffff:143.110.208.18 | baudneo/zoneminder_cve-2022-39290 | CA | 14061 DIGITALOCEAN-ASN | ban:1 | 2025-02-10
10:51:04.386773421 +0000 UTC |
| 5440 | Ip:::ffff:143.110.208.18 | crowdsecurity/http-crawl-non_statics | CA | 14061 DIGITALOCEAN-ASN | ban:1 | 2025-02-10
10:10:25.369058954 +0000 UTC |
| 5439 | Ip:::ffff:143.110.208.18 | baudneo/zoneminder_cve-2022-39290 | CA | 14061 DIGITALOCEAN-ASN | ban:1 | 2025-02-10
10:11:23.454881407 +0000 UTC |
| 5438 | Ip:::ffff:143.110.208.18 | crowdsecurity/apache_log4j2_cve-2021-44228 | CA | 14061 DIGITALOCEAN-ASN | ban:1 | 2025-02-10 10:11:20.807191648 +0000 UTC |
Same IPv4, but IPv6 encoded. Given that the IP should have been blocked
already with the initial entry, shouldn't the subsequent entries not
show up at all because the first entry should have created a firewall
entry which blocked the second access? This IP is listed in the IPv4
part of the pf tables:
# pfctl -t crowdsec-blocklists -T show | grep 143.110.208.18
143.110.208.18
Filter rules:
# pfctl -sr -v
No ALTQ support in kernel
ALTQ related functions disabled
scrub in all fragment reassemble
[ Evaluations: 128946919 Packets: 83108155 Bytes: 37415891319
States: 0 ]
[ Inserted: uid 0 pid 0 State Creations: 0 ]
anchor "blacklistd/*" in on igb0 all
[ Evaluations: 75632099 Packets: 0 Bytes: 0 States:
0 ]
[ Inserted: uid 0 pid 0 State Creations: 0 ]
block return in log quick on igb0 from <martians> to any
[ Evaluations: 2310856 Packets: 1815 Bytes: 362938 States:
0 ]
[ Inserted: uid 0 pid 0 State Creations: 0 ]
block return in log quick on igb0 from <martians6> to any
[ Evaluations: 2309041 Packets: 0 Bytes: 0 States:
0 ]
[ Inserted: uid 0 pid 0 State Creations: 0 ]
block return in log quick on igb0 from <bruteforce> to any
[ Evaluations: 2309041 Packets: 0 Bytes: 0 States:
0 ]
[ Inserted: uid 0 pid 0 State Creations: 0 ]
block return out log quick on igb0 from any to <martians>
[ Evaluations: 2309041 Packets: 0 Bytes: 0 States:
0 ]
[ Inserted: uid 0 pid 0 State Creations: 0 ]
block drop in quick from <crowdsec-blocklists> to any
[ Evaluations: 75630290 Packets: 255 Bytes: 12932 States:
0 ]
[ Inserted: uid 0 pid 0 State Creations: 0 ]
block drop in quick from <crowdsec6-blocklists> to any
[ Evaluations: 52655024 Packets: 0 Bytes: 0 States:
0 ]
[ Inserted: uid 0 pid 0 State Creations: 0 ]
Entries without ::ffff: seem to be blocked correctly.
Why is this not blocked and shows up multiple times?
The address shows up in the crowdsec-blocklists (= IPv4), but doesn't seem to be blocked there. What is the IP path this comes into the system? Maybe via IPv6 maybe and should be in crowsdec6-blocklists (= IPv6, not listed there)?
Is there a way to trace this IP back to a specific logfile? This could maybe allow me to trace back how this reaches the application in question.
What did you expect to happen?
Only 1 entry in the alerts, as the subsequent entries should have been blocked and as such not detected in access logs.
How can we reproduce it (as minimally and precisely as possible)?
No idea.
Anything else we need to know?
No response
Crowdsec version
This was with 1.6.4, since then I have upgraded but do not expect a change:
Check Releases to make sure your agent is on the latest version.
Details
I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.
What happened?
About those alerts:
Same IPv4, but IPv6 encoded. Given that the IP should have been blocked
already with the initial entry, shouldn't the subsequent entries not
show up at all because the first entry should have created a firewall
entry which blocked the second access? This IP is listed in the IPv4
part of the pf tables:
Filter rules:
Entries without ::ffff: seem to be blocked correctly.
The questions which come up on my side are:
What did you expect to happen?
Only 1 entry in the alerts, as the subsequent entries should have been blocked and as such not detected in access logs.
How can we reproduce it (as minimally and precisely as possible)?
No idea.
Anything else we need to know?
No response
Crowdsec version
This was with 1.6.4, since then I have upgraded but do not expect a change:
OS version
FreeBSD -current (1 month old development snapshot), amd64 architecture, PF firewall
Enabled collections and parsers
Acquisition config
On Windows:
C:> Get-Content C:\ProgramData\CrowdSec\config\acquis.yaml
paste output here
Config show
Prometheus metrics
Related custom configs versions (if applicable) : notification plugins, custom scenarios, parsers etc.
The text was updated successfully, but these errors were encountered: