Rules for miners should not resolve the address for the miner

[fntlnz]

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.

falco/rules/falco_rules.yaml

Line 2555 in 39b5156

condition: (fd.sport="443" and fd.sip.name in (https_miner_domains))

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

{
  "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:

[fntlnz]

/area rules

[mfdii]

Thanks for digging into this.

The goal behind fd.sip.name is 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.

[leodido]

I like the solution you're proposing Michael.

I think this improvement should be scheduled for the next release. WDYT?

[mfdii]

I think there might be downstream implications to this. @Kaizhe if we make this change, do you need to do anything on your side as you're a consumer of these rules with Sysdig Secure.

[leodido]

ping @Kaizhe

[Kaizhe]

@mfdii so far no, we haven't rolled out the rule to agent yet. cc @mstemm

[sporkmonger]

Yeah, this bug just generated a bit of a confusing, but fortunately short, fire drill for us.

[fntlnz]

@sporkmonger This is keeping hitting everyone :)

Everyone, not sure what we want to do with this? Maybe worth discussing at the next office hours?

[PeteGoo]

This affected us by firing some pretty high priority AWS GuardDuty alerts for CryptoCurrency:EC2/BitcoinTool.B!DNS (docs) due to the DNS lookups.

We spent quite a bit of time tracking this down to the above change after isolating the source EC2 instance and destroying it.

[jseadragon]

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 ;)

[Kaizhe]

@jseadragon thanks for the input. I am thinking maybe we should disable this rule by default. Alternatively, the security team needs to find a way to dynamically update the cryptoming IP addresses before enable this rule.

[sporkmonger]

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.

[cameronattard]

We got hit by this today as well.

[leodido]

I propose to close this because #1061 has been merged in.

[leodido]

/close

[poiana]

@leodido: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.