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

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

В этой статье разберем, как можно было этого избежать.

Слабые места системы

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

Обычно программа состоит из *.exe файла и директорий, хранящих глобальные настройки, системные *.dll файлы и содержащие *.log записи пользователя. Конкретно насчет доступов необходимо узнавать у сотрудников, предоставляющих вам данный софт.

Рассмотрим пример используемой программы.

Структура файлов:

1. Корневая директория – содержит поддиректории, основной *.exe файл (за счет которого пользователь запускает программу) и файлы с настройками;

2. Поддиректории – делятся на 2 группы, статические (С)/ динамические (Д):

   2.1 Поддиректории (С) – хранят файлы конфигурации/настройки (файлы в данных директориях не должны меняться);

   2.2 Поддиректории (Д) – ведут запись log-ов пользователя при работе с программой (файлы в данных директориях изменяются в связи с запуском программы).

Запуск программы производится от имени учетной записи пользователя, следовательно, для записи log в Директорию (Д), пользователю необходимы права “Чтение и запись”

Исходя из приведенной структуры и знаниях о логике работы программы можно разграничить права следующим образом:

• Корневая директория – “Чтение”

• Поддиректории (С) – “ Чтение”

• Поддиректории (Д) – “Чтение/Запись”

Таким образом, предоставление доступа “Full Access” на корневую директорию и все вложенные, было нарушением всех правил безопасности.

Вредоносный софт, внедрение, последствия

Из-за допущенной ошибки следует – любой пользователь, знающий о данной проблеме, мог беспрепятственно подменить *.exe файл.

Запуск *.exe файла триггерит скрипт, обращающийся напрямую к интернету (это является неприятной “особенностью” данной программы и избежать такой сценарий нельзя), т.е. простыми словами, подмененный файл мог беспрепятственно скачать вредоносное ПО с прописанного в конфигурации ресурса, чем и воспользовался злоумышленник.

Для распространения вируса по сети, мошенник создает пользователя с привилегированными правами (*имя домена*/Domain Admin), добавляет в него самораспаковывающийся архив и прописывает скрипт, запускающий учетную запись на все доступные серверы.

В итоге N-ое количество серверов с зашифрованными
дисками, восстановление которых будет доступно только при вводе пароля. Его
естественно предоставит злоумышленник в случае выполнения установленных
требований.

Восстановление, методы защиты

Основным способом восстановления сети в подобных ситуациях является развертывание бэкапов. Однако в конкретном примере сервер с резервными копиями был выведен из строя.

Как можно было этого избежать?

Для ответа на этот вопрос необходимо подробнее углубиться в структуру сети.

Каждая компания имеет свой домен. Домен – это основная административная единица в сетевой инфраструктуре предприятия, в которую входят все сетевые объекты, такие как пользователи, компьютеры, принтеры, общие ресурсы и т.д.

Для обеспечения отказоустойчивости сети необходимо иметь корневой домен (доступ к которому будет только у администраторов) с несколькими контроллерами, а также домены 1-2 уровня.

Благодаря встроенному в Active Directory компоненту Windows Backup Server, можно настроить резервное копирование контроллеров домена и прочих серверов в области домена по определенному сетевому пути. Для каталога, выбранного в качестве хранилища можно задать необходимые права доступа, например, разрешить “Чтение/Запись” в эту директорию только учетным записям “Domain Admins” и “Domain Controllers”.

Учитывая выше сказанное, необходимо определить, администраторы какого домена будут отвечать за создание бэкапов?

В данном случае доступ был предоставлен учетным записям как корневого домена, так и вложенного.

Из-за этой ошибки учетная запись злоумышленника получила возможность зайти на сервер и зашифровать диски с резервными копиями.

Корректировка настроек безопасности

Для повышения уровня безопасности первоначально было принято решение убрать “полный доступ” к корневой папке используемой программы.

После чего, данной директории была выдана созданная в Active Directory группа доступа. С правами, соответствующими схеме в пункте “Слабые места системы”.

При выполнении всех указанных действий общая картина выглядит следующим образом:

1. Сотрудник обращается в IT отдел, с просьбой о предоставлении доступа к программе;

2. Сотрудник IT отдела проверяет, точно ли пользователь должен иметь доступ к программе:

   2.1 Если сотруднику для работы необходимо использование программы – его учетной записи добавляется (созданная выше) группа безопасности;

   2.2 Если работа сотрудника не связана с программой – в доступе отказывается и запрашивается согласование Руководства.

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

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

Этим действием по сути полностью был убран доступ к программе изнутри. Т.е. даже если злоумышленник получает привилегированную учетную запись и выдает требуемую группу доступа, он не может зайти на сервер из-за отсутствия доменной авторизации (авторизации через учетную запись домена).

Так как сервер до сих пор оставался в нашей сети (не в домене), для возможности использования программы был предоставлен общий доступ к директории с *.exe файлом.

Общего доступа в любом случае было бы мало, поэтому на самой станции был создан локальный пользователь (за счет которого сотрудники смогут зайти в каталог, содержащий исполняемый файл).

Однако обычно создание локальной учетной записи недостаточно надежное решение, следовательно, дополнительно необходимо настроить уровни его доступа в соответствии с обговоренной ранее доменной группой безопасности (доступ только к необходимым директориям с правами “Чтение”)

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

Заключение

Сейчас любая компания имеет уязвимые места в своей сетевой инфраструктуре. В любом случае обезопасить свою систему на 100% не предоставляется возможным. В этой статье описан пример частного случая и один из возможных сценариев развития событий.
Перепроверяйте настройки доступа, следите за основными директориями, которые априори должны оставаться неизменными, а также обеспечьте максимально возможную безопасность своих серверов с резервными копиями, потому что именно они позволят избежать лишних “непредвиденных” затрат.