Opened 16 years ago

Last modified 15 years ago

#35 reopened defect

Set up iptables to not forward arbitrary packets to the backend

Reported by: quentin Owned by: ecprice
Priority: critical Milestone: Public Beta
Component: other Version:
Keywords: security Cc:

Description (last modified by quentin)

Currently the iptables rules don't REJECT or DROP anything; every packet a VM sends is ACCEPTed. This means VMs can send packets to our backend network, and black-mesa will happily forward them. We should change this.

Change History (7)

comment:1 Changed 16 years ago by broder

  • Milestone changed from Alpha to Public Beta
  • Owner changed from sipb-xen to ecprice
  • Status changed from new to assigned

comment:2 Changed 16 years ago by price

  • Milestone set to Public Beta

comment:3 Changed 16 years ago by price

  • Description modified (diff)
  • Summary changed from Change default iptables policy from ACCEPT to Set up iptables to not forward arbitrary packets

comment:4 Changed 15 years ago by broder

Can anyone actually demonstrate that it's possible to send a packet whose source isn't the VM's IP address? I haven't been able to do this.

comment:5 Changed 15 years ago by broder

  • Resolution set to invalid
  • Status changed from assigned to closed

Sam Hartman wrote:

The current network config will not let a guest using invirt-route source packets unless the ip is correct. This is done using the RPF filter rather than iptables.

That's kind of what I expected.

comment:6 Changed 15 years ago by quentin

  • Resolution invalid deleted
  • Status changed from closed to reopened

That isn't the correct threat model; RPF prevents us from forged source addresses. It doesn't protect from legitimate packets addressed to the backend network. To whit:

root@sctv-television-rx:~# ping 10.5.128.17 PING 10.5.128.17 (10.5.128.17) 56(84) bytes of data.

--- 10.5.128.17 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3009ms

root@aperture-science:~# tcpdump -i eth0 host sctv-television-rx.xvm tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 17:42:32.610776 IP XVM-65.MIT.EDU > aperture-science-internal: ICMP echo request, id 46180, seq 1, length 64 17:42:33.620334 IP XVM-65.MIT.EDU > aperture-science-internal: ICMP echo request, id 46180, seq 2, length 64 17:42:34.620373 IP XVM-65.MIT.EDU > aperture-science-internal: ICMP echo request, id 46180, seq 3, length 64 17:42:35.620387 IP XVM-65.MIT.EDU > aperture-science-internal: ICMP echo request, id 46180, seq 4, length 64

Guests should never be able to generate traffic on the backend network.

comment:7 Changed 15 years ago by quentin

  • Description modified (diff)
  • Summary changed from Set up iptables to not forward arbitrary packets to Set up iptables to not forward arbitrary packets to the backend

(fix the formatting of my comment, and make the description and summary accurate)

That isn't the correct threat model; RPF prevents us from forged source addresses. It doesn't protect from legitimate packets addressed to the backend network. To whit:

root@sctv-television-rx:~# ping 10.5.128.17
PING 10.5.128.17 (10.5.128.17) 56(84) bytes of data.
--- 10.5.128.17 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3009ms
root@aperture-science:~# tcpdump -i eth0 host sctv-television-rx.xvm
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
17:42:32.610776 IP XVM-65.MIT.EDU > aperture-science-internal: ICMP echo request, id 46180, seq 1, length 64
17:42:33.620334 IP XVM-65.MIT.EDU > aperture-science-internal: ICMP echo request, id 46180, seq 2, length 64
17:42:34.620373 IP XVM-65.MIT.EDU > aperture-science-internal: ICMP echo request, id 46180, seq 3, length 64
17:42:35.620387 IP XVM-65.MIT.EDU > aperture-science-internal: ICMP echo request, id 46180, seq 4, length 64

Guests should never be able to generate traffic on the backend network.

Note: See TracTickets for help on using tickets.