Защиту сайта часто сводят к одному решению. Подключают WAF, устанавливают антивирус, обновляют CMS или настраивают резервное копирование. Каждая из этих мер полезна. Но ни одна из них не закрывает все возможные сценарии атаки.

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

Поэтому защита сайта должна состоять из семи независимых уровней:

1. Учетные записи и права доступа.
2. Код, CMS и API.
3. Управление обновлениями.
4. Сервер и внешний периметр.
5. Зависимости и процесс развертывания.
6. Мониторинг и обнаружение атак.
7. Резервное копирование и восстановление.

Главный принцип такой: если один уровень не сработал, остальные должны остановить атаку, ограничить ущерб и позволить быстро восстановить работу.

Именно способность системы выдержать отказ одного из уровней показывает, насколько сайт действительно защищен.

 

Содержание:

Почему одного средства защиты недостаточно

Как защита сайта «Энсайн» выдержала DDoS-атаку мощностью почти 110 Гбит/с

Семь уровней защиты сайта

Как уровни защиты подстраховывают друг друга

Чек-лист семи уровней защиты

Почему слабые места не всегда видны

Вывод

 

Почему одного средства защиты недостаточно

Современный сайт редко существует отдельно от других систем компании.

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

К этому добавляется инфраструктура разработки:

• репозитории;
• сторонние библиотеки;
• системы автоматической сборки;
• облачные сервисы;
• тестовые серверы;
• учетные записи разработчиков;
• ключи и токены интеграций.
  
  

Злоумышленнику необязательно атаковать главную страницу. Он ищет самое слабое место во всей цепочке.

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

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

 

Как защита сайта «Энсайн» выдержала DDoS-атаку мощностью почти 110 Гбит/с

Один из самых показательных случаев в работе нашего системного администратора Вадима Зимина прошел внутри компании почти незаметно.

Именно так и выглядит хорошо подготовленная инфраструктура.

Речь идет о корпоративном сайте «Энсайн». Для ИТ-интегратора устойчивость собственных ресурсов напрямую связана с профессиональной репутацией. Мы предъявляем к своей инфраструктуре те же требования, что и к системам заказчиков.

Вадим заранее подключил сайт к внешней системе фильтрации DDoS-трафика. Задача была конкретной: ресурс должен оставаться доступным даже во время атаки.

Позже это решение прошло проверку в реальных условиях.

Атака продолжалась около 10 минут. В пике ее мощность достигала почти 110 Гбит/с, а интенсивность составляла около 9,5 млн пакетов в секунду.

Без защиты сайт бы просто лег. Атака пришлась как раз на рекламную кампанию, на которую уже потратили серьезный бюджет. И проблема была бы не только в потерянных заявках. Мы запускали рекламу, чтобы проверить конкретную гипотезу, а при недоступном сайте нормальных данных уже не получить. Пришлось бы восстанавливать ресурс, а потом заново оплачивать и запускать кампанию. То есть расходы по сути выросли бы в 2 раза.

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

«Сильная работа системного администратора часто остается за кадром. Вадим заранее подготовил защиту, и атака мощностью почти 110 Гбит/с прошла без недоступности сайта», — говорит Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

В этом случае сработали два уровня.

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

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

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

 

Семь уровней защиты сайта

Уровень 1. Учетные записи и права доступа

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

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

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

• панель хостинга;
• DNS;
• CDN;
• репозиторий;
• система развертывания;
• облачная инфраструктура;
• база данных;
• резервные копии;
• административные интерфейсы.
  
  

Если одна учетная запись открывает доступ сразу к нескольким системам, ее компрометация становится критической.

Что должно быть настроено

Для всех привилегированных учетных записей нужна многофакторная аутентификация.

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

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

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

Что произойдет при отказе уровня

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

Основные ответственные: владелец системы и системный администратор.

 

Уровень 2. Код, CMS и API

Второй уровень защищает от ошибок самого приложения.

К этой группе относятся:

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

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

Предположим, документ открывается по адресу:

/api/documents/1256

Если сервер проверяет только наличие активной сессии, но не проверяет принадлежность документа, достаточно изменить номер в запросе.

Так можно получить доступ к чужим заказам, договорам, счетам или внутренним документам.

