Подарок от VmWare или как заблокировать свой сервер на хостинге

в 12:52, , рубрики: Hetzner, VMware, атака, виртуализация, информационная безопасность, хостинг
 jail     Вернувшись в субботу вечером с увеселительной прогулки за грибами, я обнаружил странное состояние ноутбука:
— интернет не работает;
— VPN с сервером установлен и работает.
Отключив VPN, я немедленно получил «письмо счастья» от 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 considerable 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.

    На сайте robot.your-server.de было указано, что был заблокирован только один IP из трех, и основной функционал сервера работает, что немного облегчало задачу.
    Что это? Сервер поломали? Неожиданный эффект моего теста с открытым ресолвером? Мой ноутбук подцепил malware или botnet?

    Приложенный лог-файл (см. ниже) вызывал дополнительные вопросы:
— почему атака идет на серый IP (в своих сетях я использую другие адреса);
— почему выбран протокол netbios.

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

    Так как я использую виртуализацию, то первым делом проверил логи и активность на dom0 — подозрительного ничего не обнаружил.
    Далее вызывали вопросы вновь развернутые виртуалки (одна из них была с word press), виртуалка Windows и виртуалка с Windows установленная на ноутбуке.
    Проверка Linux серверов не выявила никаких проблем, удаленная виртуалка с Windows была выключена, а на локальную Windows установлен антивирус (до этого ставил софт для дефрагментации и он вызывал подозрения), который также ничего не обнаружил.
    Дополнительно на dom0 установил правила фильтрации netbios пакетов, но и они не срабатывали (как оказалось позднее не там их применил).
    Первое письмо в Hetzner о разблокировке с диагнозом, а не спуф ли это в вашей сети, остался без ответа.
    На всякий случай запустил tcpdump (и почему я это сразу не сделал?), и он показал удивительный результат:

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

    Мой сервер получает такие запросы (более 200 запросов в секунду), и запросы идут с моего ноутбука. Tcpdump (у меня Macbook) запущенный на ноутбуке подтверждает это. Чтобы выявить источник, поочередно решаю гасить приложения, и первым под руку попадает VmWare Fusion 5.04. Чудесным образом запросы пропадают. Последующий запуск VmWare Fusion и виртуалок не приводит к подобному результату. Быстро ищу взаимосвязь VmWare Fusion и Netbios и натыкаюсь на чудесный пост в комьюнити VmWare от 2012 года. Получается за 2.5 года VmWare так и не исправили этот баг :( Так как это мой рабочий ноутбук, поэтому я его постоянно беру на встречи. Видимо, где-то он поймал настройки WINS на IP 172.16.96.1.
    Последующая переписка с Hetzner была немного глупой (3 раза пришлось подтвердить, что проблема решена, и у меня есть доступ к серверу), но продуктивной. IP был разблокирован где-то через час.
Чтобы предупредить такие проблемы в дальнейшем, устанавливаем дополнительное правило iptables (на этот раз уже в правильном месте):

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

Удачи в борьбе с «атаками» VmWare!

Автор: Homas

Источник

* - обязательные к заполнению поля