Hetzner — история одной блокировки
Вернувшись в субботу вечером с увеселительной прогулки за грибами, я обнаружил странное состояние ноутбука: — интернет не работает; — VPN с сервером установлен и работает.Отключив VPN, я немедленно получил «письмо счастья» от Hetzner:
Dear Sir or MadamYour 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 & gt; 172.16.96.1.137: NBT UDP PACKET (137): REFRESH (8); REQUEST; UNICAST 14:47:27.911098 IP 78.X.Y. Z.56865 & gt; 172.16.96.1.137: NBT UDP PACKET (137): REFRESH (8); REQUEST; UNICAST 14:47:27.911448 IP 78.X.Y. Z.58051 & gt; 172.16.96.1.137: NBT UDP PACKET (137): QUERY; REQUEST; UNICAST 14:47:27.911453 IP 78.X.Y. Z.53676 & gt; 172.16.96.1.137: NBT UDP PACKET (137): REFRESH (8); REQUEST; UNICAST 14:47:27.911502 IP 78.X.Y. Z.62404 & gt; 172.16.96.1.137: NBT UDP PACKET (137): QUERY; REQUEST; UNICAST 14:47:27.911548 IP 78.X.Y. Z.50392 & gt; 172.16.96.1.137: NBT UDP PACKET (137): REFRESH (8); REQUEST; UNICAST 14:47:27.911598 IP 78.X.Y. Z.64778 & gt; 172.16.96.1.137: NBT UDP PACKET (137): REFRESH (8); REQUEST; UNICAST 14:47:27.911698 IP 78.X.Y. Z.60961 & gt; 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!
