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

  • @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.

    Websites have ads, I have ad-blocker.

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

    Thanked by (2)chimichurri ehab
  • Please show full ticket content from that provider - because this sounds like not possible - you are missing something or that provider is missing something.

    Thanked by (1)Talistech

    Haven't bought a single service in VirMach Great Ryzen 2022 - 2023 Flash Sale.
    https://lowendspirit.com/uploads/editor/gi/ippw0lcmqowk.png

  • NeoonNeoon OG
    edited May 2023

    @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.

    Thanked by (1)sgheghele
  • FrankZFrankZ Moderator

    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/

    Thanked by (2)sgheghele ehab

    For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add

  • edited May 2023

    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.

  • @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?

    Thanked by (1)FrankZ
  • @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.

  • @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.

    Thanked by (1)sgheghele
  • FrankZFrankZ Moderator
    edited May 2023

    @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

    Thanked by (1)sgheghele

    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:

    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.

    Thanked by (2)FrankZ skorous
Sign In or Register to comment.