Unassigned LAN IP leads to server suspension because of spoofing
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?
Comments
That's a private IP address, like 192.168.1.123 and cannot be used as public/external IP.
Artificial intelligence is no match for our natural stupidity.
Time flies like an arrow; fruit flies like a banana.
For domain registrations, create an account at Dynadot (ref) and spend $9.99 within 48 hours to receive $5 DynaDollars!
Looking for cost-effective Managed/Anycast/DDoS-Protected/Geo DNS Services? Try ClouDNS (aff).
Please show full ticket content from that provider - because this sounds like not possible - you are missing something or that provider is missing something.
Haven't bought a single service in VirMach Great Ryzen 2022 - 2023 Flash Sale.
https://lowendspirit.com/uploads/editor/gi/ippw0lcmqowk.png
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.
Free NAT KVM | Free NAT LXC
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/
I am currently traveling in mostly remote areas until sometime in April 2024. Consequently DM's sent to me will go unanswered during this time.
For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add
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.
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.
Free NAT KVM | Free NAT LXC
@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.
I forgot to add... To see what IP rules are getting hits use
sudo iptables -L -vIf you wanted your private IP 10.10.10.123 to forward traffic to the internet via your wireguard tunnel instead of :
try
also ensure port forwarding is enabled. To check use
if you get the response
your good to forward traffic from the tunnel. If you get
Then forwarding is not enabled. To enable
This is not persistent. If you want to make it persistent across reboots, edit the
/etc/sysctl.conffile in your favorite text editor and changeto
Then after saving the file enter this command
I am currently traveling in mostly remote areas until sometime in April 2024. Consequently DM's sent to me will go unanswered during this time.
For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add
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.
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:
Drop packets from the LAN range if they are not destined to the Wireguard interface (wg0):
These are equivalent to the above stated:
But they will work in case of multiple eth interfaces. I will further investigate if more is required.