Во время нашей ежегодной проверки безопасности мне напомнили об инциденте, произошедшем в начале этого года, когда мы получили угрозу веб-серверу нашей организации. Это было связано с политикой организации и угрожало DDoS-атакой на наш сайт. К счастью, ничего плохого из этого не вышло, и это оказалось пустой угрозой. Тем не менее, мы все равно немедленно уведомили CIO, CSO и генерального директора, а также нашего хостинг-провайдера, которые приветствовали наш ответ. Из-за характера нашей организации (в сфере образования) упреждающий ответ включал в себя участие многих людей, включая координацию с местными правоохранительными органами.
Хотя наш ответ был вполне достаточным для пустой угрозы, это заставляет меня осознать, как мало было проведено планирование атак на веб-приложение. Сейчас настройка такова:
- Linode VPS, не защищенный корпоративным брандмауэром (за этим стоит длинная история, которую не стоит объяснять)
- База данных PostgreSQL на том же сервере, которая допускает только локальные соединения
- сервер Nginx, для обеспечения безопасности которого мы в настоящее время следуем лучшим практикам [1]
- SSH-доступ, который мы переводим на аутентификацию по сертификату
- Резервный VPS, на котором установлены все последние настройки сервера, и требуется только загрузить последнюю версию кода и перенести настройки базы данных (в настоящее время используется как тестовый сервер, но также рассматривается как вариант геоизбыточности)
Думаю, мой вопрос можно свести к тому, какие еще шаги мне следует предпринять, чтобы заблокировать свой сервер и защитить его от DDoS? Мы бы с удовольствием использовалиCloudflare Бизнесс их защитой от DDoS, но она нам не всегда нужна, а 200 долларов в месяц — это немного дороговато для организации. Нужно ли мне это вообще? Есть ли решение, которое обеспечивает временную защиту от DDoS? Если нет, то каков наилучший способ поддержания стабильности во время/после атаки? Наконец, какое ведение журнала следует реализовать, чтобы мы могли помочь правоохранительным органам в случае атаки?
решение1
какие еще шаги мне следует предпринять, чтобы заблокировать свой сервер и защитить его от DDoS?
- Закройте все неиспользуемые порты и протоколы с помощью брандмауэра. Ограничьте доступ только доверенными IP-адресами, где это применимо и возможно.
- Своевременно применяйте все исправления и обновления безопасности.
- Внедрите сетевой монитор, который может предупреждать о подозрительных всплесках активности.
$200 в месяц — это немного дороговато для организации. А мне это вообще нужно?
Нет. Пока это не принесет пользу и не станет необходимостью.
Есть ли решение, обеспечивающее временную защиту от DDoS-атак?
Да. Они могут потребовать значительных предварительных вложений времени на устранение сложностей при внедрении своего сервиса DDoS. http://www.blacklotus.net/protect/emergency-ddos-protectionявляется одной из таких услуг по запросу.
Если нет, то каков наилучший способ поддержания стабильности во время/после приступа?
Просто сидите и терпите. Такова природа DDoS. Вы можете попробовать отгородиться от IP-адресов, но если атака действительно распределена... ну, это все равно, что бороться с лесным пожаром с помощью водяного пистолета.
Наконец, какое ведение журнала следует реализовать, чтобы мы могли помочь правоохранительным органам в случае атаки?
Ведите журналы входящих исходных IP-адресов и временных меток, а также любые другие соответствующие криминалистические данные. Например, если это веб-сервер, попробуйте зарегистрировать пользовательский агент, запрошенные ресурсы. Полезны такие показатели трафика, как количество пакетов в секунду и количество запросов в секунду.
DDoS сводится к математическому анализу. Если кто-то пытается вымогать у вас деньги, он делает ставку на то, что может достаточно нарушить ваш бизнес, чтобы заставить вас заплатить деньги за защиту, чтобы предотвратить это. Масштаб является фактором, легче уничтожить мелких операторов, но они могут заплатить меньше. Если вы получаете угрозу по электронной почте, лучшим способом действий будет игнорировать ее. Для инициирования и поддержания DDoS-атак требуются значительные ресурсы ботнета — они не могут просто так всех атаковать, как спамеры. Скорее всего, они просто проводят массированную фишинговую атаку в поисках легких целей для запугивания. Из-за природы зверя DDoS жертвы довольно беспомощны, если они не могут развернуть сложную схему предотвращения фильтрации пакетов или не имеют бюджета для заключения контрактов со сторонними службами.
решение2
Ответ inetplumber отличный.
Я бы добавил, что еще один вариант — настроить приложение для масштабирования, чтобы вы могли справиться с более крупной атакой, не влияя на своего пользователя. Вы можете настроить виртуальное частное облако (VPC) на Amazon AWS, например, с вашим сервером PostgreSQL, доступным только изнутри вашего VPC. Вы можете настроить интерфейс балансировщика нагрузки, чтобы распределить нагрузку между несколькими серверами.
Преимущество такого подхода в том, что вы можете быстро масштабировать до сотен (или более) серверов без первоначальных инвестиций и очень быстро (если вы уже настроены), что делает вас гораздо более сложной целью. Вам нужно будет платить за эти серверы только в те часы, когда вы фактически подвергаетесь атаке. Когда вы не подвергаетесь атаке, вам нужно будет платить только за один веб-сервер и один сервер базы данных.
Самая сложная часть — настройка, и она, безусловно, несколько сложнее, чем ваша текущая конфигурация. Настройка для быстрого масштабирования потребует еще больше работы. Но если вы ищете что-то, что вы могли бы сделать для планирования (особенно если из-за других проблем вы считаете, что можете стать целью в будущем), это то, что вам нужно.
решение3
какие еще шаги мне следует предпринять, чтобы заблокировать свой сервер и защитить его от DDoS?
если ваше веб-приложение не интерактивно и просто отображает контент: используйте nginx + proxy-cache с коротким временем кэширования (обычно достаточно 1-5 минут). Это значительно увеличивает производительность и заставляет злоумышленника выделять больше ресурсов.
настроить ограниченный брандмауэр, который фильтрует все ненужноеИ изустановив INPUT/OUTPUT/FORWARD-Policy на DROP; обязательно регистрируйте каждую исходящую попытку соединения (за исключением порта UPD 53 :)
Если вы не можете ограничить SSH статическим IP-адресом управления, используйте альтернативный порт с высоким номером, например 22222, это предотвратит множество стукачей типа «привет, mcfyl, там кто-то есть»
дополнительно используйте fail2ban/denyhosts для защиты ssh от атак методом подбора
если у вас есть административные ресурсы: используйте OSSEC и легковесный WAF (есть naxsi для nginx, легковесный и не такой PITA, как mod_security), но вам понадобится кто-то, кто будет настраивать и обслуживать такие установки
реализовать резервное копирование и использовать ваш резервный сервер в качестве цели резервного копирования
Поддерживайте актуальность кода вашего веб-приложения; если вы используете проект с открытым исходным кодом, подпишитесь на его рассылку по вопросам безопасности.
старайтесь избегать программного обеспечения, которое, как известно, имеет много уязвимостей
если вы используете admin-login и/или managament-webapps: установите basic-auth для этих логинов + ssl (подойдет самоподписанный сертификат).
используйте ssh-туннелирование, когда это возможно, вместо открытия портов, например, для разработки
Если нет, то каков наилучший способ поддержания стабильности во время/после атаки?
- сохранять спокойствие
- иметь под рукой кого-то с опытом в таком случае
- иметь наготове планы действий в чрезвычайных ситуациях
самое важное, что вы уже сделали: подумали об этом (и возможных мерах противодействия) до того, как это произойдет.