MAC Address abuse report?!

Hi,

Here we go again :)

We are using Proxmox 7.1-8 and got an abuse message from Hetzner today:
Abuse Message [AbuseID:the_ip]: MAC-Errors: MAC-Report for #server_id(server_ip)
Kontaktfoto
From network-abuse@hetzner.com on 2021-12-24 13:06
Detaljer
Abuse Message 9B839A1A.txt
(~194 B)
Dear Mr xxxxx,

We have detected that your server is using different MAC addresses from those allowed by your Robot account.
Click to expand...

Anyone else got the abuse message for Proxmox 7? Any ideas how to fix it?
 
spirit said:
Hi, do you use firewall ? and if yes, do you have any REJECT rule ?
Click to expand...

Yes, I use firewall functionality, configured from Proxmox web interface.
I set the Input policy to DROP (at Datacenter, Proxmox server and VM level) and only allowed the required ports.
Proxmox was installed using Hetzner image for Proxmox 7 two months ago.

In CLI these are the existing REJECT rulers:
# iptables -n -v -L |grep -i reject
Chain PVEFW-Reject (0 references)
0 0 PVEFW-reject udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 135,445
0 0 PVEFW-reject udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:137:139
0 0 PVEFW-reject udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:137 dpts:1024:65535
0 0 PVEFW-reject tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 135,139,445
Chain PVEFW-reject (4 references)
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset
0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT icmp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-unreachable
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Click to expand...
 
olegburca said:
Yes, I use firewall functionality, configured from Proxmox web interface.
I set the Input policy to DROP (at Datacenter, Proxmox server and VM level) and only allowed the required ports.
Proxmox was installed using Hetzner image for Proxmox 7 two months ago.

In CLI these are the existing REJECT rulers:
Click to expand...
do you have done all proxmox7 updates ?
#pve-version -v ?

interesting packages:

pve-cluster 7.0.5
https://git.proxmox.com/?p=pve-cluster.git;a=commit;h=fa420799297fb0dcf8c17cfc80f038e402899e91

add net.ipv4.igmp_link_local_mcast_reports = 0 to /etc/sysctl.d/pve.conf. (server need to be rebooted manually, or sysctl -p /etc/sysctl.d/pve.conf to apply the config)


-pve-firewall 4.2.3
https://git.proxmox.com/?p=pve-firewall.git;a=commit;h=d9e7522b561ceb323e93affb29c9fced89fed967

remove the default reject on port tcp/43
 
Last edited:
olegburca said:
Hi @spirit,
Everything was done excepting the net.ipv4.igmp_link_local_mcast_reports configuration. Just applied it.
In case we use IPv6 - is there an equivalent igmp_link_local_mcast_reports directive for it? Should it be also disabled?

Thank you!
Click to expand...
no need for ipv6.
 
Hi,
We got a new warning from Hetzner, despite we already set the configurations above.

net.ipv4.igmp_link_local_mcast_reports is disabled,
pve-cluster and pve-firewall packages are updated,
No rules for port 43 in the firewall configuration, port 43 is not accessible (Connection timed out error).

Any other ideas?
Thank you!
 

Attachments

  • 1642416654626.png
    1642416654626.png
    10.4 KB · Views: 17
olegburca said:
Hi,
We got a new warning from Hetzner, despite we already set the configurations above.

net.ipv4.igmp_link_local_mcast_reports is disabled,
pve-cluster and pve-firewall packages are updated,
No rules for port 43 in the firewall configuration, port 43 is not accessible (Connection timed out error).

Any other ideas?
Thank you!
Click to expand...
HI, and net.ipv4.igmp_link_local_mcast_reports is correctly applied ?
(sysctl -a |grep net.ipv4.igmp_link_local_mcast_reports ) ?
 
olegburca said:
Yes, it is:
# sysctl -a |grep net.ipv4.igmp_link_local_mcast_reports
net.ipv4.igmp_link_local_mcast_reports = 0

I did this and restarted the server when you recommended this previously.

