Вступление
Сейчас почти у каждого, даже самого небольшого бизнеса, есть свои интернет-ресурсы:
- сайты-визитки (или лендинги);
- боты;
- VPN'ки;
- CMS'ки;
- а возможно, даже полноценные интернет-магазины или другие приложения.
Зачастую владельцы, которые ещё не сталкивались с последствиями взлома своих ресурсов, забивают на безопасность.
Оно и понятно. Бытует мнение, что информационная безопасность - это дорого и нужно только крупным игрокам. А у нас небольшой бизнес, кому мы вообще нужны? Да и к тому же она не приносит прибыли. Оставим ИБ для лучших времён.
Однако это совсем не так.
Проблема в том, что ваш сервер не обязательно должен представлять интерес для какого-то конкретного хакера.
Многие атаки автоматизированы. Злоумышленники постоянно сканируют доступные серверы в поисках уязвимостей, слабых паролей и ошибок конфигурации.
В этой статье я расскажу, как бы я защищал сервер небольшого бизнеса с бюджетом 0, 15 000 и 150 000 рублей.
Разберём конкретные инструменты, услуги, на которые действительно стоит потратиться, и ошибки, которых лучше избегать.
Для простоты представим, что на старте у нас один сервер с небольшим веб-приложением. Хостинг оплачен, а выделенные суммы мы можем потратить именно на безопасность.
Начнём с самого сложного варианта.
Бюджет - 0 рублей
Итак, денег на информационную безопасность у нас нет совсем.
На первый взгляд, ситуация патовая. Но даже с нулевым бюджетом можно значительно повысить защищённость сервера.
Правда, есть один нюанс: отсутствие бюджета мы будем заменять своими временем и знаниями.
В качестве инструментов будем использовать бесплатные Open Source решения, официальную документацию и, при необходимости, ИИ-помощников.
Шаг первый. Базовая безопасность сервера
Первое, что я бы сделал, привёл в порядок конфигурацию самого сервера.
- Создал бы отдельного пользователя для администрирования.
- Запретил бы прямой SSH-вход от root.
- Настроил бы авторизацию по SSH-ключам и отключил вход по паролю.
- Настроил бы Firewall, оставив открытыми только необходимые порты.
Особенно важно убедиться, что база данных, Redis, брокер сообщений и другие внутренние сервисы не доступны всему интернету без необходимости.
Далее обновил бы операционную систему, зависимости и приложения, а также настроил регулярную установку обновлений безопасности.
Если приложение позволяет, я бы изолировал его в Docker-контейнере, настроил запуск без root-прав и не выдавал контейнеру лишних привилегий.
Но важно понимать, что сам по себе Docker не делает приложение безопасным.
Также проверил бы, не лежат ли пароли, API-ключи и другие секреты в публичных репозиториях, конфигурационных файлах с небезопасными правами или прямо в коде.
Уже на этом этапе мы устраняем немало распространённых ошибок.
Шаг второй. Защита от атак
Теперь, когда базовая конфигурация приведена в порядок, я бы установил дополнительные инструменты безопасности.
В первую очередь - Open Defender.
Это Open Source агент для защиты серверов. Он позволяет обнаруживать и блокировать перебор паролей, отслеживать подозрительную активность и использует механизмы eBPF для контроля отдельных действий в системе.
Но если у нас есть сайт или веб-приложение, одной защиты сервера недостаточно.
Я бы также рассмотрел установку WAF - Web Application Firewall.
Например, BunkerWeb, в который уже интегрирован ModSecurity с правилами OWASP Core Rule Set.
WAF помогает фильтровать подозрительные HTTP-запросы и блокировать часть распространённых атак на веб-приложение.
Также можно рассмотреть Cloudflare или альтернативные сервисы защиты от DDoS-атак. Но здесь важно учитывать географию пользователей.
Например, для сайтов с российской аудиторией использование Cloudflare может приводить к проблемам с доступностью. Поэтому я бы обязательно проверил доступность ресурса у целевых пользователей и продумал резервный вариант.
Шаг третий. Проверка самого приложения
Здесь мы подходим к очень важному моменту.
Даже идеально настроенный сервер не спасёт вас от всех уязвимостей в самом приложении.
Поэтому я бы отдельно проверил:
- Аутентификацию и восстановление паролей.
- Разграничение прав пользователей.
- Возможность получить доступ к чужим данным.
- Защиту административной панели.
- Управление сессиями и возможность их отзыва.
- Загрузку файлов и обработку пользовательского ввода.
Для начала можно использовать бесплатные сканеры уязвимостей, а также самостоятельно пройтись по критичным функциям приложения.
ИИ тоже может помочь при анализе конфигурации и кода, но его рекомендации необходимо перепроверять.
Шаг четвёртый. Резервные копии и наблюдение
И ещё один пункт, который я считаю обязательным даже при нулевом бюджете, резервное копирование.
Потому что полностью исключить вероятность взлома невозможно.
Наша задача - не только усложнить атаку, но и сохранить возможность восстановить работу бизнеса, если что-то всё-таки произойдёт.
Поэтому я бы настроил автоматическое резервное копирование важных данных и конфигураций, по возможности во внешнее независимое хранилище.
Помимо этого, я бы настроил хотя бы минимальные уведомления о недоступности сайта, проблемах с резервным копированием и подозрительных событиях.
Если есть возможность потратить небольшую сумму, можно подключить Open Defender к Light Defender Dashboard, чтобы просматривать события безопасности в удобном интерфейсе и получать push-уведомления на телефон.
Итак, что у нас получилось?
Мы укрепили конфигурацию сервера, закрыли лишние точки входа, добавили защитные инструменты, проверили основные функции приложения и предусмотрели восстановление данных.
Всё это - без дополнительных затрат на коммерческие средства безопасности.
Казалось бы, отлично. Можно работать.
Но есть проблема.
Качество такой защиты почти полностью зависит от компетенций человека, который её настраивал.
Можно установить десять инструментов безопасности, но оставить одну критическую ошибку в конфигурации - и все усилия окажутся напрасными.
ИИ, конечно, сильно упростил многие задачи, но он тоже может ошибиться или пропустить важную деталь.
И вот здесь мы переходим ко второму бюджету.
Бюджет - 15 000 рублей
Теперь у нас есть 15 000 рублей.
Сумма небольшая, поэтому покупать дорогие коммерческие продукты я бы не стал.
Базовые бесплатные средства защиты из предыдущего этапа никуда не исчезают.
Вместо этого я бы использовал бюджет, чтобы компенсировать главный недостаток самостоятельной настройки - отсутствие специализированных знаний.
Здесь я вижу два варианта.
Вариант первый. Делегировать настройку специалисту
Лично я бы предпочёл именно этот подход, особенно если у владельца бизнеса нет собственного опытного администратора.
Мы обращаемся к специалисту, который занимается безопасностью серверов, и поручаем ему первоначальную настройку и усиление защиты.
Что он может сделать в рамках согласованного объёма работ?
Во-первых, проверить текущую конфигурацию сервера.
Во-вторых, обнаружить и устранить типичные ошибки: небезопасные настройки SSH, лишние открытые порты, неправильные права доступа и доступные извне внутренние сервисы.
В-третьих, настроить дополнительные инструменты защиты, например Open Defender, WAF и Firewall.
А в завершение - предоставить рекомендации по дальнейшему поддержанию безопасности.
Например, мы в Light Defender занимаемся подобной настройкой серверов, консультируем клиентов и информируем их об актуальных уязвимостях, если они затрагивают используемые ими технологии.
При этом важно заранее согласовать, что именно входит в услугу.
Потому что полноценная проверка исходного кода, глубокий пентест и круглосуточный мониторинг атак - это отдельные задачи, которые не стоит ожидать автоматически за 15 000 рублей.
Главное преимущество такого подхода в том, что мы не просто получаем список рекомендаций, а добиваемся конкретных исправлений.
Вариант второй. Заказать аудит безопасности
Второй путь - потратить бюджет на независимую проверку сервера или веб-приложения.
Это может быть аудит конфигурации, анализ внешней поверхности атаки или небольшая точечная проверка отдельных функций приложения.
Например, специалист попробует выявить ошибки авторизации, проверить доступ к административным функциям и обнаружить потенциально опасные настройки.
Такой подход позволяет посмотреть на инфраструктуру со стороны и найти проблемы, которые могли остаться незамеченными.
Но есть нюанс.
Аудит обычно заканчивается отчётом с найденными недостатками и рекомендациями.
А вот исправлять проблемы зачастую придётся самостоятельно или за дополнительные деньги.
И за 15 000 рублей не стоит рассчитывать на полноценный пентест сложного приложения с глубокой проверкой всей бизнес-логики.
Поэтому мой выбор был бы следующим.
Если я плохо разбираюсь в администрировании и безопасности, то сначала нанял бы специалиста для базовой настройки.
А если сервер уже хорошо настроен, есть опытный разработчик или администратор, то деньги разумнее направить на независимую проверку.
И здесь мы получаем главное отличие от нулевого бюджета: нашу работу оценивает человек с профильными компетенциями.
Но что делать, если бизнес не стоит на месте?
Количество клиентов увеличивается, появляются новые функции, отдельные сервисы, дополнительные серверы. И постепенно инфраструктура, которая раньше помещалась на одном VPS, становится значительно сложнее.
Вместе с ней растёт и количество потенциальных точек входа для злоумышленников.
И здесь подхода "настроили сервер один раз и забыли" уже явно недостаточно.
Давайте посмотрим, что можно сделать с бюджетом 150 000 рублей.
Бюджет - 150 000 рублей
150 000 рублей - уже неплохой бюджет на безопасность небольшого бизнеса.
Но здесь я бы немного изменил сам подход.
Представим, что наш бизнес постепенно вырос.
Если раньше у нас был один сервер, на котором работало небольшое приложение, то теперь у нас уже несколько сервисов: сайт, API, база данных, Redis, фоновые задачи, отдельная административная панель.
Всё это работает в контейнерах, а часть сервисов уже вынесена на другие серверы.
Инфраструктура стала сложнее. И вместе с этим появились новые риски.
Например, злоумышленнику удалось получить доступ к одному из контейнеров.
Что он сможет сделать дальше?
Сможет ли получить доступ к другим контейнерам? Увидит ли пароли от базы данных? Получится ли у него выбраться из контейнера или добраться до соседнего сервера?
И самое главное - узнаем ли мы вообще о том, что кто-то посторонний получил доступ к нашей инфраструктуре?
Поэтому с таким бюджетом я бы уже задумался не только о защите отдельных серверов, но и о безопасности всей инфраструктуры.
Первое - безопасность контейнерной инфраструктуры
Для начала я бы проверил, насколько безопасно организована работа наших контейнеров.
Потому что одна из распространённых ошибок - считать, что если приложение запущено в контейнере, то оно уже изолировано и достаточно защищено.
На практике это не так.
Например, контейнер может работать с избыточными привилегиями или содержать секреты, которые позволяют подключаться к другим сервисам.
В такой ситуации компрометация одного приложения может поставить под угрозу и остальные.
Поэтому первое, что я бы сделал:
- Проверил права и привилегии контейнеров.
- Разделил контейнеры по сетям, чтобы сервисы могли взаимодействовать только там, где это действительно необходимо.
- Ограничил доступ к чувствительным ресурсам хоста.
- Проверил хранение паролей, токенов и других секретов.
- Настроил сканирование контейнерных образов на известные уязвимости.
- Проверил безопасность процесса обновления и развёртывания приложений.
И здесь важно встроить такие проверки в процесс разработки, а не проводить их точечно.
Чтобы при появлении новой версии приложения мы не выкатывали в продакшен контейнер, содержащий известные критические уязвимости, без осознанного решения о риске.
Второе - централизованный мониторинг безопасности и SIEM
Следующий этап, на который я бы направил значительную часть бюджета, организация централизованного мониторинга.
Пока у нас был один сервер, отслеживать происходящее было относительно просто.
Но теперь представим, что у нас несколько серверов, на каждом десятки контейнеров, а приложения постоянно обмениваются данными.
На одном сервере появляются подозрительные попытки авторизации.
На другом внезапно запускается неизвестный процесс.
А из третьего контейнера устанавливается необычное сетевое соединение.
По отдельности такие события могут выглядеть совершенно незначительными.
Но если собрать их вместе, может оказаться, что это части одной атаки.
И вот здесь я бы уже рассмотрел развёртывание собственной небольшой SIEM-системы.
SIEM - это система, которая централизованно собирает события безопасности из разных источников, анализирует их и помогает выявлять потенциальные инциденты.
Причём необязательно покупать дорогостоящую коммерческую платформу.
Можно использовать Open Source решения, например Wazuh.
С его помощью можно собирать события с серверов, контролировать изменения важных файлов, анализировать журналы безопасности и настраивать правила обнаружения подозрительной активности.
И отдельно рассмотрел бы мониторинг происходящего внутри контейнеров.
При этом я бы не забывал и про обычный мониторинг инфраструктуры - загрузку CPU, использование памяти, доступность сервисов и состояние контейнеров.
Для этого можно использовать Prometheus и Grafana, которые уже давно стали стандартом в индустрии.
Но здесь есть очень важный момент.
Просто установить SIEM недостаточно. Её ещё нужно правильно настроить.
Необходимо определить, какие события мы собираем, какие из них представляют опасность, в каких случаях отправляем уведомления, а какие просто сохраняем для последующего анализа.
Иначе вместо защиты мы получим красивую панель с тысячами событий, которые никто не просматривает.
Поэтому я бы обязательно настроил несколько действительно полезных сценариев обнаружения атак и протестировал их на собственном стенде.
Например, подозрительные попытки входа, неожиданные изменения критичных файлов, запуск нетипичных процессов в контейнерах или появление новых привилегированных учётных записей.
И, по возможности, определил бы человека, который будет реагировать на такие уведомления.
Потому что SIEM без реагирования - это по большей части просто хранилище информации об атаках.
Третье - аудит безопасности инфраструктуры
Следующее, на что я бы потратил часть бюджета, независимый аудит.
Но теперь я бы проверял уже не только отдельный сервер или веб-приложение.
Меня интересовала бы безопасность инфраструктуры в целом.
Например:
- Можно ли из одного контейнера получить доступ к сервисам, к которым он обращаться не должен?
- Есть ли у приложений избыточные права?
- Насколько безопасно организовано хранение секретов?
- Можно ли через компрометацию одного сервиса добраться до других?
- Есть ли критичные ошибки в конфигурации Docker и сетевом взаимодействии?
- Какие внешние точки входа доступны потенциальному злоумышленнику?
Также я бы попросил специалиста отдельно проверить наиболее критичные функции приложения, если они ещё не проходили независимую проверку.
Здесь главное - определить конкретные цели аудита и согласовать его объём.
Потому что за 150 000 рублей на все задачи сразу рассчитывать не стоит, особенно если инфраструктура уже достаточно большая.
Именно поэтому я бы не пытался проверить абсолютно всё, а сфокусировался на наиболее опасных сценариях.
Четвёртое - устранение уязвимостей и проверка результата
И последний этап - исправление обнаруженных проблем.
Допустим, в результате аудита выяснилось, что один из контейнеров имеет избыточные права, другой хранит чувствительные данные в переменных окружения, доступных слишком широкому кругу процессов, а между некоторыми сервисами вообще отсутствуют необходимые сетевые ограничения.
Все эти недостатки необходимо устранить.
Но делать это нужно с учётом их критичности и возможных последствий для бизнеса.
В первую очередь я бы устранял те проблемы, которые позволяют получить несанкционированный доступ к данным, повысить привилегии или перейти от одного скомпрометированного сервиса к остальной инфраструктуре.
Заключение
Итак, давайте подведём итог.
Если у вас вообще нет бюджета на информационную безопасность, это не повод полностью её игнорировать.
Даже с бесплатными инструментами можно значительно повысить защищённость сервера, если правильно настроить операционную систему, сетевой доступ, приложения и резервное копирование.
Если у вас есть 15 000 рублей, я бы в первую очередь рассмотрел помощь специалиста, который сможет настроить сервер и устранить распространённые ошибки. Либо заказал бы аудит, если базовая безопасность уже настроена.
А при бюджете 150 000 рублей, особенно если бизнес развивается и инфраструктура становится сложнее, я бы уже задумался о защите контейнерных сред, централизованном мониторинге безопасности, аудите и устранении выявленных уязвимостей.
Но важно понимать, что само по себе увеличение бюджета не гарантирует увеличения безопасности.
Поэтому я считаю, что главное в информационной безопасности - не количество денег, а знание того, что именно мы защищаем, от каких угроз и почему.
А если вы не знаете, куда обратиться, в Light Defender есть решения под любой кошелёк.
Спасибо за чтение!