Как мы вылечили предприятие от вируса Petya -10


Когда мы приехали в компанию, на проходной висел большой плакат «КОМПЬЮТЕРЫ НЕ ВКЛЮЧАТЬ!» Это было указанием департамента ИТ для всех работников. Вся техника была выключена из розеток. Ситуация с серверной инфраструктурой была аналогичной: многие серверы были поражены. Корпоративные базы данных вовремя бэкапились, но в целом это, конечно, была катастрофа.

У предприятия есть ИТ-отдел, и сначала руководство хотело попытаться справиться своими силами. Каждый специалист тратил на один компьютер несколько часов, параллельно брался за несколько других. Один инженер мог переустановить максимум четыре компьютера в смену. Но как только их вводили в работу, Petya снова поражал их, распространяясь лавинообразно. Дело совсем не продвигалось, работа компании была парализована.

image

Напомню, что в прошлом году десятки российских предприятий попали под атаку шифровальщика-вымогателя Petya. В конкретном случае вирус был специально сконфигурирован под компанию и поразил всю ее ИТ-инфраструктуру, разбросанную территориально. Вернуть к жизни предприятие нам удалось за 20 дней силами специалистов по услугам AnyKey и компетенциям Microsoft в МТС и дочернего системного интегратора «Энвижн Груп».

После того, как ИТ-отдел не смог самостоятельно справиться с вирусом, руководство осознало, что теряет время, и приняло решение обратиться за помощью к подрядчику. Помимо неудачного опыта самостоятельного деплоймента, была еще одна большая проблема – сроки. Никто из потенциальных подрядчиков не гарантировал, что работы будут выполнены в сжатый срок. Также у заказчика было требование сохранить данные, которые уцелели и не успели зашифроваться (их надо было спасать), именно поэтому одной переустановки Windows было недостаточно.

Выбор в нашу пользу был сделан после того, как мы при первом обсуждении провели предварительную экспертизу и дали оценку, за какой срок мы сможем закончить всю работу – три недели. Плюсом было и то, что у нас уже был сервер, который мы могли бы привезти на объект и подключить его к местному, не привлекая со стороны заказчика какие-то дополнительные ресурсы. Мы купили билеты и на следующий день уже сидели в самолете с сервером под мышкой.

Что мы сделали


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

Сначала компьютер загружался в специальную оболочку, в которой выполнялись PowerShell scripts. Эти скрипты копировали на сетевое хранилище уцелевшие данные, потом устанавливалась новая чистая система из золотого образа, и уцелевшие данные возвращались на этот компьютер в определенную папку. Конечно, на сетевом хранилище стоял антивирус. Все файлы сканировались. Таким образом мы защищали их от повторного заражения.

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

Уникальность этого решения была в двух фишках: во-первых, мы применили PowerShell scripts и все сохраняли на файловые ресурсы, которые проводили потоковое сканирование антивирусом, во-вторых, мы все сделали в небольших выделенных VLANax.

image

Несмотря на то, что у нас все процессы были максимально автоматизированы, у заказчика имелось много компьютеров и распределенная сеть в формате звезды – центральный офис, несколько региональных офисов и зависимые от последних удаленные рабочие места. Для решения задачи нужно было объехать все объекты – не меньше сотни. Были и небольшие офисы, на которых всего один-два компьютера. Их все нужно было забрать и довезти до ближайшего крупного офиса заказчика, где уже имелась на должном уровне ИТ-инфраструктура, позволяющая производить работы.

Заказчик со своей стороны, конечно, максимально обеспечил нас транспортом, но кадровый ресурс был ограничен. Мы мобилизовали 25 ИТ-специалистов МТС с соседних регионов. Они работали без выходных и с перерывом только на сон, график работы был очень тяжелым, и нельзя было больше трех дней держать одного сотрудника на объекте – он просто бы выгорал. Поэтому у нас была непрерывная ротация кадров: сотрудник прилетает на три дня, улетает, вместо него прилетает другой. Так мы поддерживали большую интенсивность работы. Что важно, ребята, которые приезжали, быстро становились командой. Они знали, что делать, у них был четкий план, и их не надо было учить и вводить в курс дела. Отдельно у нас была команда, которая занималась восстановлением серверов.

Мы с руководителем проекта также вылетели на объект и занимались административной работой. Для заказчика было важно произвести четкое планирование, защитить проект. Все, конечно, горело, но есть регламент, комплаенс внутри: мы сидели и день и ночь готовили документы: обоснования, почасовое планирование, сетевой график выхода инженеров, писали, сколько и каких инженеров выходит на разработку, на каких объектах, какие работы они будут выполнять – все это было очень муторно, но необходимо для того, чтобы выполнить работу в срок.

Что получилось


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

На выходе все данные на серверах были подняты из бэкапа, и никакие критичные системы в итоге не пострадали, данные из корпоративных информационных систем утеряны не были. Помимо того сервера, который мы привезли с собой, в процессе реализации проекта решили развернуть дополнительные серверы MS Deployment Services на инфраструктуре заказчика. Мы научили его инженеров работать с этой системой, провели мастер-классы, обучали и консультировали. Заказчик остался с полной документацией, знал, как ему дальше производить деплоймент, как теперь с этим сервером дальше жить и что делать при наступлении похожей ситуации.

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

Стоит отметить, что спрос на ИТ-услуги на аутсорсе в подобных ситуациях в будущем будет расти, и не только из-за увеличения количества атак и совершенствования навыков хакеров. У этой услуги определенный потребитель – это компании с высоким уровнем зрелости, которые уже достигли такого этапа развития, что начинают управлять ИТ как услугой. На этом этапе происходят изменения в мышлении ИТ-директора: он понимает, что при переходе на аутсорс можно не оглядываться на собственные ресурсы и возможности, не вникать в личные дела сотрудников. Можно просто ставить задачу, договариваться об уровне сервиса и поддерживать заданный уровень получаемой услуги. Таким образом, ИТ-директор может заниматься более высокоуровневым планированием и свои ресурсы перенаправлять на какие-то более критичные задачи.

Сергей Гудков, руководитель отдела решений Майкрософт «Энвижн Груп».




К сожалению, не доступен сервер mySQL