"Drop" route configuration should add FORWARD rules to block internet/routing of guest/analysis VM

[zOLakh]

Prerequisites

Please answer the following questions for yourself before submitting an issue.

• I am running the latest version
• I did read the README!
• I checked the documentation and found no answer
• I checked to make sure that this issue has not already been filed
• I'm reporting the issue to the correct repository (for multi-repository projects)
• I have read and checked all configs (with all optional parts)

Expected Behavior

When using per-analysis routing, using "drop" configuration should block internet for the guest/analysis VM. This implies blocking FORWARD/routing for the guest/analysis VM IP.

Current Behavior

When using the "drop" configuration, only OUTPUT blocking rules are created. Since no FORWARD rules are generated, the communication between CAPE (acting as the router) and the guest/analysis VM is restricted, but not for internet access.

The fix is quite easy, I could create a PR. However, am I correct here? Should another system/way handle that part of blocking internet access?

Failure Information (for bugs)

Steps to Reproduce

1. Use a "drop" route type for an analysis.
2. Internet is still accessible since no FORWARD rules are blocking the communication.

Context

• "Drop" route configuration :

  CAPEv2/lib/cuckoo/core/analysis_manager.py

  Lines 594 to 595 in 563fd24

  	elif self.route in ("none", "None", "drop"):
  	self.rooter_response = rooter("drop_enable", self.machine.ip, str(self.cfg.resultserver.port))

• Router "drop_enable" rules creation :

  CAPEv2/utils/rooter.py

  Lines 871 to 880 in 563fd24

  	def drop_enable(ipaddr, resultserver_port):
  	run_iptables(
  	"-t", "nat", "-I", "PREROUTING", "--source", ipaddr, "-p", "tcp", "--syn", "--dport", resultserver_port, "-j", "ACCEPT"
  	)
  	run_iptables("-A", "INPUT", "--destination", ipaddr, "-p", "tcp", "--dport", "8000", "-j", "ACCEPT")
  	run_iptables("-A", "INPUT", "--destination", ipaddr, "-p", "tcp", "--sport", resultserver_port, "-j", "ACCEPT")
  	run_iptables("-A", "OUTPUT", "--destination", ipaddr, "-p", "tcp", "--dport", "8000", "-j", "ACCEPT")
  	run_iptables("-A", "OUTPUT", "--destination", ipaddr, "-p", "tcp", "--sport", resultserver_port, "-j", "ACCEPT")
  	# run_iptables("-A", "OUTPUT", "--destination", ipaddr, "-j", "LOG")
  	run_iptables("-A", "OUTPUT", "--destination", ipaddr, "-j", "DROP")

Failure Logs

N.A.

[kevoreilly]

I am sure @doomedraven will provide more wisdom than I can, but it sounds like you didn't follow the documentation and set up the vm with host-only network.

It sounds counter-intuitive but this is how it should be set up so there is no Internet for the vms until the rooter component actively provides it.

[zOLakh]

Hi. Thanks for your fast response time! I'm not using host-only (I'm using Proxmox machinery), and I double-checked (manual firewall rules + tcpdump) that the guest access the internet through CAPE (which is in a container, and is the only one that can access internet in the subnet).

The issue is that the CAPE router doesn't block "routing" through FORWARD rules, and only adds OUTPUT rules, which aren't triggered, since CAPE only does routing on those communications (packets are not destined to CAPE, so only the FORWARD rules are triggered).

I don't know if I missed an option or if I'm doing something wrong. From my understanding, the CAPE router should handle the route blocking itself, but I'm sure that the guest VM access the internet through CAPE (and hence the CAPE router should block it?).

[kevoreilly]

Well that doesn't sound right to me!

[doomedraven]

hello, KVM has those rules by default, so drop works fine there and is unique hypervisor that we officially support. IF you can elaborate iptables rule and make a PR we can test if it not breaking it on our side, but we don't use/have proxmon so we can't help there

[zOLakh]

Okay, I can prepare a PR for next week. I'll be able to test the change for Proxmox. If there is any issue on KVM side, we could add an option/enable only for Proxmox machinery.

Thanks!

[doomedraven]

yep, no rush, we are on holidays anyway, so have a good weekend

[doomedraven]

any update here?