Unassigned LAN IP leads to server suspension because of spoofing

sgheghele

Can you educate me on something I was not aware of?

I added a LAN IP address to my WireGuard server like this:

ip addr add 10.10.10.123/32 dev wg0

I happened not to use this IP for anything. The IP was pingable when connected to WireGuard, the server would respond.

The hosting provider suspended my server because of IP spoofing, that someone had been using that unassigned IP to spoof my public IP.

This was fixed easily, but now I have questions.

How is that possible? Given that there was no breach, it means that the unassigned LAN IP could be somehow used to act as the external IP?

somik

@sgheghele said:
ip addr add 10.10.10.123/32 dev wg0

That's a private IP address, like 192.168.1.123 and cannot be used as public/external IP.

TheDP

@sgheghele said: someone had been using that unassigned IP to spoof my public IP

Jab

Please show full ticket content from that provider - because this sounds like not possible - you are missing something or that provider is missing something.

Neoon

@Jab said:
Please show full ticket content from that provider - because this sounds like not possible - you are missing something or that provider is missing something.

Yes, if its Hetzner.
You have to drop any traffic from IP ranges, even if private, if something leaks out, you end up getting a abuse ticket with Hetzner.

FrankZ

I expect other providers, besides Hetzner, have an issue with leaking private IP ranges to their networks. As a general practice I block all private IP ranges that I use on tun/tap devices both inbound & outbound from outside networks via firewall rules. I also do not use any 10.x.x.x subnets on VMs because I see so many of them in my traceroutes. Just my two cents/

sgheghele

Yes, I was also surprised by this. I’m on mobile and they sent screenshots mostly, so I can’t reproduce here easily.

They showed me that there was a ping to my external/public IP address associated to the MAC address of eth0 (correct, expected).

Then, they showed a ping to 10.10.10.123 (don’t know from where) also associated to the MAC address of my eth0 interface (not the WireGuard one). Which I understand is not desirable, but not sure how bad/dangerous it it is. I have trouble to name this issue, so I can’t research it.

@FrankZ @Neoon you seem familiar with the issue. Would you have any link or keyword that explain me what the issue here is, which kind of spoofing this can bring and how? (I’m not with Hetzner btw)

@somik @TheDP yeah, this would be new to me as well and the first time that a provider complains about it.

skorous

@sgheghele said:

Then, they showed a ping to 10.10.10.123 (don’t know from where) also associated to the MAC address of my eth0 interface (not the WireGuard one). Which I understand is not desirable, but not sure how bad/dangerous it it is. I have trouble to name this issue, so I can’t research it.

So it's proxying/forwarding arp requests instead of masquerading them?

sgheghele

@skorous said:

@sgheghele said:

Then, they showed a ping to 10.10.10.123 (don’t know from where) also associated to the MAC address of my eth0 interface (not the WireGuard one). Which I understand is not desirable, but not sure how bad/dangerous it it is. I have trouble to name this issue, so I can’t research it.

So it's proxying/forwarding arp requests instead of masquerading them?

No idea. I wouldn’t even know how to do this maliciously.

I removed the unused IP, then have the following commands at boot:

iptables -D INPUT -i eth0 -s 10.10.10.0/24 -j DROP
iptables -D FORWARD -i eth0 -s 10.10.10.0/24 -j DROP

Which I believe would fix the issue but unsure given that I don’t know what to search for.

I’m also curious whether it only can happen with unused IPs or any IP if I don’t block the LAN range on eth0.

Neoon

@sgheghele said:

@skorous said:

@sgheghele said:

Then, they showed a ping to 10.10.10.123 (don’t know from where) also associated to the MAC address of my eth0 interface (not the WireGuard one). Which I understand is not desirable, but not sure how bad/dangerous it it is. I have trouble to name this issue, so I can’t research it.

So it's proxying/forwarding arp requests instead of masquerading them?

No idea. I wouldn’t even know how to do this maliciously.

I removed the unused IP, then have the following commands at boot:

iptables -D INPUT -i eth0 -s 10.10.10.0/24 -j DROP
iptables -D FORWARD -i eth0 -s 10.10.10.0/24 -j DROP

Which I believe would fix the issue but unsure given that I don’t know what to search for.

I’m also curious whether it only can happen with unused IPs or any IP if I don’t block the LAN range on eth0.

Yea, drop the outgoing packages via your primary interface / which is the default route.

FrankZ

@sgheghele - I expect @skorous is correct you are leaking arp requests. iptables rules should fix your problem.
You might want to use the "-A" append option instead of the "-D" delete option in your iptables rules.

iptables -A INPUT -i eth0 -s 10.10.10.0/24 -j DROP
iptables -A OUTPUT -o eth0 -s 10.10.10.0/24 -j DROP

I forgot to add... To see what IP rules are getting hits use sudo iptables -L -v

---

If you wanted your private IP 10.10.10.123 to forward traffic to the internet via your wireguard tunnel instead of :

iptables -A FORWARD -i eth0 -s 10.10.10.0/24 -j DROP

try

iptables -A POSTROUTING -s 10.10.10.0/24 -j SNAT --to-source [your external IPv4 address]

also ensure port forwarding is enabled. To check use

sysctl net.ipv4.ip_forward

if you get the response

net.ipv4.ip_forward = 1

your good to forward traffic from the tunnel. If you get

net.ipv4.ip_forward = 0

Then forwarding is not enabled. To enable

sysctl -w net.ipv4.ip_forward=1

This is not persistent. If you want to make it persistent across reboots, edit the /etc/sysctl.conf file in your favorite text editor and change

net.ipv4.ip_forward = 0

to

net.ipv4.ip_forward = 1

Then after saving the file enter this command

sysctl -p

sgheghele

Yeah I accidentally copy/pasted the PostDown lines. The ones on PostUp have -A.

Thanks @Neoon for confirming and thank tou @FrankZ for the extensive reply. I’ll check all commands once back, to see if some are needed.

I see that others didn’t know about this so I guess this post will turn out useful.

sgheghele

Alright, I came back home and here is what I found out. This seems to be a case of IP address spoofing as implied by @FrankZ.

Two initial steps to be done to prevent this are:

Enable reverse path filtering

As easy as adding the two following sysctl entries:

net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1

Drop packets from the LAN range if they are not destined to the Wireguard interface (wg0):

iptables -A INPUT ! -i wg0 -s 10.10.10.0/24 -j DROP
iptables -A FORWARD ! -i wg0 -s 10.10.10.0/24 -j DROP

These are equivalent to the above stated:

iptables -A INPUT -i eth0 -s 10.10.10.0/24 -j DROP
iptables -A OUTPUT -o eth0 -s 10.10.10.0/24 -j DROP

But they will work in case of multiple eth interfaces. I will further investigate if more is required.