A gift from VmWare or how to block your server on hosting

Returning on Saturday evening from a fun walk for mushrooms, I discovered the strange state of the laptop: - Internet does not work; - VPN with server installed and working. Having disconnected VPN, I immediately received a “letter of happiness” from Hetzner: Dear Sir or Madam Your server with the above-mentioned IP address. It has been negatively affected. Your server has therefore been deactivated as a precautionary measure. The corresponding log history is this email.

On the robot.your-server.de website, it was stated that only one of the three IPs was blocked, and the main functionality of the server works, which made the task a little easier.
What is it? Server broke? Unexpected effect of my open-resolver test ? Has my laptop picked up malware or botnet?

The attached log file (see below) raised additional questions:
- why the attack goes to a gray IP (in my networks I use other addresses);
- why the netbios protocol is selected.

14:47:27.911048 IP 78.XYZ50189 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST 14:47:27.911098 IP 78.XYZ56865 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST 14:47:27.911448 IP 78.XYZ58051 > 172.16.96.1.137: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST 14:47:27.911453 IP 78.XYZ53676 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST 14:47:27.911502 IP 78.XYZ62404 > 172.16.96.1.137: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST 14:47:27.911548 IP 78.XYZ50392 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST 14:47:27.911598 IP 78.XYZ64778 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST 14:47:27.911698 IP 78.XYZ60961 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST 

Since I use virtualization, I first checked the logs and activity on dom0 - I did not find anything suspicious.
Next, the questions were raised by newly deployed virtuals (one of them was with word press), a virtual Windows and a virtual Windows with installed on a laptop.
Checking the Linux servers did not reveal any problems, the remote virtual machine with Windows was turned off, and antivirus was installed on the local Windows (previously it installed software for defragmentation and it caused suspicions), which also did not detect anything.
Additionally, on the dom0 I installed the filtering rules for netbios packets, but they did not work either (as it turned out later, they did not apply them).
The first letter in Hetzner about unlocking with a diagnosis, and not whether it is spoof in your network, remained unanswered.
Just in case, I ran tcpdump (and why didn't I do it right away?), And it showed an amazing result:

 21:55:01.985310 IP XYWZnetbios-ns > 172.16.96.1.137.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 21:55:01.985472 IP XYWZnetbios-ns > 172.16.96.1.137.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 21:55:01.985557 IP XYWZnetbios-ns > 172.16.96.1.137.netbios-ns: NBT UDP PACKET(137): RELEASE; REQUEST; BROADCAST 21:55:01.987328 IP XYWZnetbios-ns > 172.16.96.1.137.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 

My server receives such requests (more than 200 requests per second), and requests come from my laptop. Tcpdump (I have a Macbook) running on a laptop confirms this. To identify the source, I decide to quench the applications one by one, and VmWare Fusion 5.04 comes first. Miraculously requests disappear. The subsequent launch of VmWare Fusion and virtualk does not lead to a similar result. I quickly look for the interconnection between VmWare Fusion and Netbios and stumble upon a wonderful post in the 2012 VmWare community. It turns out for 2.5 years VmWare did not fix this bug. Since this is my working laptop, so I constantly take it to meetings. Apparently, somewhere he caught the WINS settings for IP 172.16.96.1.
The subsequent correspondence with Hetzner was a bit stupid (I had to confirm 3 times that the problem was solved and I had access to the server), but productive. IP was unlocked in about an hour.
To prevent such problems in the future, we install an additional iptables rule (this time in the right place):

 -A RH-Firewall-1-INPUT -p udp -m multiport --dports 137,138,139 -j DROP 

Good luck in fighting VmWare attacks!