falco: Rules for miners should not resolve the address for the miner
What happened:
After starting Falco, I noticed that there was a strange DNS activity in my network towards some domains like de.minemxr.com.
Initially this issue had been reported to me by Pi-Hole
Then I dug a bit more using wireshark and noticed this was related to falco itself.
This happens because the miners rules, use the fd.sip.name filtercheck that does such resolution. See here for documentation.
What you expected to happen:
The rule works without resolving the domain name for mining pools.
How to reproduce it (as minimally and precisely as possible):
- Open wireshark or tcpdump and look at it
- Start falco
Anything else we need to know?:
While this might be technically right, it raises a warning in the eyes of any operator looking at it, in fact users already reported this kind of activity in the Falco slack, and it might seem that the machine is actually mining when it’s not.
I personally felt very bad when I saw such connections in my systems, it seemed like someone hacked my workstation.
Environment:
- Falco version (use
falco --version): 0.17.0 - System info <!-- Falco has a built-in support command you can use “falco --support | jq .system_info” -->
{
"machine": "x86_64",
"nodename": "gallifrey",
"release": "5.2.13-arch1-1-ARCH",
"sysname": "Linux",
"version": "#1 SMP PREEMPT Fri Sep 6 17:52:33 UTC 2019"
}
- Cloud provider or hardware configuration:
- OS (e.g:
cat /etc/os-release):
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="0;36"
HOME_URL="https://www.archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
LOGO=archlinux
- Kernel (e.g.
uname -a):5.2.13-arch1-1-ARCH - Install tools (e.g. in kubernetes, rpm, deb, from source): from source
- Others:
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 15
- Comments: 16 (12 by maintainers)
I think the near term fix should be to disable by default until a longer term resolution presents itself. There’s many other good ways to get alerts for this behavior. It doesn’t need to be Falco doing the alerting and if someone doesn’t have good coverage for this risk, they can still optionally turn this on. Having it on by default is much more likely to create unnecessary work than it is to reveal a breach that would otherwise go undetected.
Edit: GuardDuty in particular will happily alert hundreds of thousands of times for this.
I just encountered this today and lost part of the day looking into it only to find that it was falco doing this. The DNS traffic was flagged by my SIEM and I spent several hours tracking it down.
I like the concept of dynamically keeping the DNS names up to date so you can track malicious behavior at the IP level, but querying the DNS name inside the cluster natively is probably not the best way IMO.
Is there an external source of truth we can use here that doesn’t require a DNS lookup? Otherwise, this is almost like a security team Chaos Monkey, triggering fire drills for everyone 😉
@sporkmonger This is keeping hitting everyone 😃
Everyone, not sure what we want to do with this? Maybe worth discussing at the next office hours?
Yeah, this bug just generated a bit of a confusing, but fortunately short, fire drill for us.
Thanks for digging into this.
The goal behind
fd.sip.nameis to allow domains to be put on a allow/deny list and the end user not having to look up all the possible IPs for a domain. Also, as domain’s A records might change, an end user is constantly in a race to update rules when a new A records (IP addresses) might be added.An easy solution might be to add a macro to enable or disable this rule, with a comment above it explaining that turning this rule will cause DNS lookups to occur for these domains.