Сложный адрес не является защитой. Права необходимо проверять при каждом обращении к объекту.

Что должно быть настроено

Приложение должно контролировать:

• входящие данные;
• права на каждый объект и действие;
• тип и размер загружаемых файлов;
• количество запросов;
• содержимое ответов API;
• создание и завершение сессий;
• восстановление доступа;
• обработку ошибок.
  
  

Готовая CMS не снимает эту задачу. Безопасность зависит от версии платформы, установленных модулей, настроек и качества доработок.

Что произойдет при отказе уровня

Если в приложении появилась уязвимость, часть атак может остановить WAF. Сегментация ограничит доступ к внутренним системам. Мониторинг покажет необычные запросы. Резервная копия поможет вернуть систему, если данные были повреждены.

Основные ответственные: технический руководитель и разработчики.

 

Уровень 3. Управление обновлениями

Наличие исправления не защищает сайт, пока оно не установлено.

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

Для управления этим риском нужно знать точные версии:

• CMS;
• плагинов;
• фреймворков;
• библиотек;
• серверного ПО;
• базы данных;
• операционной системы;
• контейнеров.
  
  

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

Что должно быть настроено

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

1. Получить информацию об уязвимости.
2. Проверить, используется ли компонент.
3. Оценить возможность эксплуатации.
4. Подготовить резервную копию.
5. Проверить исправление.
6. Установить обновление.
7. Проанализировать журналы.
8. Убедиться, что уязвимость не использовали раньше.

Если компонент нельзя обновить сразу, часть атак можно временно блокировать через WAF или сетевые правила. Но это только временная компенсация.

Пока уязвимый компонент остается в системе, риск не устранен.

Что произойдет при отказе уровня

Если исправление не было установлено вовремя, внешний периметр может остановить известный способ эксплуатации. Мониторинг поможет обнаружить попытки атаки. Изоляция приложения ограничит возможное распространение.

Основная ответственная сторона: команда сопровождения.

 

Уровень 4. Сервер и внешний периметр

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

В него входят:

• CDN;
• защита от сетевых DDoS;
• защита от прикладных DDoS;
• WAF;
• ограничение частоты запросов;
• фильтрация автоматического трафика;
• защита DNS;
• сегментация сети;
• ограничения доступа к служебным панелям.
  
  

Сетевая DDoS-атака пытается перегрузить канал или оборудование. Прикладная атака действует иначе. Она имитирует действия обычного пользователя и обращается к наиболее тяжелым функциям:

• поиску;
• фильтрам;
• авторизации;
• расчету стоимости;
• формированию документов;
• оформлению заказа;
• внешним интеграциям.
  
  

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

Что должно быть настроено

Базы данных, служебные панели и внутренние сервисы не должны быть доступны из интернета без необходимости.

Административные интерфейсы можно ограничить через VPN, доверенные адреса или отдельную систему доступа.

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

Что произойдет при отказе уровня

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

Основные ответственные: системный администратор или DevOps-команда.

 

Уровень 5. Зависимости и процесс развертывания

Современный сайт состоит не только из кода, который написала команда проекта.

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

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

Отдельный риск создает система автоматической сборки и развертывания. Обычно она имеет доступ:

• к исходному коду;
• рабочим серверам;
• облачной инфраструктуре;
• контейнерам;
• ключам;
• токенам;
• внутренним сетям.
  
  

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

Что должно быть настроено

Необходимо контролировать:

• список зависимостей;
• точные версии;
• происхождение пакетов;
• известные уязвимости;
• сценарии установки;
• права системы сборки;
• доступ к секретам;
• состав итогового артефакта.
  
  

Версии библиотек нужно фиксировать. Новые компоненты должны проходить проверку. Сборки из недоверенных веток не должны иметь доступ к рабочим ключам и серверам.

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

Что произойдет при отказе уровня

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

Основные ответственные: разработчики, DevOps и технический руководитель.

 

Уровень 6. Мониторинг и обнаружение атак

Даже хорошо защищенную систему могут атаковать.

Поэтому важно не только предотвращать инциденты, но и быстро замечать подозрительную активность.

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

Что должно отслеживаться

В зоне контроля должны находиться:

