Ответ 1
DDOS - это семейство атак, которые подавляют ключевые системы в центре данных, включая:
- Сетевое подключение хостинга к Интернету
- Внутренняя сеть хостинга и маршрутизаторы
- Ваш брандмауэр и балансировки нагрузки
- Ваши веб-серверы, серверы приложений и база данных.
Прежде чем приступать к созданию защиты от DDOS, подумайте о том, что такое наихудшее значение для риска. Для некритического, бесплатного использования для небольшого сообщества общая стоимость риска может быть арахисами. Для платной, ориентированной на общественность, критически важной системы для создания многомиллиардного бизнеса стоимость может стоить компании. В этом последнем случае вы не должны использовать StackExchange:) Во всяком случае, чтобы защитить от DDOS, вам нужен углубленный подход защиты:
- Работайте со своим центром хостинга, чтобы понять предлагаемые ими услуги, включая фильтрацию IP и портов при их сетевых подключениях к Интернету и услугам брандмауэра, которые они предлагают. Это очень важно: многие сайты вытаскиваются из Интернета хостинговой компанией, так как хостинговая компания занимается разрывом центра обработки данных, вызванным DDOS для одного клиента. Кроме того, во время DDOS-атаки вы будете очень тесно работать с персоналом хостингового центра, поэтому узнайте их номера экстренных служб и будьте в хороших отношениях с ними:) Они должны иметь возможность блокировать целые международные регионы, полностью блокировать определенные услуги или сеть протоколов и других защитных мер широкого спектра или, альтернативно, разрешать только белые списки IP-адресов (в зависимости от вашей бизнес-модели).
- В хостинговом центре используйте Сеть доставки контента, чтобы распространять (в основном статические) службы, близкие к вашим конечных пользователей и скрыть реальные серверы от архитекторов DDOS. Полный CDN слишком велик для DDOS, чтобы вывести все узлы во всех странах; если DDOS ориентирована на одну страну, по крайней мере другие пользователи все еще в порядке.
-
Сохраняйте все свои системные и программные пакеты с последними исправлениями безопасности - и я имею в виду все:
- Управляемые коммутаторы - иногда им требуется обновление
- Маршрутизаторы
- Брандмауэры
- Балансиры нагрузки
- Операционные системы
- Веб-серверы
- Языки и их библиотеки
-
Убедитесь, что у вас есть хороший брандмауэр или устройство безопасности, и он регулярно проверяется квалифицированным специалистом по безопасности. Сильные правила брандмауэра - хорошая защита от многих простых атак. Также полезно иметь возможность управлять пропускной способностью, доступной для каждой открытой службы.
-
У вас есть хорошие инструменты сетевого мониторинга - это может помочь вам понять:
- Чтобы вы были атакованы, а не просто находились под большой нагрузкой
- Где происходит атака (которая может включать страны, с которыми вы обычно не работаете) и
- На самом деле атака (порты, службы, протоколы, IP-адреса и содержимое пакета)
-
Атака может быть просто чрезмерным использованием законных сервисов веб-сайтов (например, попадание "законных" URI-запросов, выполняющих запросы или вставка/обновление/удаление данных) - тысячи или миллионы запросов, поступающих с десятков до миллионов разных IP-адресов принесет сайт на колени. В качестве альтернативы, некоторые службы могут быть настолько дорогими для запуска, что только несколько запросов вызывают DOS - считайте действительно дорогой отчет. Итак, вам нужен хороший мониторинг уровня приложения того, что происходит:
- Какие службы были вызваны и какие аргументы/данные отправлены (т.е. протоколирование в вашем приложении)
- Какие пользователи выполняют вызовы и с каких IP-адресов (т.е. регистрируются в вашем приложении)
- Какие запросы и вставки/обновления/удаления БД выполняет
- Средняя загрузка, загрузка процессора, дисковый ввод/вывод, сетевой трафик на всех компьютерах (и виртуальных машинах) в вашей системе.
- Убедитесь, что вся эта информация легко извлекается и что вы можете сопоставлять журналы с разных компьютеров и служб (т.е. обеспечить синхронизацию всех компьютеров с помощью ntp).
-
Разумные ограничения и ограничения в приложении. Например, вы можете:
- Используйте функцию QoS в балансировщике нагрузки для отправки всех анонимных сеансов для разделения серверов приложений в вашем кластере, а вошедшие в систему пользователи используют другой набор. Это предотвращает анонимное DDOS-приложение на уровне приложений, получающее ценные клиенты.
- Использование сильной CAPCHA для защиты анонимных сервисов
- Тайм-ауты сеанса
- У вас есть ограничение по сеансу или ограничение скорости для определенных типов запросов, таких как отчеты. Убедитесь, что вы можете отключить анонимный доступ в случае необходимости
- Убедитесь, что у пользователя есть ограничение на количество одновременных сеансов (чтобы предотвратить запись взломанной учетной записи в миллион раз)
- Для разных служб (например, использование транзакций и использования отчетов) используются разные пользователи приложений баз данных и используют управление ресурсами базы данных, чтобы предотвратить подавление всех типов веб-запросов одним типом.
- Если возможно, эти ограничения являются динамическими или, по крайней мере, настраиваемыми. Таким образом, в то время как вы находитесь под атакой, вы можете установить агрессивные временные ограничения на месте ( "дросселировать" атаку), например, только один сеанс на пользователя и отсутствие анонимного доступа. Это, конечно, не очень удобно для ваших клиентов, но намного лучше, чем вообще не иметь услуги.
-
Наконец, напишите документ DOS Response Plan и получите внутреннюю проверку всеми заинтересованными сторонами: бизнес, менеджмент, команда разработчиков SW, команда ИТ и безопасность эксперт. Процесс написания документа заставит вас и вашу команду продумать проблемы и помочь вам подготовиться, если худшее произойдет в 3 часа ночи в выходной день. Документ должен охватывать (помимо всего прочего):
- Что находится под угрозой, и стоимость бизнеса.
- Меры, принятые для защиты активов
- Как обнаружена атака
- Плановая реакция и процедура эскалации
- Процессы для обновления системы и настоящего документа.
Итак, преамбула в сторону, вот некоторые конкретные ответы:
DDOS обычно блокируются на уровне сервера, правильно?
Не совсем - большинство худших DDOS-атак являются низкоуровневыми (на уровне IP-пакетов) и обрабатываются правилами маршрутизации, брандмауэрами и устройствами безопасности, разработанными для обработки DDOS-атак.
Есть ли способ заблокировать его на уровне PHP или, по крайней мере, уменьшить его?
Некоторые атаки DDOS нацелены на само приложение, отправляя действительные URI и HTTP-запросы. Когда скорость запросов возрастает, ваш сервер начинает бороться, и вы будете иметь отказ от SLA. В этом случае есть вещи, которые вы можете сделать на уровне PHP:
-
Мониторинг уровня приложений. Обеспечьте, чтобы каждый запрос журнала услуг/страниц был таким, чтобы вы могли видеть, что происходит (чтобы вы могли предпринять действия для смягчения атаки). Некоторые идеи:
-
Имейте формат журнала, который можно легко загрузить в инструмент журнала (или Excel или аналогичный) и проанализировать с помощью средств командной строки (grep, sed, awk). Помните, что DDOS будет генерировать миллионы строк журнала. Вам, скорее всего, потребуется отрезать ваши журналы (особенно в отношении URI, времени, IP и пользователя), чтобы выработать то, что происходит, и вам необходимо создать такие данные, как:
- Доступ к URI
- То, что URI не работает с высокой скоростью (вероятный индикатор конкретных URI, атакующих атакующих)
- Какие пользователи обращаются к службе
- Сколько IP-адресов каждый пользователь получает доступ к сервису из
- Какие URI являются анонимными пользователями, обращающимися к
- Какие аргументы используются для данной службы
- Аудит определенных действий пользователей.
-
Запишите IP-адрес каждого запроса. НЕ ОТКРЫВАЙТЕ DNS это - по иронии судьбы, стоимость этого делает DDOS легче для злоумышленников
- Запишите весь метод URI и HTTP, например "GET http://example.com/path/to/service?arg1=ddos"
- Введите идентификатор пользователя, если он есть
- Зарегистрировать важные HTTP-аргументы
-
-
Пределы чувствительной скорости: вы можете использовать ограничения на количество запросов, которые данный IP-адрес или пользователь может сделать за определенный период времени. Может ли законный клиент делать более 10 запросов в секунду? Могут ли анонимные пользователи получить доступ к дорогостоящим отчетам?
-
CAPTCHA для анонимного доступа: выполните CAPTCHA для всех анонимных запросов, чтобы убедиться, что пользователь является человеком, а не бот DDOS.
Какой самый быстрый и самый распространенный способ остановить атаки DDOS?
Самый быстрый, вероятно, должен уступить шантажу, хотя это может быть нежелательно.
В противном случае первое, что вам нужно сделать, это связаться с вашим хостингом и/или поставщиком CDN и работать с ними (если они не связались с вами, вы уже спрашиваете, что, черт возьми, происходит...). При возникновении DDOS это, скорее всего, косвенно повлияет на других клиентов хостинг-провайдера, и провайдер может испытывать значительное давление, чтобы закрыть свой сайт просто для защиты своих ресурсов. Будьте готовы делиться своими журналами (любой информацией и информацией) с поставщиком; эти журналы, в сочетании с их сетевыми мониторами, могут вместе предоставить достаточную информацию для блокировки/смягчения атаки.
Если вы ожидаете DDOS, это очень хорошая идея, чтобы квалифицировать вашего хостинг-провайдера на уровень защиты, который они могут предоставить. У них должен быть опыт DDOS и инструменты для его смягчения - понимать их инструменты, процессы и процедуры эскалации. Также спросите о том, какую поддержку у хостинг-провайдера у своих провайдеров. Эти услуги могут означать больше авансовых или ежемесячных затрат, но рассматривают это как страховой полис.
Во время атаки вам нужно будет захватить ваши журналы и добыть их - попробуйте разработать шаблон атаки. Вы должны рассмотреть возможность отключения анонимного доступа и дросселирования служб под атакой (т.е. Снизить предел скорости передачи для службы).
Если вам повезет, и у вас небольшая фиксированная клиентская база, вы сможете определить свои действительные IP-адреса клиентов. Если это так, вы можете переключиться на подход белого списка на короткое время. Убедитесь, что все ваши клиенты знают, что это происходит, чтобы они могли звонить, если им нужно получить доступ с нового IP:)
Doug McClean имеет отличный совет: fooobar.com/questions/81721/...