Closed arudinskis closed 11 months ago
Hi @arudinskis we have good news refactoring meaning a complete revamp in this regard is on the Falco Roadmap https://github.com/orgs/falcosecurity/projects/5. We may not be able to land it for Falco 0.36, because there are other competing priorities, but hopefully we have a better approach by Falco 0.37.
CC @loresuso
Totally agree with @incertum! Things start moving in this regard!
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
.
Mark the issue as fresh with /remove-lifecycle rotten
.
Provide feedback via https://github.com/falcosecurity/community. /close
@poiana: Closing this issue.
mine.moneropool.com
DNS A and AAAA resolve to Cloudflare IP addresses.status.dpd.lt
also resolves the same Cloudflare IP addresses and due to this ruleDetect outbound connections to common miner pool ports
is triggered false positively.It seems that Falco resolves and periodically updates crypto-miner IP addresses from DNS. When a connect syscall occurs to one of those IP addresses it fires an alert. More details: https://falco.org/docs/rules/fd-sip-name/
Would it be possible to map a crypto miner domain with corresponding IP addresses? This way there shouldn’t be any false positives. Or are there other options on how to get rid of these false positives without creating exceptions?