• создание новых администраторов;
• изменение ролей;
• массовые неудачные входы;
• авторизация из необычных мест;
• изменение системных файлов;
• установка новых модулей;
• изменение DNS;
• необычные запросы к API;
• массовые выгрузки;
• рост ошибок;
• аномальная нагрузка;
• новые исходящие соединения.
  
  

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

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

Что произойдет при отказе уровня

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

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

 

Уровень 7. Резервное копирование и восстановление

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

Резервная копия должна быть:

• регулярной;
• автоматической;
• зашифрованной;
• изолированной от основной инфраструктуры;
• защищенной отдельной учетной записью;
• проверенной на восстановление.
  
  

Копия, которую никто не пытался восстановить, не гарантирует возвращение системы в работу.

Что должно быть известно заранее

Компания должна понимать:

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

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

Поэтому восстановление работает вместе с обновлениями, мониторингом и контролем процесса разработки.

Что произойдет при отказе уровня

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

Основные ответственные: системный администратор и владелец системы.

 

Как уровни защиты подстраховывают друг друга

Семь уровней не работают по очереди. Они действуют одновременно.

Если не сработал	Возможное последствие	Что ограничивает ущерб
Защита учетной записи	Атакующий входит под администратором	Ограниченные права, мониторинг, восстановление
Безопасность приложения	Используется ошибка в коде или API	WAF, сегментация, журналы
Управление обновлениями	Эксплуатируется известная уязвимость	WAF, мониторинг, изоляция
Внешний периметр	Вредоносный трафик достигает приложения	Лимиты, кеширование, очереди
Контроль зависимостей	В сборку попадает вредоносный пакет	Минимальные права, мониторинг, доверенная сборка
Мониторинг	Атака обнаруживается с задержкой	Сегментация и ограниченные права
Восстановление	Систему нельзя быстро вернуть в работу	Остальные уровни должны ограничить разрушение

 

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

 

Чек-лист семи уровней защиты

Для каждого пункта выберите один ответ:

• да;
• нет;
• не знаю.
  
  

Ответ «не знаю» означает, что состояние защиты не подтверждено.

Уровень 1. Учетные записи

• Для CMS, хостинга, DNS и репозитория включена многофакторная аутентификация.
• У каждого сотрудника есть собственная учетная запись с ограниченными правами.
• Доступы бывших сотрудников и подрядчиков отключены.

Уровень 2. Код, CMS и API

• Права проверяются при каждом обращении к документу или объекту.
• CMS, модули и API проходят регулярную проверку безопасности.
• Загрузка файлов и восстановление доступа защищены от злоупотреблений.

Уровень 3. Обновления

• Составлен список используемых платформ и их версий.
• Компания получает уведомления о критических уязвимостях.
• Для срочных обновлений существует отдельный процесс.

Уровень 4. Внешний периметр

• Перед сайтом настроены WAF и защита от DDoS.
• Базы данных и служебные панели не открыты в интернет.
• Тестовые среды, старые поддомены и сетевые сервисы учтены.

Уровень 5. Зависимости и развертывание

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

Уровень 6. Мониторинг

• Журналы собираются централизованно и хранятся отдельно от сайта.
• Настроены уведомления об изменении прав, файлов и конфигурации.
• Определен сотрудник, который реагирует на предупреждения.

Уровень 7. Восстановление

• Резервные копии создаются автоматически и хранятся отдельно.
• Доступ к копиям защищен отдельной учетной записью.
• Восстановление проверялось на практике.
  
  

Если по трем или более пунктам выбран ответ «не знаю», состояние системы нельзя считать подтвержденным.

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

 

Почему слабые места не всегда видны

Сайт может работать стабильно и внешне не показывать никаких проблем.

При этом в системе могут оставаться:

• устаревшие библиотеки;
• открытые сетевые сервисы;
• забытые поддомены;
• небезопасные настройки сервера;
• лишние точки входа;
• компоненты с известными уязвимостями.
  
  

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

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

Для технической проверки применяют сканирование систем на наличие уязвимостей.

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

 

Вывод

Защита сайта не строится вокруг одного продукта.

WAF не заменяет безопасный код. Обновление не защищает украденную учетную запись. Мониторинг не исправляет уязвимость. Резервная копия не предотвращает повторный взлом.

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

Следующий вопрос заключается в том, как проверить, где эта система уже имеет разрывы.

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