SQL Slammer: сеть легла за десять минут

В пятницу вечером, около восьми, начали звонить клиенты. Не один, не два - сразу несколько, с разных концов города, с одним и тем же: интернет встал. Не медленный, не с потерями - именно встал. Пинг до провайдера не проходит, сайты не открываются, почта не ходит.

Первая мысль - авария у провайдера. Но провайдеры у всех разные. Значит, не у провайдера.

Пока добирались до первого клиента удалённо, картина начала складываться. На маршрутизаторе - загрузка канала под сто процентов. Трафик весь исходящий, UDP, порт 1434, идёт на случайные адреса в интернете. Это не пользователи что-то скачали. Это SQL Slammer.

Что случилось. SQL Slammer - червь, который умещается в один UDP-пакет. Он эксплуатирует переполнение буфера в службе SQL Server Resolution Service - это Microsoft SQL Server 2000 и MSDE, порт 1434 UDP. Уязвимость была закрыта патчем ещё летом прошлого года. Но если патча нет и порт открыт наружу - всё, заражение мгновенное. Никакого файла, никакого вложения, никакого участия пользователя: пришёл пакет, сервер выполнил произвольный код, и уже через секунды сам начал слать такие же пакеты на случайные IP-адреса. С максимально возможной скоростью, без ограничений.

На узких каналах это убивает интернет полностью. Сламмер не думает о пропускной способности - он просто льёт, сколько может. Сто мегабит - зальёт сто мегабит, два - зальёт два. Добросовестно и без остановки.

Откуда взялся SQL Server наружу. Это отдельный разговор. У одного клиента - небольшая бухгалтерская программа, написанная местными разработчиками на MSDE. Программисты при установке открыли порт в брандмауэре «для удалённого доступа к базе данных», имея в виду что директор иногда работает из дома. Никакого VPN, просто проброс порта - так проще настроить. У другого клиента - похожая история с самописной CRM: база данных торчит наружу потому что «так было сделано изначально, мы не трогали». Третий - вообще не знал, что у него SQL Server установлен: шёл в комплекте с каким-то учётным ПО, поставился тихо, порт открылся сам.

Ни в одном из случаев администратор не принимал осознанного решения «выставить базу данных в интернет». Оно получилось само - через цепочку маленьких неудобных решений, каждое из которых казалось разумным в моменте.

Как лечили. Первое действие во всех случаях одинаковое - закрыть 1434 UDP на внешнем интерфейсе. Сразу, немедленно, пока канал забит. Маршрутизатор или firewall - неважно, главное заблокировать исходящий трафик с этого порта. Примерно через минуту после блокировки канал освобождается. Интернет возвращается.

Дальше - патч на SQL Server, KB327673. Потом разбираться, зачем вообще этот порт был открыт и как сделать нормально.

У одного клиента пришлось объяснять разработчикам программы, что удалённый доступ к базе нужно организовывать через VPN, а не прямым пробросом порта. Разработчики поначалу удивились: «раньше же работало». Работало. До пятницы.

Почему сервисы не должны торчать наружу. Code Red и Nimda в 2001-м показали это применительно к IIS - открытый веб-сервер без патча становится источником заразы. Со Slammer та же история, только с базой данных. И принцип один: сервис, который не должен быть виден из интернета, не должен быть виден из интернета. Это не параноя, это просто здравый смысл.

База данных практически никогда не должна принимать соединения напрямую из интернета. Это внутренний сервис: к нему ходит приложение, которое стоит рядом, или администратор через защищённый туннель. Не браузер партнёра, не «на всякий случай если нужен доступ откуда угодно».

Правило простое:

• Если сервис нужен только внутри сети - он должен слушать только на внутреннем интерфейсе или быть закрыт на периметре.
• Если нужен удалённый доступ - VPN, а потом уже к сервису. Не проброс порта напрямую.
• Если не знаете, что открыто - нужно проверить. Регулярно, не только после инцидента.

Про последнее - мы с прошлого года писали о мониторинге: не знаешь что происходит в сети - не управляешь ей. Это работает и для периметра: не знаешь что открыто - не контролируешь поверхность атаки.

Три клиента в одну пятницу - это не совпадение и не невезение. Это нормальное распространение быстрого червя по незакрытым портам. Сламмер прошёлся по всему интернету за несколько минут, просто потому что мог. Порты были открыты, патчей не было, и UDP не требует установки соединения - один пакет, и готово.

Ближайшие несколько дней потратим на обход остальных клиентов: смотреть что открыто на периметре, убирать лишнее, ставить недостающие патчи. Лучше в плановом режиме, чем в следующую пятницу вечером.