View attachment 33333
Click to expand...
:( .

Difficult to known without having some traces.

it could be great to be able to reproduce, with theses iptables rules

Code: 
ebtables -I OUTPUT -o enp2s0 --among-src !mac1,mac2,mac3,... --log-level info --log-prefix "MAC-FLOOD-O" --log-ip -j CONTINUE
ebtables -I FORWARD -o enp2s0  --among-src !mac1,mac2,mac3,... --log-level info --log-prefix "MAC-FLOOD-F" --log-ip -j CONTINUE

replace mac1,mac2,mac3..... with the full list of all allowed mac
replace enp2s0 by your phyiscal interface name

Like this, I could see exactly what kind of packet,proto,port is send.
(or you can also replace CONTINUE by DROP, to protect yourself)
 
  • Like
Reactions: olegburca
spirit said:
:( .

Difficult to known without having some traces.

it could be great to be able to reproduce, with theses iptables rules

Code: 
ebtables -I OUTPUT -o enp2s0 --among-src !mac1,mac2,mac3,... --log-level info --log-prefix "MAC-FLOOD-O" --log-ip -j CONTINUE
ebtables -I FORWARD -o enp2s0  --among-src !mac1,mac2,mac3,... --log-level info --log-prefix "MAC-FLOOD-F" --log-ip -j CONTINUE

replace mac1,mac2,mac3..... with the full list of all allowed mac
replace enp2s0 by your phyiscal interface name

Like this, I could see exactly what kind of packet,proto,port is send.
(or you can also replace CONTINUE by DROP, to protect yourself)
Click to expand...

I added the rules with DROP, however looks like it was not blocking the packets with wrong MAC address.

I inspected the traffic using tcpdump and found the following packages:
Code: 
08:21:56.823350 00:25:90:d8:38:96 (oui Unknown) > 00:31:46:0d:24:02 (oui Unknown), ethertype IPv6 (0x86dd), length 78: fe80::225:90ff:fed8:3896 > fe80::1: ICMP6, neighbor advertisement, tgt is fe80::2
08:22:01.819824 00:25:90:d8:38:96 (oui Unknown) > 00:31:46:0d:24:02 (oui Unknown), ethertype IPv6 (0x86dd), length 86: fe80::225:90ff:fed8:3896 > fe80::1: ICMP6, neighbor solicitation, who has fe80::1

00:25:90:d8:38:96 is one of the MAC addresses Hetzner was complaining about.
Disabled IPv6 as I don't use it and continue to monitor.
Thanks for helping!
 
Last edited:
olegburca said:
I added the rules with DROP, however looks like it was not blocking the packets with wrong MAC address.

I inspected the traffic using tcpdump and found the following packages:
Code: 
08:21:56.823350 00:25:90:d8:38:96 (oui Unknown) > 00:31:46:0d:24:02 (oui Unknown), ethertype IPv6 (0x86dd), length 78: fe80::225:90ff:fed8:3896 > fe80::1: ICMP6, neighbor advertisement, tgt is fe80::2
08:22:01.819824 00:25:90:d8:38:96 (oui Unknown) > 00:31:46:0d:24:02 (oui Unknown), ethertype IPv6 (0x86dd), length 86: fe80::225:90ff:fed8:3896 > fe80::1: ICMP6, neighbor solicitation, who has fe80::1

00:25:90:d8:38:96 is one of the MAC addresses Hetzner was complaining about.
Disabled IPv6 as I don't use it and continue to monitor.
Thanks for helping!
Click to expand...
do you known on which interface is set the mac address ? (#ip addr | grep <mac>)

fe80::1: is for ipv6 local link address, I would like to known if it's coming from a fwbrX interface. (they don't have ip, but maybe ipv6 is enabled on theses interfaces, and maybe they are trying to get an auto ipv6 address)
 
spirit said:
do you known on which interface is set the mac address ? (#ip addr | grep <mac>)

fe80::1: is for ipv6 local link address, I would like to known if it's coming from a fwbrX interface. (they don't have ip, but maybe ipv6 is enabled on theses interfaces, and maybe they are trying to get an auto ipv6 address)
Click to expand...

I checked previously and it was not really set on any interface.
Cannot check right now as already disabled IPv6 at kernel level.

I have a feeling like it was set occasionally for some purpose (unknown for me).
Tonight it logged about 20 records, but without any evident periodicity. There were about 10 requests around 3-4 AM, and then some other until 8 AM when I disabled IPv6.
 
Last edited:
olegburca said:
I checked previously and it was not really set on any interface.
Cannot check right now as already disabled IPv6 at kernel level.

I have a feeling like it was set occasionally for some purpose (unknown for me).
Tonight it logged about 20 records, but without any evident periodicity. There were about 10 requests around 3-4 AM, and then some other until 8 AM when I disabled IPv6.
Click to expand...
ok, thanks. I'll try to reproduce on my side. (I just checked, ipv6 is correctly disabled on fwbr by default)
 
openaspace said:
Hello.
I have received a MAC abuse notification ...where my server is using n°3 mac address that aren't allowed for my account!

I have verified all MAC address configured on the virtual machines and proxmox host are all correct no one of the 3 mentioned MAC address are used in my configuration.
Click to expand...

That is a common mistake with proxmox on hetzner servers. You must not using a bridge to your public interfaces. You have to use a routet solution.

Background: pve creates another virtial device (for firewalling) with random mac adresses for each host and put in the bridge too. So hetzner will detect more than the allowed mac adresses. I found no way to prevent this, it is the solution/design from pve.

I had this problem too, tried different workarouds but have to switch to the routet solution. Everything is fine now. I did'nt found a way to prevent the creating of addition devices for each VM. If you MUST use a bridge, do not use pve, use a plain qemu ontop another distribution.

You can check if you affected (in your bridged) setup by check the devices in your bridge (assume this is vmbr0)

Code: 
brctl show vmbr0
 
ikke said:
That is a common mistake with proxmox on hetzner servers. You must not using a bridge to your public interfaces. You have to use a routet solution.

Background: pve creates another virtial device (for firewalling) with random mac adresses for each host and put in the bridge too. So hetzner will detect more than the allowed mac adresses. I found no way to prevent this, it is the solution/design from pve.

I had this problem too, tried different workarouds but have to switch to the routet solution. Everything is fine now. I did'nt found a way to prevent the creating of addition devices for each VM. If you MUST use a bridge, do not use pve, use a plain qemu ontop another distribution.

You can check if you affected (in your bridged) setup by check the devices in your bridge (assume this is vmbr0)

Code: 
brctl show vmbr0
Click to expand...
Can you please share your config file?

Having same issue on hetzner especially when I have multiple IPs
 
  • Like
Reactions: Stoiko Ivanov
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom