September 21, 2014 at 16:52

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

     jail    Returning on a Saturday evening with a fun walk for mushrooms, I discovered a strange laptop condition:
    - the 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 has carried out an attack on another server on the Internet.
    This has placed a significant strain on network resources and, as a result, a segment of our network has been adversely affected.
    Your server has therefore been deactivated as a precautionary measure.
    A corresponding log history is attached at the end of this email.


        The site robot.your-server.de indicated that only one of the three IPs was blocked, and the main server functionality was working, which made the task a little easier.
        What is it? Did the server break? 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 is on a gray IP (I use other addresses in my networks);
    - why the netbios protocol is selected.
    14:47:27.911048 IP 78.X.Y.Z.50189 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST
14:47:27.911098 IP 78.X.Y.Z.56865 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST
14:47:27.911448 IP 78.X.Y.Z.58051 > 172.16.96.1.137: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
14:47:27.911453 IP 78.X.Y.Z.53676 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST
14:47:27.911502 IP 78.X.Y.Z.62404 > 172.16.96.1.137: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
14:47:27.911548 IP 78.X.Y.Z.50392 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST
14:47:27.911598 IP 78.X.Y.Z.64778 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST
14:47:27.911698 IP 78.X.Y.Z.60961 > 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.
        Further questions were raised by newly deployed virtual machines (one of them was with word press), a Windows virtual machine and a Windows virtual machine installed on a laptop.
        Checking Linux servers did not reveal any problems, the remote Windows virtual machine was turned off, and an antivirus was installed on the local Windows (before that, it installed defragmentation software and it aroused suspicion), which also did not find anything.
        Additionally, on dom0, I set filtering rules for netbios packets, but they did not work (as it turned out later, they didn’t apply them there).
        The first letter to Hetzner about unlocking with a diagnosis, but not if it is spoof on your network, remained unanswered.
        Just in case, I started tcpdump (and why didn’t I do it right away?), And it showed an amazing result: 
    21:55:01.985310 IP X.Y.W.Z.netbios-ns > 172.16.96.1.137.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
21:55:01.985472 IP X.Y.W.Z.netbios-ns > 172.16.96.1.137.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
21:55:01.985557 IP X.Y.W.Z.netbios-ns > 172.16.96.1.137.netbios-ns: NBT UDP PACKET(137): RELEASE; REQUEST; BROADCAST
21:55:01.987328 IP X.Y.W.Z.netbios-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 extinguish the applications one by one, and VmWare Fusion 5.04 first comes to hand. Miraculously, requests disappear. The subsequent launch of VmWare Fusion and virtual machines does not lead to a similar result. Quickly looking for the relationship between VmWare Fusion and Netbios, I come across a wonderful post in the 2012 VmWare community. It turns out that over 2.5 years VmWare did not fix this bug. Since this is my working laptop, so I always take it to meetings. Apparently, somewhere, he caught WINS settings on IP 172.16.96.1.
        The subsequent correspondence with Hetzner was a bit stupid (I had to confirm 3 times that the problem was resolved, and I have access to the server), but productive. IP was unblocked about an hour later.
    To prevent such problems in the future, we establish 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 the fight against "attacks" VmWare!
    Tags:

    Also popular now: