Анатомия глубокого IT-аудита: почему поверхностный чек-лист не спасет ваш бизнес от катастрофы

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

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

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

1. Аппаратный уровень: заглядываем в телеметрию дисков и процессоров

Наш подход: мы оцениваем риски отказа оборудования на основе реальной телеметрии и спецификаций вендоров.

• ●Ресурс SSD под микроскопом. В ходе аудита мы обнаружили, что на ключевых серверах (интернет-шлюз, сервер 1С, файловый сервер) установлены накопители потребительского класса (серии Samsung EVO, OCZ Vertex), предназначенные для домашних ПК. Мы не просто указали на это, а рассчитали износ. Например, на сервере резервных копий системный SSD выработал 63 Тб, а на IP-АТС — 7 Тб, что многократно превышало их лимиты.
• ●Отсутствие отказоустойчивости. Ни на одном из 8 исследованных серверов не использовалась технология RAID. Выход из строя любого диска гарантированно привел бы к безвозвратной потере данных и остановке бизнеса.
• ●Аппаратные аномалии. Проанализировав логи сервера СЭД, мы обнаружили регулярные сообщения о перегреве процессора. Скрининг показал скачки температуры до +73 °C (при критическом пороге в +82 °C). Мы сразу локализовали и устранили проблему: брак термопакета либо дефект системы охлаждения, который мог привести к физическому разрушению кристалла при пиковой нагрузке.

2. Уровень конфигураций: почему «закрытый» порт на самом деле открыт

Наш подход: мы построчно разбираем правила файрвола и конфигурации сетевых служб.

• ●Политика по умолчанию. На интернет-шлюзе под управлением Debian правила фильтрации закрывали лишь несколько портов. При этом параметр по умолчанию стоял в режиме policy ACCEPT (разрешено все). Это означало, что шлюз пропускал любой другой внешний трафик. Как результат — логи сервера были забиты ежесекундными попытками подбора паролей со стороны внешних ботов.
• ●Невидимые уязвимости. Мы не просто пишем «обновите ПО». На интернет-шлюзе со старой версией Debian (3.16) мы выявили: Apache2 (v2.4.10) — 22 уязвимости; BIND9 (v9.9.5-9) — 18 уязвимостей; NTPd (v4.2.6p5) — 23 уязвимости; Samba (v4.2.14) — 19 уязвимостей.
• ●Детальный анализ секции NAT показал, что критически важные ресурсы были открыты во внешнюю сеть. Порты RDP (12202, 33441, 21006, 23988) вели напрямую к файловому серверу и серверу СКУД. В условиях отсутствия ограничений по IP-адресам это делало инфраструктуру легкой мишенью для автоматизированного перебора паролей и заражения вирусами-шифровальщиками.

3. Анализ прав доступа и логики скриптов: от скрытых учётных записей до финансовых рисков

Наш подход: мы проверяем права доступа вручную и досконально разбираем код системных скриптов.

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

1. 1.К сетевому каталогу с конфиденциальной информацией был открыт полный доступ для всех авторизованных пользователей локальной сети.
2. 2.Внутри этого каталога находилась папка backup_scripts со сценариями резервного копирования. Из-за некорректных прав любой рядовой сотрудник мог читать и изменять эти скрипты.
3. 3.Внутри файлов сценариев в открытом виде хранились логины и пароли от баз данных внутренней CRM, а также реквизиты FTP-доступа к хранилищу резервных копий. Это позволяло любому пользователю незаметно скопировать все базы данных компании.
4. 4.Возможность модификации этих скриптов позволяла злоумышленнику скрытно захватить контроль над сервером. Достаточно было добавить всего две строчки кода, чтобы во время очередного ночного бэкапа в системе автоматически создалась учётная запись с правами локального администратора.

На сервере резервных копий из-за ошибок в настройке Samba к пяти ключевым каталогам (включая backup и video) был открыт неавторизованный гостевой доступ. Любой пользователь, подключенный к локальной сети или корпоративному Wi-Fi, мог прочитать или удалить незашифрованные резервные копии баз 1С. Это открывало вектор для опасной финансовой атаки: злоумышленник мог скачать бэкап 1С, изменить банковские реквизиты контрагента в ожидающем оплату документе, вернуть модифицированную копию обратно и повредить рабочую базу.

4. Уровень периферии и беспроводных сетей: уязвимости, о которых забывают

• ●Зависимость Wi-Fi от личной почты. Управление корпоративным Wi-Fi на базе оборудования Zyxel велось через облачный портал Nebula, привязанный к личному почтовому ящику администратора. Взлом этой почты ставил под угрозу безопасность всей беспроводной сети. При этом сам пароль от Wi-Fi состоял всего из 8 цифр, что позволяло подобрать его методом перебора за короткое время.
• ●Уязвимость офисных МФУ. Сетевые принтеры использовались со стандартными заводскими паролями. Мы продемонстрировали, как с помощью общедоступного пароля из документации производителя можно получить доступ к панели администрирования МФУ и извлечь из буфера памяти конфиденциальные документы (в качестве примера был выгружен документ объемом 46 страниц).