Permissive forwarding rule leads to unintentional exposure of containers (2021)

Re:Permissive forwarding rule leads to unintentional exposur... by TekMol on Wednesday June 22, 2022 @03:34PM (#31840773)

Does it have to? The attack looks like it would also work over the internet:

    2. [ATTACKER] Route all packets destined for 172.16.0.0/12 through the victim's machine.

    ip route add 172.16.0.0/12 via 192.168.0.100

Here, "192.168.0.100" could be exchange for any ip address I guess?

[ Parent | on HN ]

Re:Permissive forwarding rule leads to unintentional exposur... by jandrese on Wednesday June 22, 2022 @04:12PM (#31841273)

That will only work if you are on the same subnet.

When you craft a packet for that address, the stack will see that route and send an ARP "who has" request out whatever interface you assigned when you did that IP route rule (probably your default ethernet). If nobody responds than the packet dies in the stack.

[ Parent | on HN ]

Re:Permissive forwarding rule leads to unintentional exposur... by Plutoberth on Thursday June 23, 2022 @02:05AM (#31845669)

172.16.0.0/12 is a private subnet. This means that it's addresses are relevant only within a local network, and never over the internet. If you try to send a packet to an address within that subnet, layer 3 devices (i.e. routers) on the internet will drop it.

[ Parent | on HN ]

Re:Permissive forwarding rule leads to unintentional exposur... by thedougd on Wednesday June 22, 2022 @03:49PM (#31840975)

If that's true, you can then send packets to it, but not receive replies. That's still a problem.

[ Parent | on HN ]

Re:Permissive forwarding rule leads to unintentional exposur... by gcbirzan on Wednesday June 22, 2022 @03:49PM (#31840968)

Except you would have to be on the same layer 2 network as the "victim" for this to work.

[ Parent | on HN ]