Open sl805 opened 1 year ago
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
/remove-lifecycle stale
Thank you for reporting this! we will try to improve our DNS detection soon @loresuso
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
/remove-lifecycle stale
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
/remove-lifecycle stale
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
/remove-lifecycle stale
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
/remove-lifecycle stale
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
DNS resolution false positives.
If I understood correctly, if one declares a list of DNS names, Falco will resolve them to IP addresses, to be able to track attempts to reach them. Which means every agent will generate traffic to each list element, as result each Falco agent does external requests which have to be explicitly excluded.
How to reproduce it
Create a list of malicious domain to track, as per this example: https://falco.org/docs/rules/fd-sip-name/ **Expected behaviour** Borrowed someone's idea in `#falco` slack channel: _Is it possible to use following approach ? Instead of resolving names by falco, track attempts to resolve domain mentioned in rule ? For example, if we have domains 'evil-miner.xyz', 'evil-c2c.xyz' we report process which tries to resolve evil*.xyz ip it gets in response and dns-server it tries to reach in case it's some external one. This way we have following benefits: covering variation of malicious domain-name passively getting actual ip-address malicious process gets in response to its request passively getting external dns address malware relies on, if there's any passively monitoring resolution errors as potential Ioc-s. Malware domains are often short-living DAG names so we can monitor Error: Domain does not exist, or c2c server running on compromised host not always handling load properly, which results in server error answers. This approach is less intensive, it stealth-ier and gets more potential ioc's_ I don't know if it's possible but looks promising, especially for such feature-rich and flexible tool. Best regards, sl805.