Добрый день, хабровчане! Сегодня мы поделимся c вами нашими соображениями по самостоятельной подготовке к защите в случае DDoS-атаки. Тема наболевшая, и не только среди пользователей ЖЖ и других атакуемых сайтов, но и наших специалистов проекта Kaspersky DDoS Prevention.
Особенность DDoS-атак в России
DDoS — это стихия. Прогнозировать стихию невозможно, но готовиться к ней необходимо.
Яркий пример — спасательный круг и шлюпки на кораблях. Навряд ли они спасут от всемогущего Ктулху, но со средним штормом и прочими рядовыми инцидентами вполне себе справятся.
Конечно, хотелось бы посоветовать заранее оценивать риски и иметь на примете поставщика решений по защите от DDoS-атак, иметь сценарий действий на случай атаки и т.п., но зачастую события все-таки разворачиваются так: «пока гром не грянет — мужик не перекрестится».
Оперативное принятие интернет-ресурса под защиту у всех поставщиков решений по защите от DDoS выглядит одинаково: вас попросят поменять IP-адрес в DNS-записи вашего ресурса.
Даже если вам предложат переехать на какой либо защищенный хостинг — это все равно влечет за собой смену адреса. Поэтому самые первые «спасательные средства» — это:
1. Наличие учетных данных для изменения DNS-записи в доступности;
2. Предварительное сокращение время жизни записи DNS имени ресурса до 10-15 минут.
Опыт «Лаборатории Касперского» говорит о том, что подавляющее большинство атак может быть отбито без проблем, и основное время недоступности ресурса после обращения составляет именно ожидание «переключения » пользователей.
Во-вторых — заранее уточните, какие протоколы используются в процессе работы вашего ресурса. Для некоторых владельцев ресурсов становится откровением то, что после постановки под защиту перестают работать личные кабинеты пользователей и другой подобный функционал, работающий по протоколу HTTPS.
Наши специалисты обходят сайты и пытаются выявить «скрытый» функционал, но если бы владелец ресурса изначально о нем знал — было бы проще.
Заранее проверяйте взаимодействие компонентов ресурса. Ссылки, содержащие IP-адрес или локальные пути, могут отрезать часть функционала при миграции атакуемого компонента под защиту.
Ну и, конечно, желательно не доводить ресурс до состояния, когда в мирное время он работает «на последнем издыхании». Проверить это часто затруднительно, но ждать способности стойко переносить нагрузку от сайта, размещенного на виртуальном хостинге, часто не приходится. В зависимости от атаки через любую систему защиты могут проходить некоторые паразитные запросы. Опять же, никакая система защиты не может ментально определить и отличить бота от обычного пользователя. На анализ нужно время, в течение которого от атакующего будут проходить паразитные запросы. Ресурс должен быть способен выдерживать ка минимум 10-15% повышения нагрузки. В практике «Лаборатории Касперского» бывали случаи, когда приходилось бороться за каждый лишний пропущенный запрос: в мирное время портал обрабатывал по 3 запроса в секунду, и под атакой выяснялось, что 5 запросов в секунду для него губительны.
В общем, если ресурс дорог и ценен для вашей деятельности или бизнеса — он должен соответствующим образом сопровождаться. Нам часто приходится видеть компании, которые говорят о критической важности ресурса и при этом не только не имеют систем мониторинга его работоспособности, но и администрируют ресурс силами аутсорсеров, достучаться до которых в критический момент не удается.
Очевидно, что смена администраторов в режиме 24х7 доступна и нужна не всем, но те же пароли от DNS должны быть в доступности у того человека, которому можно дозвониться в любое время.
Особенность DDoS-атак в России
DDoS — это стихия. Прогнозировать стихию невозможно, но готовиться к ней необходимо.
Яркий пример — спасательный круг и шлюпки на кораблях. Навряд ли они спасут от всемогущего Ктулху, но со средним штормом и прочими рядовыми инцидентами вполне себе справятся.
Конечно, хотелось бы посоветовать заранее оценивать риски и иметь на примете поставщика решений по защите от DDoS-атак, иметь сценарий действий на случай атаки и т.п., но зачастую события все-таки разворачиваются так: «пока гром не грянет — мужик не перекрестится».
Оперативное принятие интернет-ресурса под защиту у всех поставщиков решений по защите от DDoS выглядит одинаково: вас попросят поменять IP-адрес в DNS-записи вашего ресурса.
Даже если вам предложат переехать на какой либо защищенный хостинг — это все равно влечет за собой смену адреса. Поэтому самые первые «спасательные средства» — это:
1. Наличие учетных данных для изменения DNS-записи в доступности;
2. Предварительное сокращение время жизни записи DNS имени ресурса до 10-15 минут.
Опыт «Лаборатории Касперского» говорит о том, что подавляющее большинство атак может быть отбито без проблем, и основное время недоступности ресурса после обращения составляет именно ожидание «переключения » пользователей.
Во-вторых — заранее уточните, какие протоколы используются в процессе работы вашего ресурса. Для некоторых владельцев ресурсов становится откровением то, что после постановки под защиту перестают работать личные кабинеты пользователей и другой подобный функционал, работающий по протоколу HTTPS.
Наши специалисты обходят сайты и пытаются выявить «скрытый» функционал, но если бы владелец ресурса изначально о нем знал — было бы проще.
Заранее проверяйте взаимодействие компонентов ресурса. Ссылки, содержащие IP-адрес или локальные пути, могут отрезать часть функционала при миграции атакуемого компонента под защиту.
Ну и, конечно, желательно не доводить ресурс до состояния, когда в мирное время он работает «на последнем издыхании». Проверить это часто затруднительно, но ждать способности стойко переносить нагрузку от сайта, размещенного на виртуальном хостинге, часто не приходится. В зависимости от атаки через любую систему защиты могут проходить некоторые паразитные запросы. Опять же, никакая система защиты не может ментально определить и отличить бота от обычного пользователя. На анализ нужно время, в течение которого от атакующего будут проходить паразитные запросы. Ресурс должен быть способен выдерживать ка минимум 10-15% повышения нагрузки. В практике «Лаборатории Касперского» бывали случаи, когда приходилось бороться за каждый лишний пропущенный запрос: в мирное время портал обрабатывал по 3 запроса в секунду, и под атакой выяснялось, что 5 запросов в секунду для него губительны.
В общем, если ресурс дорог и ценен для вашей деятельности или бизнеса — он должен соответствующим образом сопровождаться. Нам часто приходится видеть компании, которые говорят о критической важности ресурса и при этом не только не имеют систем мониторинга его работоспособности, но и администрируют ресурс силами аутсорсеров, достучаться до которых в критический момент не удается.
Очевидно, что смена администраторов в режиме 24х7 доступна и нужна не всем, но те же пароли от DNS должны быть в доступности у того человека, которому можно дозвониться в любое время.
