DDOS - это семейство атак, которые воздействуют на ключевые системы в центре обработки данных, включая:
- Сетевое подключение хостинг-центра к Интернету
- Внутренняя сеть и маршрутизаторы хостинг-центра
- Ваш брандмауэр и балансировщики нагрузки
- Ваши веб-серверы, серверы приложений и база данных.
Прежде чем приступить к построению защиты от DDOS-атак, подумайте, какова наихудшая величина риска. Для некритичной, бесплатной услуги для небольшого сообщества общая стоимость риска может быть ничтожной. Для платной, общедоступной и критически важной системы для устоявшегося многомиллиардного бизнеса стоимость может быть стоимостью компании. В последнем случае вам не следует использовать StackExchange :) В любом случае, чтобы защитить себя от DDOS, вам нужен всесторонний подход к защите:
- Обратитесь в свой хостинг-центр, чтобы понять, какие услуги они предлагают, включая фильтрацию IP-адресов и портов при их сетевых подключениях к Интернету и услуги межсетевого экрана, которые они предлагают. Это критически важно: многие сайты извлекаются из Интернета хостинговой компанией, поскольку хостинговая компания имеет дело с нарушениями работы центра обработки данных, вызванными DDOS для одного клиента. Кроме того, во время DDOS-атаки вы будете очень тесно сотрудничать с персоналом хостингового центра, поэтому знайте их номера экстренных служб и будьте в хороших отношениях с ними :) Они должны иметь возможность блокировать целые международные регионы, полностью блокировать определенные службы или сеть. протоколы и другие защитные меры широкого спектра, или, альтернативно, разрешить только IP-адреса из белого списка (в зависимости от вашей бизнес-модели)
- Находясь в хостинг-центре - используйте сеть доставки контента для распространения (в основном статических) сервисов рядом с вашими конечными пользователями и сокрытия ваших реальных серверов от архитекторов DDOS. Полный CDN слишком велик для того, чтобы DDOS уничтожил все узлы во всех странах; если DDOS ориентирован на одну страну, по крайней мере, другие пользователи все еще в порядке.
Обновляйте все свои системы и программные пакеты с помощью последних исправлений безопасности - я имею в виду все из них:
- Управляемые коммутаторы - иногда их нужно обновить
- Маршрутизаторы
- Межсетевые экраны
- Балансировщики нагрузки
- Операционные системы
- Веб-серверы
- Языки и их библиотеки
Убедитесь , что у вас есть хороший брандмауэр или безопасности прибора установить и регулярно пересматриваться квалифицированным экспертом безопасности . Строгие правила брандмауэра - хорошая защита от многих простых атак. Также полезно иметь возможность управлять пропускной способностью, доступной для каждой открытой службы.
Используйте хорошие инструменты для мониторинга сети - это поможет вам понять:
- Что вас атакуют, а не просто тяжелая нагрузка
- Откуда исходит атака (включая страны, с которыми вы обычно не ведете бизнес) и
- Что на самом деле представляет собой атака (порты, службы, протоколы, IP-адреса и содержимое пакетов)
Атака может быть просто интенсивным использованием законных сервисов веб-сайта (например, попадание в «законные» URI, выполняющие запросы или вставка / обновление / удаление данных) - тысячи или миллионы запросов, поступающих с десятков или миллионов различных IP-адресов, приведут сайт к его колени. В качестве альтернативы, некоторые службы могут быть настолько дорогими в эксплуатации, что только несколько запросов вызывают DOS - подумайте, действительно, дорогой отчет. Итак, вам нужен хороший мониторинг того, что происходит на уровне приложения :
- Какие службы были вызваны и какие аргументы / данные были отправлены (например, вход в ваше приложение)
- Какие пользователи выполняют вызов и с каких IP-адресов (например, входят в ваше приложение)
- Какие запросы и вставки / обновления / удаления выполняет БД
- Средняя нагрузка, использование ЦП, дисковый ввод-вывод, сетевой трафик на всех компьютерах (и виртуальных машинах) в вашей системе
- Убедитесь, что всю эту информацию легко получить и что вы можете сопоставить журналы с разных компьютеров и служб (то есть обеспечить синхронизацию времени на всех компьютерах с помощью ntp).
Разумные ограничения и ограничения в вашем приложении . Например, вы можете:
- Используйте функцию QoS в балансировщике нагрузки, чтобы отправлять все анонимные сеансы на отдельные серверы приложений в кластере, в то время как вошедшие в систему пользователи используют другой набор. Это предотвращает анонимный DDOS на уровне приложения, уводящий ценных клиентов.
- Использование сильной CAPCHA для защиты анонимных сервисов
- Таймауты сеанса
- Установите ограничение сеанса или скорости для определенных типов запросов, например отчетов. Убедитесь, что вы можете отключить анонимный доступ при необходимости.
- Убедитесь, что у пользователя есть ограничение на количество одновременных сеансов (чтобы предотвратить вход в систему взломанной учетной записи миллион раз)
- Иметь разных пользователей приложения базы данных для разных сервисов (например, использование транзакций или использование отчетов) и использовать управление ресурсами базы данных, чтобы один тип веб-запроса не подавлял все остальные.
- Если возможно, сделайте эти ограничения динамическими или, по крайней мере, настраиваемыми. Таким образом, пока вы находитесь под атакой, вы можете установить агрессивные временные ограничения («дросселирование» атаки), например, только один сеанс для каждого пользователя и запретить анонимный доступ. Это, конечно, не очень хорошо для ваших клиентов, но намного лучше, чем полное отсутствие обслуживания.
И последнее, но не менее важное: напишите документ с планом реагирования DOS и получите его на внутреннюю проверку всеми соответствующими сторонами: бизнесом, менеджментом, командой разработчиков ПО, ИТ-командой и экспертом по безопасности. Процесс написания документа заставит вас и вашу команду обдумать проблемы и поможет вам подготовиться, если худшее случится в 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 :)
Дуг МакКлин есть отличный совет: https://stackoverflow.com/a/1029613/1395668