0

Suppose I have this situation where I wrote a program to poison the ARP cache of 2 devices (let's say A and B), both in the local network to successfully able to MITM from device M. The program runs on device M. When I enable IP forwarding with the command sysctl net.ipv4.ip_forward=1 on device M, HTTP connection from device A to B can be established without any issues, and I am able to see the traffic on device M.

But, the same situation where ARP caches are poisoned after I disable the IP forwarding with the command sysctl net.ipv4.ip_forward=0 on device M, HTTP connection can't be established from device A to B. I can see the TCP SYN packet from device A on device M. In my program, after receiving the SYN packet on device M, I modify the src MAC address in the packet with M's MAC address (from A's MAC address) and dst MAC address to B's MAC address (from M's MAC address) and inject it into the network. I don't modify anything from the network layer onwards. I can see the packet at B with new src and dst MACs with TCPdump command, which means the packet gets to the B. But B doesn't respond to that packet, which I can't comprehend why.

So, the question is what special does ip_forward=1 does that makes this kind of MITM situation work? To clarify, all the machines are linux. With forwarding enabled on device M, I don't need to modify the MAC addresses in the packets. I just poison the cache and things work fine from there.

2 Answers 2

1

M's kernel receives a packet whose destination IP address indicates it's not meant for M. What will it do?

When ip_forward=0, it thinks: "I don't know why this got sent to me and I don't really care. To the trash it goes!"

With ip_forward=1, "Hmm, this is not for me. But I know where the recipient is, so I'll just resend it with the correct MAC address."

In other words, with ip_forward=1, you don't have to modify the MAC address because your kernel does it for you.

1
  • If the packet sent for a different IP address gets discarded I am curious why I am still able to read the packet programmatically? Also, when I send a ping using ICMP, which also uses IP protocol, B receives the packet with the exact setup. That got me thinking - does this possible drop behavior related to TCP only? Nov 23, 2021 at 3:59
0

When you poison the ARP cache, A and B start sending datagrams to M that have the MAC-Adress of M but the IP addresses of B and A respectively. So these datagrams are directed at M in layer 2 (ethernet) but directed at the other device in layer 3 (IP). In order to send these datagrams out to the layer 3 recipient (according to IP address) M has to do IP forwarding.

With net.ipv4.ip_forward=0 you disable IP forwarding, with net.ipv4.ip_forward=1 you enable it.


Why is IP forwarding needed?

Take a look at the OSI model. There you find

  • HTTP at layer 7
  • TCP at layer 4
  • IP at layer 3
  • Ethernet at layer 2

Your ARP poisoning affects layer 2.

If there is no ARP poisoning the HTTP message from A to B is wrapped into a TCP stream (directed at port 80) which is sent with IP to the IP address of B. The IP address of B is associated with the Ethernet address of B and the datagrams go straight (through the hub or switch) from A to B and vice versa. There is no necessity to forward IP.

When you poison the ARP cache of A and B to point to M, the following happens. The HTTP message from A to B is wrapped into a TCP stream (directed at port 80) which is sent with IP to the IP address of B. The IP address of B is associated with the Ethernet address of M and the datagrams go to M. M is not the intended recipient of these datagrams.

In order ot make the HTTP connection work, M has to forward the IP datagrams from A to B and vice versa. This may happen either through the kernel with the setting above or with a special program that listens for these datagrams and resends them.

1
  • Yes, but I wanted to know why IP forwarding is needed when I am reading the packet from A on M and sending it to B. Nov 18, 2021 at 18:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.