Wi-fi

Новая услуга: защита от DDoS-атак. Kaspersky DDoS Protection Непрерывная работа вашего бизнеса Защита от ddos атаки

DoS (от англ. Denial of Service - отказ в обслуживании) - атака на вычислительную систему (обычно совершенная хакерами) с целью довести её до отказа, то есть создание таких условий, при которых легитимные пользователи системы не могут получить доступ к предоставляемым системным ресурсам (серверам), либо этот доступ затруднён.

В настоящее время DoS и DDoS-атаки наиболее популярны, так как позволяют довести до отказа практически любую систему, не оставляя юридически значимых улик. Стоимость организации атаки ничтожно мала. Атака в 10Gbit/s длительностью в час стоит около 50 долларов/евро, и ее может организовать любой желающий, зашедший на специальный хакерский сервис в интернете. Если атака выполняется одновременно с большого числа компьютеров, говорят о DDoS-атаке (от англ. Distributed Denial of Service, распределённая атака типа «отказ в обслуживании»). В современных условиях в DDoS атаки вовлекают не только компьютеры, но и другие потребительские приборы с выходом в интернет.

Первым делом злоумышленник сканирует сеть с помощью специально подготовленных сценариев, которые выявляют потенциально слабые узлы. Выбранные узлы подвергаются нападению, и злоумышленник получает на них права администратора. На захваченные узлы устанавливаются троянские программы, которые работают в фоновом режиме. Теперь эти компьютеры называются компьютерами-зомби: их пользователи даже не подозревают, что являются потенциальными участниками DDoS-атаки.

Далее злоумышленник отправляет определенные команды захваченным компьютерам, и те, в свою очередь, осуществляют мощную DoS-атаку на целевой интернет-сервис. В некоторых случаях к фактической DDoS-атаке приводит непреднамеренное действие, например, размещение на популярном интернет-ресурсе ссылки на сайт, расположенный на не очень производительном сервере (слэшдот-эффект). Большой наплыв пользователей приводит к превышению допустимой нагрузки на сервер и, следовательно, отказу в обслуживании части из них.

По методу воздействия различают:

DDoS-атаки сетевого уровня (L3-4) , которые ограничивают работу серверного оборудования или нарушают работу программного обеспечения за счёт уязвимости протоколов.

DDoS-атаки на уровне приложений (L7) , которые атакуют «слабые» места интернет-сайта, действуют направленно, отличаются минимальным потреблением ресурсов, преобладают по количеству и требуют сложного и дорогостоящего «противоядия».

Заголовки новостей сегодня пестрят сообщениями о DDoS-атаках (Distributed Denial of Service). Распределенным атакам «отказ в обслуживании» подвержены любые организации, присутствующие в интернете. Вопрос не в том, атакуют вас, или нет, а в том, когда это случится. Государственные учреждения, сайты СМИ и электронной коммерции, сайты компаний, коммерческих и некоммерческих организаций – все они являются потенциальными целями .

Кого атакуют?

По данным ЦБ, в 2016 году количество на российские финансовые организации увеличилось почти вдвое. В ноябре DDoS-атаки были направлены на пять крупных российских банков. В конце прошлого года ЦБ сообщал о DDoS-атаках на финансовые организации, в том числе Центральный банк. «Целью атак было нарушение работы сервисов и, как следствие, подрыв доверия к этим организациям. Данные атаки были примечательны тем, что это было первое масштабное использование в России интернета вещей. В основном в атаке были задействованы интернет-видеокамеры и бытовые роутеры», - отмечали в службах безопасности крупных банков.

При этом DDoS-атаки существенного ущерба банкам не принесли – они неплохо защищены, поэтому такие атаки, хотя и доставляли неприятности, но не носили критический характер и не нарушили ни одного сервиса. Тем не менее, можно констатировать, что антибанковская активность хакеров значительно увеличилась.

В феврале 2017 года технические службы Минздрава России отразили самую масштабную за последние годы DDoS-атаку, которая в пиковом режиме достигала 4 миллионов запросов в минуту. Предпринимались и DDoS-атаки на государственные реестры, но они также были безуспешны и не привели к каким-либо изменениям данных.

Однако жертвами DDoS-атак становятся как многочисленные организации и компании, на обладающие столь мощной «обороной». В 2017 году ожидается рост ущерба от киберугроз – программ-вымогателей, DDoS и атак на устройства интернета вещей.

Устройства IoT приобретают все большую популярность в качестве инструментов для осуществления DDoS-атак. Знаменательным событием стала предпринятая в сентябре 2016 года DDoS-атака с помощью вредоносного кода Mirai. В ней в роли средств нападения выступили сотни тысяч камер и других устройств из систем видеонаблюдения.

Она была осуществлена против французского хостинг-провайдера OVH. Это была мощнейшая DDoS-атака – почти 1 Тбит/с. Хакеры с помощью ботнета задействовали 150 тыс. устройств IoT, в основном камеры видеонаблюдения. Атаки с использованием ботнета Mirai положили начало появлению множества ботнетов из устройств IoT. По мнению экспертов, в 2017 году IoT-ботнеты по-прежнему будут одной из главных угроз в киберпространстве.

По данным отчета «2016 Verizon data breach incident report» (DBIR), в прошлом году количество DDoS-атак заметно выросло. В мире больше всего страдает индустрия развлечений, профессиональные организации, сфера образования, ИТ, ритейл.

Примечательная тенденция DDoS-атак – расширения «списка жертв». Он включает теперь представителей практически всех отраслей. Кроме того, совершенствуются методы нападения.
По данным Nexusguard, в конце 2016 года заметно выросло число DDoS-атак смешанного типа - с использованием сразу нескольких уязвимостей. Чаще всего им подвергались финансовые и государственные организации. Основной мотив кибепреступников (70% случаев) – кража данных или угроза их уничтожения с целью выкупа. Реже – политические или социальные цели. Вот почему важна стратегия защиты. Она может подготовиться к атаке и минимизировать ее последствия, снизить финансовые и репутационные риски.

Последствия атак

Каковы последствия DDoS-атаки? Во время атаки жертва теряет клиентов из-за медленной работы или полной недоступности сайта, страдает репутация бизнеса. Сервис-провайдер может заблокировать IP-адрес жертвы, чтобы минимизировать ущерб для других клиентов. Чтобы все восстановить, потребуется время, а возможно и деньги.

По данным опроса компании HaltDos , DDoS-атаки рассматриваются половиной организаций как одна из самых серьезных киберугроз. Опасность DDoS даже выше, чем опасность несанкционированного доступа, вирусов, мошенничества и фишинга, не говоря о прочих угрозах.

Средние убытки от DDoS-атак оцениваются по миру в 50 тыс. долларов для небольших организаций и почти в 500 тыс. долларов для крупных предприятий. Устранение последствий DDoS-атаки потребует дополнительного рабочего времени сотрудников, отвлечения ресурсов с других проектов на обеспечение безопасности, разработки плана обновления ПО, модернизации оборудования и пр.

Репутация атакованной организации может пострадать не только из-за плохой работы сайта, но и из-за кражи персональных данных или финансовой информации.

По данным опроса компании HaltDos , количество DDoS-атак растет ежегодно на 200%, ежедневно в мире сообщают о 2 тыс. атаках такого типа. Стоимость организации DDoS-атаки недельной продолжительности – всего порядка 150 долларов, а потери жертвы в среднем превышают 40 тыс. долларов в час.

Типы DDoS-атак

Основные типы DDoS-атак: массированные атаки, атаки на протокольном уровне и атаки на уровне приложений. В любом случае цель состоит в том, чтобы вывести сайт из строя или же украсть данные. Другой вид киберпреступлений – угроза совершения DDoS-атаки для получения выкупа. Этим славятся такие хакерские группировки как Armada Collective, Lizard Squad, RedDoor и ezBTC.

Организация DDoS-атак заметно упростилась: сейчас есть широко доступные автоматизированные инструменты, практически не требующие от киберпреступников специальных знаний. Существуют и платные сервисы DDoS для анонимной атаки цели. Например, сервис vDOS предлагает свои услуги, не проверяя, является ли заказчик владельцем сайта, желающим протестировать его «под нагрузкой», или это делается с целью атаки.

DDoS-атаки представляют собой атаки из многих источников, препятствующие доступу легитимных пользователей к атакуемому сайту. Для этого в атакуемую систему направляется огромное количество запросов, с которыми та справиться не может. Обычно для этой цели используются скомпрометированные системы.

Ежегодный рост количества DDoS-атак оценивается в 50% (по сведениям www.leaseweb.com), но данные разных источников расходятся, на и не все инциденты становятся известными. Средняя мощность DDoS-атак Layer 3/4 выросла в последние годы с 20 до нескольких сотен Гбайт/с. Хотя массовые DDoS-атаки и атаки на уровне протоколов уже сами по себе – штука неприятная, киберпреступники все чаще комбинируют их с DDoS-атаками Layer 7, то есть на уровне приложений, которые нацелены на изменение или кражу данных. Такие «многовекторные» атаки могут быть очень эффективными.

Многовекторные атаки составляют порядка 27% от общего числа атак DDoS.

В случае массовой DDoS-атаки (volume based) используется большое количество запросов, нередко направляемых с легитимных IP-адресов, чтобы сайт «захлебнулся» в трафике. Цель таких атак – «забить» всю доступную полосу пропускания и перекрыть легитимный трафик.

В случае атаки на уровне протокола (например, UDP или ICMP) целью является исчерпание ресурсов системы. Для этого посылаются открытые запросы, например, запросы TCP/IP c поддельными IP, и в результате исчерпания сетевых ресурсов становится невозможной обработка легитимных запросов. Типичные представители - DDoS-атаки, известные в узких кругах как Smurf DDos, Ping of Death и SYN flood. Другой вид DDoS-атак протокольного уровня состоит в отправке большого числа фрагментированных пакетов, с которыми система не справляется.

DDoS-атаки Layer 7 – это отправка безобидных на вид запросов, которые выглядят как результат обычных действий пользователей. Обычно для их осуществления используют ботнеты и автоматизированные инструменты. Известные примеры - Slowloris, Apache Killer, Cross-site scripting, SQL-injection, Remote file injection.

В 2012–2014 годах большинство массированных DDoS-атак были атаками типа Stateless (без запоминания состояний и отслеживания сессий) – они использовали протокол UDP. В случае Stateless в одной сессии (например, открытие страницы) циркулирует много пакетов. Кто начал сессию (запросил страницу), Stateless-устройства, как правило, не знают.

Протокол UDP подвержен спуфингу – замене адреса. Например, если нужно атаковать сервер DNS по адресу 56.26.56.26, используя атаку DNS Amplification, то можно создать набор пакетов с адресом отправителя 56.26.56.26 и отправить их DNS-серверам по всему миру. Эти серверы пришлют ответ по адресу 56.26.56.26.

Тот же метод работает для серверов NTP, устройств с поддержкой SSDP. Протокол NTP – едва ли не самый популярный метод: во второй половине 2016 года он использовался в 97,5% DDoS-атак.
Правило Best Current Practice (BCP) 38 рекомендует провайдерам конфигурировать шлюзы для предотвращения спуфинга – контролируется адрес отправителя, исходная сеть. Но такой практике следуют не все страны. Кроме того, атакующие обходят контроль BCP 38, переходя на атаки типа Stateful, на уровне TCP. По данным F5 Security Operations Center (SOC), в последние пять лет такие атаки доминируют. В 2016 году TCP-атак было вдвое больше, чем атак с использованием UDP.

К атакам Layer 7 прибегают в основном профессиональные хакеры. Принцип следующий: берется «тяжелый» URL (с файлом PDF или запросом к крупной БД) и повторяется десятки или сотни раз в секунду. Атаки Layer 7 имеют тяжелые последствия и трудно распознаются. Сейчас они составляют около 10% DDoS-атак.

Соотношение разных типов DDoS-атак по данным отчета Verizon Data Breach Investigations Report (DBIR) (2016 год).

Нередко DDoS-атаки приурочивают к периодам пикового трафика, например, к дням интернет-распродаж. Большие потоки персональных и финансовых данных в это время привлекают хакеров.

DDoS-атаки на DNS

Доменная система имен (Domain Name System, DNS) играет фундаментальную роль в производительности и доступности сайта. В конечном счете – в успехе вашего бизнеса. К сожалению, инфраструктура DNS часто становится целью DDoS-атак. Подавляя инфраструктуру DNS, злоумышленники могут нанести ущерб вашему сайту, репутации вашей компании и повлиять ее финансовые показатели. Чтобы противостоять современным угрозам, инфраструктура DNS должна быть весьма устойчивой и масштабируемой.

По существу DNS – распределенная база данных, которая, кроме всего прочего, ставит в соответствие удобные для чтения имена сайтов IP-адресам, что позволяет пользователю попасть на нужный сайт после ввода URL. Первое взаимодействие пользователя с сайтом начинается с DNS-запросов, отправляемых на сервер DNS с адресом интернет-домена вашего сайта. На их обработку может приходиться до 50% времени загрузки веб-страницы. Таким образом, снижение производительности DNS может приводить к уходу пользователей с сайта и потерям для бизнеса. Если ваш сервер DNS перестает отвечать в результате DDoS-атаки, то на сайт никто попасть не сможет.

DDoS-атаки трудно обнаружить, особенно вначале, когда трафик выглядит нормальным. Инфраструктура DNS может подвергаться различным типам DDoS-атак. Иногда это прямая атака на серверы DNS. В других случаях используют эксплойты, задействуя системы DNS для атаки на другие элементы ИТ-инфраструктуры или сервисы.

При атаках DNS Reflection цель подвергается массированным подложным ответам DNS. Для этого применяют бот-сети, заражая сотни и тысячи компьютеров. Каждый бот в такой сети генерирует несколько DNS-запросов, но в качестве IP источника использует один и тот же IP-адрес цели (спуфинг). DNS-сервис отвечает по этому IP-адресу.

При этом достигается двойной эффект. Целевую систему бомбардируют тысячи и миллионы ответов DNS, а DNS-сервер может «лечь», не справившись с нагрузкой. Сам запрос DNS – это обычно менее 50 байт, ответ же раз в десять длиннее. Кроме того, сообщения DNS могут содержать немало другой информации.

Предположим, атакующий выдал 100 000 коротких запросов DNS по 50 байт (всего 5 Мбайт). Если каждый ответ содержит 1 Кбайт, то в сумме это уже 100 Мбайт. Отсюда и название – Amplification (усиление). Комбинация атак DNS Reflection и Amplification может иметь очень серьезные последствия.

Запросы выглядят как обычный трафик, а ответы – это множество сообщений большого размера, направляемых на целевую систему.

Как защититься от DDoS-атак?

Как же защититься от DDoS-атак, какие шаги предпринять? Прежде всего, не стоит откладывать это «на потом». Какие-то меры следует принимать во внимание при конфигурировании сети, запуске серверов и развертывании ПО. И каждое последующее изменение не должно увеличивать уязвимость от DDoS-атак.

Безопасность программного кода. При написании ПО должны приниматься во внимание соображения безопасности. Рекомендуется следовать стандартам «безопасного кодирования» и тщательно тестировать программное обеспечение, чтобы избежать типовых ошибок и уязвимостей, таких как межсайтовые скрипты и SQL-инъекции.
Разработайте план действий при обновлении программного обеспечения. Всегда должна быть возможность «отката» в том случае, если что-то пойдет не так.
Своевременно обновляйте ПО. Если накатить апдейты удалось, но при этом появились проблемы, см. п.2.
Не забывайте про ограничение доступа. Аккаунты admin и/или должны быть защищены сильными и регулярно сменяемыми паролями. Необходим также периодический аудит прав доступа, своевременное удаление аккаунтов уволившихся сотрудников.
Интерфейс админа должен быть доступен только из внутренней сети или через VPN. Своевременно закрывайте VPN-доступ для уволившихся и тем более уволенных сотрудников.
Включите устранение последствий DDoS-атак в план аварийного восстановления. План должен предусматривать способы выявления факта такой атаки, контакты для связи с интернет- или хостинг-провайдером, дерево «эскалации проблемы» для каждого департамента.
Сканирование на наличие уязвимостей поможет выявить проблемы в вашей инфраструктуре и программном обеспечении, снизить риски. Простой тест OWASP Top 10 Vulnerability выявит наиболее критичные проблемы. Полезными также будут тесты на проникновение – они помогут найти слабые места.
Аппаратные средства защиты от DDoS-атак могут быть недешевы. Если ваш бюджет такого не предусматривает, то есть хорошая альтернатива – защита от DDoS «по требованию». Такую услугу можно включать простым изменением схемы маршрутизации трафика в экстренной ситуации, либо находится под защитой постоянно.
Используйте CDN-партнера. Сети доставки контента (Content Delivery Network) позволяют доставлять контент сайта посредством распределенной сети. Трафик распределяется по множеству серверов, уменьшается задержка при доступе пользователей, в том числе географически удаленных. Таким образом, хотя основное преимущество CDN – это скорость, она служит также барьером между основным сервером и пользователями.
Используйте Web Application Firewall – файрвол для веб-приложений. Он мониторит трафик между сайтом или приложением и браузером, проверяя легитимность запросов. Работая на уровне приложений, WAF может выявлять атаки по хранимым шаблонам и выявлять необычное поведение. Атаки на уровне приложений нередки в электронной коммерции. Как и в случае CDN, можно воспользоваться сервисами WAF в облаке. Однако конфигурирование правил требует некоторого опыта. В идеале защитой WAF должны быть обеспечены все основные приложения.

Защита DNS

А как защитить инфраструктуру DNS от DDoS-атак? Обычные файрволы и IPS тут не помогут, они бессильны против комплексной DDoS-атаки на DNS. На самом деле брандмауэры и системы предотвращения вторжений сами являются уязвимыми для атак DDoS.

На выручку могут прийти облачные сервисы очистки трафика: он направляется в некий центр, где проверяется и перенаправляется обратно по назначению. Эти услуги полезны для TCP-трафика. Те, кто сами управляют своей инфраструктурой DNS, могут для ослабления последствий DDoS-атак принять следующие меры.

Мониторинг DNS-серверов на предмет подозрительной деятельности является первым шагом в деле защиты инфраструктуры DNS. Коммерческие решения DNS и продукты с открытым исходным кодом, такие как BIND, предоставляют статистику в реальном времени, которую можно использоваться для обнаружения атак DDoS. Мониторинг DDoS-атак может быть ресурсоемкой задачей. Лучше всего создать базовый профиль инфраструктуры при нормальных условиях функционирования и затем обновлять его время от времени по мере развития инфраструктуры и изменения шаблонов трафика.
Дополнительные ресурсы DNS-сервера помогут справиться с мелкомасштабными атаками за счет избыточности инфраструктуры DNS. Ресурсов сервера и сетевых ресурсов должно хватать не обработку большего объема запросов. Конечно, избыточность стоит денег. Вы платите за серверные и сетевые ресурсы, которые обычно не используются в нормальных условиях. И при значительном «запасе» мощности этот подход вряд ли будет эффективным.
Включение DNS Response Rate Limiting (RRL) снизит вероятность того, что сервер будет задействован в атаке DDoS Reflection – уменьшится скорость его реакции на повторные запросы. RRL поддерживают многие реализации DNS.
Используйте конфигурации высокой доступности. Можно защититься от DDoS-атак путем развертывания службы DNS на сервере высокой доступности (HA). Если в результате атаки «упадет» один физический сервер, DNS-служба может быть восстановлена на резервном сервере.

Лучшим способом защиты DNS от DDoS-атак будет использование географически распределенной сети Anycast. Распределенные сети DNS могут быть реализованы с помощью двух различных подходов: адресации Unicast или Anycast. Первый подход намного проще реализовать, но второй гораздо более устойчив к DDoS-атакам.

В случае Unicast каждый из серверов DNS вашей компании получает уникальный IP-адрес. DNS поддерживает таблицу DNS-серверов вашего домена и соответствующих IP-адресов. Когда пользователь вводит URL, для выполнения запроса выбирается один из IP-адресов в случайном порядке.

При схеме адресации Anycast разные серверы DNS используют общий IP-адрес. При вводе пользователем URL возвращается коллективный адрес серверов DNS. IP-сеть маршрутизирует запрос на ближайший сервер.

Anycast предоставляет фундаментальные преимущества перед Unicast в плане безопасности. Unicast предоставляет IP-адреса отдельных серверов, поэтому нападавшие могут инициировать целенаправленные атаки на определенные физические серверы и виртуальные машины, и, когда исчерпаны ресурсы этой системы, происходит отказ службы. Anycast может помочь смягчить DDoS-атаки путем распределения запросов между группой серверов. Anycast также полезно использовать для изоляции последствий атаки.

Средства защиты от DDoS-атак, предоставляемые провайдером

Проектирование, развертывание и эксплуатации глобальной Anycast-сети требует времени, денег и ноу-хау. Большинство ИТ-организаций не располагают для этого специалистами и финансами. Можно доверить обеспечение функционирования инфраструктуры DNS провайдеру – поставщику управляемых услуг, который специализируется на DNS. Они имеют необходимые знания для защиты DNS от DDoS-атак.

Поставщики услуг Managed DNS эксплуатируют крупномасштабные Anycast-сети и имеют точки присутствия по всему миру. Эксперты по безопасности сети осуществляют мониторинг сети в режиме 24/7/365 и применяют специальные средства для смягчения последствий DDoS-атак.

Услуги защиты от DDoS-атак предлагают и некоторые поставщики услуг хостинга: анализ сетевого трафика производится в режиме 24/7, поэтому ваш сайт будет в относительной безопасности. Такая защита способна выдержать мощные атаки - до 1500 Гбит/сек. Оплачивается при этом трафик.

Еще один вариант – защита IP-адресов. Провайдер помещает IP-адрес, который клиент выбрал в качестве защищаемого, в специальную сеть-анализатор. При атаке трафик к клиенту сопоставляется с известными шаблонами атак. В результате клиент получает только чистый, отфильтрованный трафик. Таким образом, пользователи сайта могут и не узнать, что на него была предпринята атака. Для организации такого создается распределенная сеть фильтрующих узлов так, чтобы для каждой атаки можно было выбрать наиболее близкий узел и минимизировать задержку в передаче трафика.

Результатом использования сервисов защиты от DDoS-атак будет своевременное обнаружение и предотвращение DDoS-атак, непрерывность функционирования сайта и его постоянная доступность для пользователей, минимизация финансовых и репутационных потерь от простоев сайта или портала.

DDoS-атаки - это распространенный инструмент недобросовестной конкуренции или маскировка взлома сайтов с целью кражи конфиденциальной информации. Защита от таких атак особенно актуальна для компаний, работающих в сети Интернет – в первую очередь, это банки, компании, работающие в сфере электронного бизнеса (интернет-магазины), ежедневно использующие системы платежей и заказов, контент-провайдеры, средства массовой информации.

Почему сложно защититься от DDoS

Защититься от DDoS сложно по следующим трем основным причинам.

Врожденные уязвимости сети . Во-первых, в этом случае нет уязвимостей сети, которая используется преступниками. Атака успешна потому, что в природе всех компьютерных платформ существует некий порог доставки. Компьютеры, кластеры или облачные системы - все они имеют физические ограничения по количеству запросов, которые они могут обрабатывать в заданное время. Успешная атака DDoS должно просто генерировать достаточное количество трафика, чтобы превысить это пороговое значение. Большая часть других атак может быть отражена путем использования специальных патчей, конфигурацией систем безопасности или изменение политик. Но ни один из этих подходов не поможет противостоять DDoS. Службы должны быть всегда доступны и, значит, уязвимы для атак.

Невозможность заблокировать толпу . DDoS очень сложно заблокировать, поскольку существует очень много источников атаки. Очень трудно обеспечить эффективную блокировку длинного списка атакующих IP-адресов. Потенциально тысячи адресов должны быть временно добавлены в черный список для того, чтобы остановить атаку. Если атакующий использует метод, прикрывающий атаку вполне легитимными хостами (spoofing), то в черный список могут попасть и невинные хосты.

Список мер, если вы подверглись DDoS-атаке

Убедитесь в том, что атака произошла. Исключите общие причины перебоя работы, включая неправильную конфигурацию DNS, проблемы с маршрутизацией и человеческий фактор.

Установите приоритеты важности приложений, для того, чтобы сохранить наиболее приоритетные. В условиях интенсивной DDoS-атаки и ограниченных ресурсов необходимо сосредоточиться на приложениях, обеспечивающих основные источники прибыли.

Защитите удаленных пользователей. Обеспечьте работу вашего бизнеса: занесите в белый список IP-адреса доверенных удаленных пользователей, которым необходим доступ, и сделайте этот список основным. Распространите это список в сети и отправьте его поставщикам услуг доступа.

Определите класс атаки. C каким типом атаки вы столкнулись: Объемная? Маломощная и медленная? Ваш поставщик услуг сообщит вам, является ли атака исключительно объемной.

Оцените варианты борьбы с адресами источников атак. В случае сложных атак ваш поставщик услуг не сможет преодолеть/определить количество источников. Заблокируйте небольшие списки атакующих IP-адресов в вашем межсетевом экране. Более крупные атаки можно блокировать на основе данных о геопозиционировании.

Заблокируйте атаки на уровне приложения. Определите вредоносный трафик и проверьте, создается ли он известным инструментом. Определенные атаки на уровне приложения можно блокировать для каждого конкретного случая с помощью контрмер, которые могут быть предоставлены имеющимися у вас решениями.

Усильте свой периметр защиты. Возможно, вы столкнулись с ассиметричной атакой DDoS 7 уровня. Сосредоточьтесь на защите на уровне приложений: используйте системы логинов, систему распознавания людей или технологию Real Browser Enforcement.

Ограничьте сетевые ресурсы. Если предыдущие меры не помогли, то необходимо ограничить ресурсы – таким образом будет ограничен «плохой» и «хороший» трафик.

Управляйте связями с общественностью. Если атака стала публичной, подготовьте официальное заявление и проинформируйте персонал. Если отраслевые политики предусматривают это, подтвердите факт атаки. Если нет, то сошлитесь на технические трудности и порекомендуйте персоналу перенаправлять все вопросы руководителю отдела по связям с общественностью.

В таблице ниже приводится сравнение типичного понимания атаки и действий, которые предпринимаются в условиях ограниченности ресурсов, по сравнению с другой реакцией, основанной на более обширной базе знаний и более глубоком анализе.

Дополнительные материалы

Как не стать жертвой DDoS-атаки

Разработка стратегии защиты

Чтобы остановить атаки, организациям требуется изменить стратегию защиты, перейдя с двухэтапной защиты на трехэтапную. Двухэтапный подход подразумевает предварительный этап подготовки к атаке – выбор решений по обеспечению безопасности, развертывание систем безопасности и другие меры, и этап после атаки - проведение экспертизы, подведение итогов и совершенствование используемых средств защиты в ожидании следующей атаки. Этих действий было достаточно, пока атаки носили непродолжительный характер.

Теперь, когда кампании длятся днями или неделями, организациям требуется добавить третий этап – защитную стратегию, используемую ВО ВРЕМЯ атаки. Наиболее важным компонентом такой стратегии является команда экспертов, которые могут не только динамически реагировать на действия злоумышленников во время нападения, но также применять контрмеры для остановки атаки, и затем анализировать полученную информацию для совершенствования методов борьбы с будущими атаками. Для организаций неразумно содержать требуемое количество людских ресурсов и квалифицированных специалистов на постоянной основе, учитывая, что в год они подвергаются всего нескольким атакам. Организации, таким образом, должны найти дополнительные внешние ресурсы – экспертов по безопасности, отраслевые альянсы или государственные службы. Только с помощью таких услуг по требованию и усиления своей команды специалистов услугами сторонних экспертов можно одержать победу в борьбе за безопасность.

Очистка трафика на уровне оператора связи или спецпровайдера

Мощная DDoS-атака может занять всю емкость интернет-канала «жертвы», поэтому на стороне атакуемого проблему не решить: эффективная защита может быть обеспечена только на уровне оператора связи. Internet Umbrella постоянно контролирует уровень превышения интенсивности различных профилей трафика для защищаемой сети и сравнивает его со стандартными значениями трафика. В случае атаки оборудование фильтрует вредоносные пакеты и направляет клиенту только очищенный трафик. Все эти действия производятся в автоматическом режиме 24 часа в сутки, а емкость интернет-каналов оператора достаточна для того, чтобы предотвращать самые мощные атаки. Выделенная смена технических специалистов Orange наблюдает за эффективностью и работоспособностью услуги в режиме 24/7 и оперативно вносит корректировки по мере необходимости.

Из-за снижения стоимости организации мощных DDoS-атак рассчитывать на свои силы в защите от них могут позволить себе только компании, располагающие широкополосным доступом в Интернет и резервированием канала подключения, что редкость в нынешней российской корпоративной практике. Поэтому в этом деле корректнее полагаться даже не на операторов связи, а на специализированных провайдеров услуги по защите от DDoS-атак.

Будьте осторожны с сервисами стрессового тестирования

Доступность веб-ресурса является важнейшим фактором при ведении бизнеса: длительное время отклика и недоступность приводит к прямым убыткам в виде потерянных потенциальных клиентов. Именно поэтому разработчики и владельцы веб-приложений уделяют особое внимание процедурам нагрузочного и стрессового тестирования. В свою очередь, появились сервисы, осуществляющие проверку веб-ресурсов, имитируя активность посетителей.

Стрессовое тестирование - это процедура оценки характеристик работоспособности системы, проводимая за рамками предельного значения нагрузки. Стресс-тесты в большинстве случаев ведут к аномальному поведению системы или ее отказу в обслуживании аналогично DDoS-атакам. Однако цели у стрессового тестирования и DDoS-атаки совершенно разные. В первом случае задача - определить показатели предельной нагрузки системы и проверить устойчивость к некоторым сценариям DDoS-атак, а во втором - сделать недоступным атакуемый объект любыми эффективными методами, нарушив тем самым работоспособность целевой инфраструктуры.

С ростом потребности подобных оценок появилось немало онлайн-сервисов, позволяющих не утруждать себя настройкой сложных систем тестирования и подготовкой облачной инфраструктуры: достаточно задать параметры нагрузки и оплатить вычислительные мощности, ожидая затем отчет о поведении ресурса. При этом некоторые службы для ознакомления бесплатно предлагают короткий тест без регистрации.

Однако злоумышленники могут воспользоваться этой, на первый взгляд, безобидной услугой в своих целях. Дело в том, что большинство сервисов нагрузочного тестирования не требуют подтверждения того, что процедуру заказывает его владелец - нет никаких дополнительных привязок к телефонному номеру или кредитной карте. Так, из шести рассмотренных специалистами «Лаборатории Касперского » сервисов только один просит разместить на тестируемом ресурсе специальный файл - его наличие означает гарантию того, что администратор сервера уведомлен о процедуре. Более того, два сервиса позволили осуществить нагрузочное тестирование вообще без регистрации - достаточно было ввести URL ресурса. Эксперты «Лаборатории Касперского» пришли к неутешительному прогнозу, представив несколько вариантов использования злоумышленниками одного только бесплатного режима, не говоря уже про более богатые платные возможности.

«Киберпреступники могут эксплуатировать подобные системы для нанесения серьезных ударов владельцам некрупных веб-ресурсов. Во избежание такого сценария каждый сервис нагрузочного тестирования должен запрашивать согласие от владельца: просить его разместить уникальный код или баннер на сайте, только после чтения которого будет запущен трафик. В дополнение следует использовать технологию CAPTCHA при работе с сервисом. Подобные процедуры верификации помогут избежать неправомерных действий со стороны злоумышленников и роботов бот-сетей», - прокомментировал Денис Макрушин, менеджер по техническому позиционированию «Лаборатории Касперского».

Проблемы защиты от атак по HTTPS и SSL

Есть два допущения в отношении борьбы с DoS/DDoS-атаками. Во-первых, требуется остановить атаку как можно раньше, прежде чем она проникнет глубоко в сеть. Во-вторых, что является более очевидным, требуется проверять весь трафик. Этого нелегко добиться при атаках, основанных на использовании протокола HTTPS .

Уже к 2012 году команда ERT столкнулась с возросшим количеством просьб о помощи в борьбе с HTTPS- атаками. Удивительно, что такие атаки раньше не так часто использовались, однако в это время ожидался резкий рост их популярности.

Почему HTTPS-атака представляет такую угрозу? Несмотря на то, что в ней используется протокол, аналогичный протоколу HTTP, она представляет угрозу совершенно иного уровня. Причина в следующем: как правило, HTTP-атаки можно обнаружить и ликвидировать с помощью системы защиты от DDoS-атак, которая расположена на клиентском оборудовании (CPE), в облаке или, в идеальном случае, и там, и там. Такие решения могут справиться с HTTP-атаками уровня приложений или атаками на переполнение сети.

Однако когда те же самые атаки выполняются посредством протокола HTTPS, дела обстоят по-другому. Сетевые флуды могут быть остановлены; данные пока не шифруются, и SYN-флуд, к примеру, по HTTPS выглядит точно также, как и по HTTP. Однако атаки на приложения достаточно сложно обнаружить.

Как показано на рисунке, зашифрованный HTTPS-трафик обычно дешифруется только на веб-сервере, балансировщике нагрузки или выделенном устройстве для SSL-терминации. Данные объекты обычно лежат дальше в сети после того уровня, где трафик проверяется системами защиты от DoS-атак (в облаке или CPE):

Поскольку организации неохотно соглашаются на передачу своих ключей SSL и сертификата в MSSP облака, ведь такое действие несет определенные риски, система защиты от DoS-атак, расположенная в облаке, не может проанализировать зашифрованный трафик, и, следовательно, не может обнаружить атаку.
CPE-устройство также видит данные в зашифрованном виде, и тоже не может их проанализировать. Следовательно, заметить атаку получается слишком поздно, после того, как она уже достигла своей цели.

Помимо HTTPS-атак, существуют атаки, присущие именно уровню SSL , которые нацелены непосредственно на механизм обмена данными по SSL. SSL-атаки, которые выполняются с помощью инструмента THC-SSL-DOS, подробно обсуждались в отчете за 2011 год, однако мы вкратце изложим этот вопрос.

Обычно SSL-подтверждение выполняется только единожды с целью установки безопасного соединения. Для атаки используется опция протокола на «повторное согласование» для установки нового секретного ключа. Отправляя многократные запросы на повторное SSL-согласование, злоумышленник значительно повышает нагрузку на процессор целевого сервера до того момента, когда тот уже не может дальше работать.

В тех случаях, когда сервером не поддерживается опция «повторного согласования», злоумышленник может открывать новые SSL-соединения, что приведет к такому же эффекту. SSL-атака носит асимметричный характер - ресурсы, необходимые серверу для обработки подтверждения, в 15 раз больше тех, которые требуются от устройства, запросившего подтверждение (атакующего).

Протокол HTTPS поддерживается практически всеми веб-сайтами и является важным компонентом финансовых сайтов, где с его помощью защищаются денежные операции. С учетом сложности выявления HTTPS-атак, мы ожидаем увидеть резкий рост популярности таких атак и рекомендуем организациям, особенно тем, кто работает в финансовом секторе, приобрести решение по борьбе с данной проблемой.

* Рекомендации по выбору поставщика услуг защиты от DDoS

Необходимо рассматривать качество на трёх уровнях:

качество восприятия услуги пользователем здесь и сейчас;
ожидания пользователя относительно качества услуги во время определённого периода времени (час, неделя, месяц);
гарантия качества, построенная на уверенности пользователя, что предоставляемый сервис не окажет скрытого негативного влияния на него (компьютер не взломают, не заразят вирусом и т.д.).

Чему мы можем научиться в борьбе с атаками?

Усовершенствованные и продолжительные DoS- и DDoS-атаки безусловно опасны и сложны, однако они предоставляют некоторые весьма ценные возможности для развития. Эксперты по безопасности могут собрать актуальные сведения об атакующих – кем они являются, и какие инструменты используют. В конечном итоге, это позволяет организациям отразить атаку, применить контрмеры и победить атакующих на их поле.

Защита от DDoS-атак с использованием SSL-шифрования чем-то напоминает работу службы безопасности в аэропортах на Ближнем Востоке: всегда есть множество женщин с прикрытыми лицами, которых нужно не просто деликатно досматривать, но и анализировать поведение. Иначе рано или поздно одна из них взорвет самолёт. Технически в защите от таких атак используются специфические подходы, но при адекватных настройках расшифровка HTTPS-сообщений потребует не так много ресурсов. Проблема в другом: далеко не каждый клиент готов дать полный доступ к своим зашифрованным каналам. Можно ли эффективно анализировать трафик без ключей?

«Сегодня с помощью HTTPS-сообщений атакуют множество защищенных ресурсов, а SSL используют в том числе для того, чтобы обойти средства безопасности, – поясняет суть проблемы руководитель Qrator Labs Александр Лямин. – В отличие от прямых DDoS-атак на механизмы шифрования, которые происходят на уровнях L5 и L6, атаки с использованием SSL относятся к уровню L7. Поэтому они очень похожи на действия легитимных пользователей».

Многие вредоносные программы нацелены на то, чтобы сделать уязвимый компьютер частью сети заражённых машин – ботнета с единым центром управления. Такой ботнет может по удалённой команде выполнять сетевые атаки без ведома владельцев протрояненных компьютеров. Если раньше ботнеты использовались в основном для рассылки спама, майнинга криптовалют и выполнения примитивных DDoS-атак, то сегодня они стали более серьёзной угрозой безопасности.

Например, ботнет может имитировать зашифрованное соединение и выполнить SSL-атаку. Шифрование каждого канала связи способно какое-то время скрывать от систем безопасности и администраторов сайта наличие вредоносной активности. В итоге это может привести к утечке конфиденциальных данных или нарушению работы сайта.
«Атаки L7 в любом случае попадают в корпоративную сеть, – комментирует Александр Лямин. – Так как первые пакеты HTTPS-запроса от атакующего – сугубо служебные, то они всегда выглядят легитимно. Понять на этом этапе намерения удалённого клиента принципиально невозможно».

Обычно вредоносные действия начинаются на втором или последующих этапах. Чтобы их обнаружить, необходимо пустить пользователя в сеть. Поэтому основная задача средств защиты – не столько предотвратить SSL DDoS-атаки, сколько минимизировать возможный ущерб. Так как для каждого пользователя создается свой, закрытый канал, то вполне допустимо потратить дополнительное время на анализ действий перед принятием решения о блокировки того или иного пользователя.

Любая защита от DDoS-атаки с использованием SSL-шифрования подразумевает использование средств, способных анализировать поведение пользователя по его зашифрованным запросам. Они могут прямо или косвенно получать информацию о том, что происходит в зашифрованном канале. При этом дополнительно нужно обеспечить автоматическую фильтрацию на уровне пользователей, чтобы обнаруживать атаки в реальном времени.

С ключом

В общем случае для защиты от DDoS-атаки с использованием SSL-шифрования всегда требуется тот или иной уровень расшифровки содержимого канала. В некоторых случаях расшифровку может производить клиент – тогда он сам решает, какие данные следует допускать для передачи. Однако для этого на стороне клиента должна быть установлена защита от троянов, бэкдоров, руткитов и прочих вредоносных программ, способных скрыто перехватить управление компьютером или сделать его частью ботнета.
Поэтому наиболее распространенный и практичный способ защиты заключается в постоянном взаимодействии средств безопасности с сервером компании. В такой схеме достаточно внести новые настройки на сервер, и он предоставит всю необходимую информацию о происходящем в зашифрованном канале. Если же возникают опасения по поводу поведения того или иного клиента, то сервер передаёт его сессию на контроль поставщику средств защиты или аппаратно-программным комплексам на стороне клиента.

Без ключа

Как показывает практика, многие клиенты из сферы розничной торговли и СМИ предпочитают раскрыть ключи шифрования поставщику средств защиты. Это считается допустимым риском, поскольку SSL-шифрование используется у них только для изоляции клиентов друг от друга и предотвращения перехвата данных из слабо защищённых сегментов сети – например, через Wi-Fi. Финансовые организации, напротив, предпочитают настраивать сервера таким образом, чтобы поставщику была доступна только косвенная информация.

Сегодня DDoS-атаки остаются одним из главных средств конкурентной борьбы в политике, деловом и финансовом секторе. Как и раньше, они парализуют работу сайтов и ключевых сервисов, нанося многомиллионный ущерб. Отличие в том, что современные атаки по типу «отказ в обслуживании» стали технически сложнее и мощнее. Их сложнее вовремя распознать традиционными средствами защиты, поэтому разработчикам приходится всё время искать и оптимизировать новые алгоритмы, использовать облачные технологии и методы анализа «больших данных».

Выбирая решения для защиты от DDoS атак стоит убедиться, что они умеют фильтровать трафик на уровне L7 и обладают реальной возможностью отличить действия легитимных пользователей от аткивности продвинутого ботнета. Дополнительным преимуществом станет возможность работать с зашифрованным трафиком без раскрытия секретных ключей, но делать это только по косвенной информации о поведении клиента в канале пока умеют единицы.

Здравствуйте, уважаемые читатели блога сайт. Кто не слышал про CloudFlare ? Я слышал и даже подробно изучал возможности сервиса лет этак пять назад, наверное (когда ). Вот только сейчас уже не скажу, что именно тогда меня остановило от того, чтобы этот сервис попробовать (не помню). Но это и не важно.

Важно же то, что в первый рабочий день после новогодних праздников мне таки пришлось подключить сайт к CloudFlare и притом в авральном режиме (с выдиранием волос, литрами выпитого кофе и биением головой об стол). Сделать это пришлось из-за полной блокировки доступа к сайту (скорее всего путем Ддос атаки — по FTP доступ был возможен).

Из меня администратор сервера аховый и по большому счету я мало что понимаю в тонкостях и разновидностях DDos атак (ни как их организуют, ни как от них грамотно отбиваться — кроме простейшего блокирование по IP). Когда с этим не сталкиваешься, то оно тебе и не надо.

Но по всему выходит, что в первый рабочий день после новогодних праздников меня ддосили, и ничего ни я, ни техподдержка хостинга с этим поделать не смогли. Нанимать фрилансера для решения проблемы было стремно. Хорошо хоть по телефону ребята с Инфобокса мне подкинули идею подключить CloudFlare (как один из вариантов решения проблемы) и я за эту идею ухватился как за соломинку.

На успех особо не рассчитывал (за несколько часов, нужных для сброса старых и прописывания новых NC адресов успел много чего узнать по теме и даже составил уже примерный план действий). Но к моему удивлению буржуйский чудо-сервис помог! Притом даже на бесплатном тарифе. Замечательно сработал режим защиты от DDos атаки . Честно — не ожидал. Был приятно удивлен. Да еще и сайт стал летать как на крыльях (хотя и раньше черепахой не был).

В общем — так не бывает, но все же случается...

Что такое Ддос и что такое CloudFlare?

Что такое Ddos ? Ну, во-первых, это аббревиатура от «distributed denial of service». По-русски это звучит как распределенная атака, цель которой добиться от атакуемого сервера (группы серверов) отказа в обслуживании для посетителей сайта (сайтов). Сайт будет выдавать ошибку всем желающим на него войти.

Слово «распредленная» означает, что Ддос атака идет сразу со множества компьютеров в сети. Очень часто для этой цели используется так называемый ботнет, т.е. группа зараженных вирусами или другим способом взятых под контроль компьютеров. Владельцы входящих в ботнет компьютеров могут при этом даже не догадывать о том, что они кого-то атакуют (все происходит в фоновом режиме).

Физически это означает огромное количество запросов, совершаемых к серверу с разных IP адресов. Если адрес будет один или несколько, то его легко можно вычислить по логам или открыв страницу http://xxx.xxx.xxx.xxx/server-status (где x нужно заменить на IP вашего сервера, если он работает под Апачем). После чего проблем не составит подозрительные IP временно заблокирвовать, например, через файл.htaccess дописав в него строки (Ip замените на свои — строк с Deny from можно добавлять сколько угодно):

Order allow,deny allow from all Deny from 83.149.19.177 Deny from 87.228.80.49 Deny from 178.212.72.13

Какое-то время мне это помогало. Но настоящий Ddos так ни за что не отбить — просто не успеете выявлять повторы IP адресов, если атаковать будут с десятков и/или сотен хостов. У меня так и случилось. В итоге 7 часов полного дауна!

Первые два часа я общался с техподдержкой хостинга на предмет «помогите» — «не могем». Потом за пять минут подключил к сайту CloudFlare, еще за пару минут сменил DNS записи у и часа четыре ждал, пока начнется проключение ( должны обновиться на всех ключевых NS серверах в сети). Полноценно сайт заработал только через сутки, примерно.

Что такое DDos? Это страшная вещь на самом деле. Чувствуешь свое полное бессилие и безысходность. Со стороны атакующих — это способ заработать (на шантаже или выполняя заказ конкурента). Постоянная защита от этого зла очень дорогая, но CloudFlare даже на бесплатном тарифе позволяет отбиться от слабо-средней Ддос-атаки .

У этого сервиса есть миллионы подключенных сайтов (около пяти миллионов) и разработчики сервиса всегда четко отслеживают с каких IP сейчас обычно атакуют и таким посетителям, например, можно показать капчу (боты вряд ли настроены на ее разгадывание) или проверить браузер на «человечность» у таких подозрительных IP. Да и сами по себе их распределенные по миру сервера неплохо разреживают атаку на отказ — просто эти запросы распределяются на разные сервера и сильно снижают силу атаки сводя все усилия «редисок» на нет.

Для более серьезной защиты от Ддос в CloudFlare нужно уже платить и не мало (200$). Но это все для очень серьезного бизнеса, где Ддос мощнее (денег вливаемых в это больше), но и средств у владельцев много больше. Нам с вами «за глаза» хватит тарифа PRO за 20$ или вообще бесплатного тарифа, на котором почти все есть (читайте об этом ниже).

Что такое CloudFlare ? Это онлайн сервис, ведущий свою историю с 2009 года (он ровесник моему блогу). Это ни в коем разе не хостинг, хотя со стороны может показаться именно так. Это скорее надстройка над хостингом (что-то вроде кеширующего обратного прокси). После подключения сайта к этому онлайн-сервису у него меняется IP адрес и возникает такое ощущение, что вы сменили хостера, но это не так.

Хостинг вам будет по-прежнему нужен и работать с сайтом вы будете фактически так же, как и работали раньше. Будут некоторые нюансики, но суть останется прежней. CloudFlare же нужен для защиты (стабильной работы) и ускорения работы сайта .

К нему подключены уже более пяти миллионов сайтов по всему миру. Этот онлайн сервис владеет распределенной сетью дата-центров (более 120) по всему миру (с прошлого года и в Москве такой появился). Последнее особо приятно, ибо обеспечивает гораздо более быстрый отклик при обращении к сайтам с территории России (хотя страна у нас большая и центров надо строить больше).

Итак, CloudFlare владеет кучей серверов распределенных по всему миру . Зачем? Чтобы добавленные в него сайты грузились в браузерах посетителей как можно быстрее. Вся графика, CSS и джава-скрипт коды будут отдаваться с того дата центра, который ближе находится к данному посетителю вашего сайта. Посетитель зашел из Москвы? Значит в работу включится московский дата-центр. Из США? Значит графика и прочая статика будет отдаваться посетителю с ближайшего к нему узла Cloud Flare.

Одно это уже способно повысить среднюю скорость загрузки странниц вашего сайта. Но данный сервис имеет в своем загашнике еще несколько тузов и джокеров. Работая с миллионами сайтов и отражая ежесекундно атаки сервис имеет базу адресов, с которых сейчас чаще всего атакуют сайты. Одно это может даже на бесплатном тарифе служить первым эшелоном защиты от DDoS-атак (и на это не требуется тратить особо ресурсы и время).

Кроме этого сервис позволяет включить режим «под атакой» (Under Attack Mode), когда каждое обращение к сайту прерывается на 5 секунд для выяснения типа браузера, с которого осуществлялся заход. Как раз этот режим спас меня в описанной выше безвыходной ситуации. Да, при этом отсекаются все боты и часть легитимных пользователей (на вскидку трафик стал процентов на двадцать меньше), но это лучше чем полный отказ сервера в доступе.

По окончании Ддос-атаки этот режим можно будет отключить и выбрать подходящий уровень бдения. При повторении атаки его легко можно будет включить даже с мобильника сидя в метро (главное , чтобы вовремя среагировать).

В общем, даже на бесплатном тарифе практически все что нужно уже есть. Даже можно сжимать на лету файлы CSS и джава скрипта (удалив из них пробелы), чтобы на капелюшечку увеличить скорость загрузки. Не поверите — на бесплатном тарифе в CloudFlare можно будет даже SSL к сайту подключить (перейти на шифрованный протокол передачи данных — https, к чему нас последнее время активно склоняет Гугл). Причем сервис предоставляет свой собственный бесплатный сертификат.

Фантастика какая-то, не правда ли? Сами посмотрите сравнительную таблицу тарифных планов (включая Free). Чума! Если ваш хостинг упадет (будут проблемы), то Cloud Flare будет отдавать в этот промежуток времени страницы сайта из своего кеша (и это работает — проверял остановкой сервака, но есть нюансы о которых обязательно читайте ниже, иначе не сработает). Может чего упустил из бесплатных прелестей, но и этого более чем достаточно (за так то).

Кстати, у сервиса этого нет партнерки, но в рунете есть масса конкурентов с сумасшедшими ценниками (например, защита от DDoS-атак в qrator стоит ого-го-го сколько). Поэтому когда будете читать на форумах или блогах отзывы о CloudFlare , то обратите внимание на зачастую очень тонкую работу этих конкурентов (возможности CloudFlare занижаются, а своего сервиса или надстройки — абсолютируются). Многие ведутся, но сервис однозначно из разряда «такого не может быть, но все же есть».

Нет, недостатки у него тоже есть . Какие? Ну, зачастую очень даже значимые:

Что дает переход на тариф PRO в CloudFlare?

Как я уже сказал выше, купил PRO за 20$ в месяц (дороже хостинга получилось в полтора раза) и меня перевели (без моей просьбы — автоматом) на новый IP , где только три соседа и вполне себе легитимные.

Кроме этого на платном тарифе появилась возможность :

Polish (вкладка «Speed» из верхнего меню) — сжимать на лету картинки перед их отдачей посетителям сайта (можно настроить вариант сжатия — без потерь или с потерями, но более сильно).
Mirage — позволяет подгружать график на мобильных устройствах не сразу, а по мере прокрутки посетителем страницы. Кроме этого, изображения сжимают до реально требуемых размеров и только потом передаются пользователю в гаджет. Вроде как это здорово ускоряет работу сайта на мобильниках.
Например, если открыть мой блог с мобильника, то при быстрой прокрутке страницы увидите, что вместо картинок вставляются заглушки, которые заменяются на реальные изображения только при их попадании в экран просмотра.
А сейчас существенно ниже дает оценку — ругается, что часть контента на первом экране не подгружается вовремя. Кто его поймет?
Page Rules — на платном аккаунте появляется возможность задать более трех правил для страниц (а точнее — до 20). Зачем нужны эти правила? Например, именно они позволяют настроить кеширование не только статики, но и Html страниц сайта. Ну, и еще другие применения найдутся, но мне это нужно только для описанной цели. Как настроить полное кеширование сайта (включая текст страниц, а не только картинок, скриптов и стилей) читайте ниже.
Web Application Firewall — на платном аккаунте можно активировать (на вкладке «Firewall» из верхнего меню) базовый набор защиты от различных атак типа межсайтового скриптинга (XSS) и SQL инъекций. Вся подобная активность будет отсекаться (фильтроваться) еще на
CloudFlare (не доходя до реального хостинга). Можно еще свои правила добавить, но я в этом не силен, посему ограничился стандартным (проверенным временем и миллионами сайтов) набором.
Можно будет еще на платном акке сделать свой дизайн для страниц с различными ошибками. Например, когда вы включаете режим «Под атакой» (Under Attack Mode), то всем новым посетителям сайта будет показывать сообщение о том, что идет проверка их браузера на предмет «человечности» (если Серч читаете, то могли у них такую надпись видеть в течении последнего года, после подключения ими Cloud Flare).
Табличка эта на буржуйском языке и часть посетителей могут просто сбежать. А вот если написать что-то типа «Ребят, ребят, ребят! Не уходите! Буквально 5 сек и все будет!», то шанс удержать посетителя увеличится. Я пока все ленюсь этим заняться...

Тариф я оплачиваю через Пейпел, что весьма удобно. При настройке платежей меня попросили , но деньги снимались не с карты, а непосредственно с самого кошелька (я в него вывожу ). Прикольно, что каждый последующий месяц платеж происходит без моего участия — деньги автоматом списываются с Пайпаловского кошелька в день оплаты, что очень удобно.

Оно и не мудрено, ибо Пайпал позволяет в течении полутора месяцев опротестовать платеж, если что.

Как подключить свой сайт к CloudFlare?

Ну, тут, кстати, все довольно просто, если мастер подключения сможет вытянуть все нужные настройки для переноса вашего сайта (его IP, Ms записи). Однако, обо всем по порядку.

Заходите на Cloud Flare и регистрируетесь ( как зеницу ока, ибо это ключ к вашему сайту).

Сразу оговорюсь, что бояться особо нечего, ибо при неудачном подключении вам не придется ждать сутки, пока ДНС записи опять перепишутся. Просто кликните по облачкам на странице настройки DNS и ваш сайт будет работать напрямую (мне пришлось так поступить с одним из второстепенных проектов, который почему-то с CloudFlare перестал открываться — см. скриншот ниже). Но по-любому: вся ответственность за ваши действия лежит только на вас и я тут буду, как бы, ни причем .

Сразу после регистрации можно переходить на страницу добавления нового сайта , где в предложенную строку нужно будет просто вставить его доменное имя и нажать на кнопку «Begin Scan»:

Тут, как видите, все ОК — сервис нашел все основные NS записи (включая почтовые), что есть хорошо. Автоматически для будущих данных, передаваемых с этого сайта, включилось кеширование (облачка окрасились). Идем дальше.

Как уже говорил выше, для защиты от Ddos подойдет даже бесплатный тарифный план (на нем при желании еще и бесплатный SSL сертификат получить можно). Отличия плана PRO от бесплатного я описал выше, поэтому выбирайте то, что вам нужно (мне все равно). Идем дальше.

Теперь основное. Нужно зайти в панель вашего регистратора доменных имен () и сменить там NS записи на те, что предложил на этом шаге мастера CloudFlare. Например, в Вебмани Домейнс это делается на такой вот страничке:

Нужно просто заменить записи в двух строчках на то, что вам Cloud Flare дал и подождать от 4 часов до 2 суток , пока все это дело пропишется на всех NS интернета. Идем далее, и по истечении нескольких часов после прописывания новых NS серверов можно будет нажать на кнопку «Recheck Nameservers»:

Обратите внимание, что внизу приведены настройки по умолчанию , которые будут применены к вашему сайту сразу после окончательного подключения к CloudFlare (средний уровень безопасности и стандартное кеширование, которое подразумевает попадание в кеш только статики — картинок, стилей и скриптов).

Если подключение ДНС уже прошло, то статус после нажатия на упомянутую кнопку сменится:

Кнопка «Quick Actions» позволяет быстро перейти в режим защиты от Ddos и прочих видов атак, который называется «Under Attack Mode» . Мне при переходе на Cloud Flare пришлось сделать именно так. Данный режим «Под атакой» (Under Attack Mode) у меня был включен около 12 часов, пока атака не прекратилась.

На это время доступ к сайту ограничен и все соединения проверяются на предмет их легетивности. Всякие боты, в том числе и поисковых систем пробиться на сайт не смогут. В общем, работать в нем не стоит дольше того, чем необходимо (пока идет атака). Чуть подробнее о включении и выключении режима защиты от Ддос-атаки читайте в самом конце этой публикации.

100%-ый аптайм для сайта с помощью CloudFlare

Под автономной работой сайта я имею такую ситуацию, когда по каким-либо причинам ваш хостинг «ляжет», а сайт продолжит быть доступным посетителям . Это, как говорится, крайний случай. Но зачастую хостинг может просто-напросто не справляться с высокой нагрузкой (вызванной посещаемостью или использованием множества плагинов и плохой оптимизацией движка). В этом случае опять же поможет кеширование Html страниц в CloudFlare.

По умолчанию, как я понимаю, сервис кэширует только статику : картинки, CSS и JC. Все. В принципе, и это здорово может облегчить работу хостинга и ускорить загрузку страниц сайта в разных точках мира. Но зачастую этого бывает недостаточно. И даже не это главное. В этом режиме не срабатывает функция «Always Online» (Всегда онлайн), ибо Cloud Flare не умеет творить чудеса и отдает страницы из своего собственного кеша, а если их там нет, то отсылает к хостингу (который в данный момент может быть недоступен).

В общем, задача сводится к тому, чтобы включить кэширование всего содержимого веб-страниц (кода разметки, включающего текстовое наполнение), а не только статики. Сделать это можно на вкладке «Page Rules» из верхнего меню (см. пояснения в хелпе). Почему это не вынесли в общие настройки кэширования? Думаю, что из-за великого разнообразия сайтов и движков, на которых они работают. Видимо, не возможно обеспечить таким образом стабильность. Нужно действовать более точечно, опираясь на структуру и специфику каждого конкретного вебсайта. ИМХО.

На бесплатном тарифе можно создать только три правила для страниц, а на тарифе PRO — уже 20. Суть создания правила довольно проста. Пока опустим то, что нужно вставить в поле с регулярным выражением, а посмотрим что нам предлагают при нажатии на «+ Add a Setting» (добавить настройку):

Здесь как раз можно выбрать настройку степени кэширования (Cache levels), где в открывшемся списке допнастроек можно будет выбрать последний вариант «Cache everything» («Кэшировать все»). Таким образом, мы принудительно заставим CloudFlare кешировать всю вебстраницу, а не только статику.

Еще желательно будет задать время, которое страница будет храниться в кэше CloudFlare и в кэше браузеров посетителей сайта (это две разных настройки). Тут все зависит от степени динамичности вашего сайта в целом и отдельных его страниц в частности. Меня вполне устраивает интервал в несколько суток хранения кеша в облаке, а кеш браузера я выбираю разный (в зависимости от типа страниц).

Для задания этих настроек нужно будут еще пару раз нажать на кнопку «+ Add a Setting» и выбрать:

Browser Cache TTL — настройка времени жизни кэша в браузерах посетителей вашего сайта. Например, если выберите одни сутки, то посетитель, в течении суток зашедший дважды на одну и ту же страницу вашего сайта, второй раз получит ее не из интернета, а из кеша собственного браузера (без изменений). А вот если времени пройдет более суток, то страничка будет запрашиваться уже из интернета (с Cloud Flare). Для главной страницы этого блога я поставил значение «пару часов» для Browser Cache TTL, а для остальных страниц — от суток до двух. Возможно, что можно придумать что-то более оптимальное.
Edge cache TTL — это уже время жизни кеша на серверах в дата-центрах CloudFlare (по всему миру). Если поставите все те же сутки, то все посетители вашего сайта будут видеть эту страницу (или группу страниц, для которых вы задали Edge cache TTL равным суткам) без изменений, даже если на сервере эта страница поменялась (например, к ней добавились комментарии или вы что-то изменили в тексте, поменяли изображение и т.п.).

Сразу оговорюсь, что на сервисе есть возможность принудительно сбросить кеш не только для всего сайта (чего делать особо не рекомендуется), но и отдельных страниц, и даже отдельных статических файлов (изображений, файлов стилей и скриптов), когда вы внесли в них изменения и хотите, чтобы они незамедлительно стали доступны посетителям вашего сайта.

Делается это на вкладке «Caching» (из верхнего меню) путем нажатия на кнопку «Purge Individual Files» (чтобы сбросить весь кеш нужно будет нажать на стрелочку на этой кнопке и выбрать нижний из двух пунктов «Purge Everything»). В открывшееся окно нужно ввести Урл страницы, либо страниц (по одной на строку), либо отдельных файлов (полный путь до картинок, файла стилей и т.п.):

Я этой опцией пользуюсь довольно часто, например, после изменения картинок, добавлении комментария к статье или при изменении дизайна сайта (сбрасываю кеш для файлика стилей). Файлы, кеш которых вы недавно сбрасывали, отображаются ниже — по ним можно просто кликнуть, чтобы выполнить их очередной сброс. Очень удобно.

Но вернемся к настройкам правил для отдельных страниц сайта — Page Rules . Чуть ранее мы нажали на кнопку «Create Page Rule» и научились включать полное кеширование содержимого Html страниц, а также ограничивать время жизни кэша в браузерах посетителей и на серверах CloudFlare. Получиться в результате должно что-то типа этого:

Т.е. мы задали нужные нам правила кеширования. В примере — это кэширование всего содержимого со сроком жизни кэша в браузерах посетителей 4 час и сроком жизни кеша на серверах сервиса 2 суток. Осталось дело за малым — прописать в первой строке этого всплывающего окна формулу, по которой сервис поймет для каких именно страниц вашего сайта эти правила применять . Как это сделать, можно почитать нажав на кнопку «Хелп» внизу окна настроек правил.

На мой взгляд есть два пути задания правил:

На тарифе Pro есть возможность прописать 20 правил для страниц, что позволяет реализовать первый вариант: описать формулами все типы страниц сайта, которые стоит кешировать . Для моего блога — это главная, страницы со статьями, страницы рубрик, а также статические страницы типа «О блоге» и т.п. Естественно, Урлы админки тут указывать не будем, ибо там кеш может помешать работе.
На бесплатном тарифе доступны только три правила, и в некоторых случаях их может не хватить для реализации первого способа. Второй способ заключается в том, чтобы сначала разрешить кеширование страниц всего сайта, а потом запретить кешировать админку и страницу авторизации. Трех правил для этого должно хватить.

Как настроить полное кеширования страниц сайта в CloudFlare

Теперь поподробнее о практической реализации обеих способов.

Начнем с первого варианта создания разрешающих правил кеширования для всех (или большинства) страниц сайта, которые нужно будет хранить в кеше серверов CloudFlare полностью (весь html код с картинками, скриптами и стилями).

Если страницы со статьями вашего сайта (как и на моем блоге) оканчиваются на.html , то для их полного кеширования хватит одного единственного правила для страниц:

Сайт/*.html

Замените мое доменное имя на свое и все должно заработать. Довольно просто — знак * заменяет все, что может стоять между доменными именем и суфиксом.html.

Останется еще только добавить правило для полного кеширования главной страницы сайта:

Сайт/

Тут, думаю, все понятно и без пояснений. Единственное что, для главной страницы я время кеширования в браузерах пользователей выбрал поменьше, ибо содержимое этой страницы чаще других изменяется, и важно, чтобы она отображалась в более-менее актуальном состоянии.

Время же кеширования на серверах CloudFlare оставил большим, ибо при добавлении новой записи я просто сбрасываю кеш для главной способом описанным чуть выше. Очень удобно, только по первости нужно привыкнуть это делать.

Замечательно, когда все страницы кроме главной оканчиваются на.html. У меня же, например, рубрики и статические страницы (типа «О блоге») такого индекса не имеют. С рубриками особо мучиться не пришлось, ибо я выбрал, как оказалось, удачный шаблон, с обязательным словом (каталогом) «/category/», поэтому правило для этого типа страниц выглядит так:

Сайт/category/*

Ну, а со статическими страницами пришлось поизголяться, но вроде все получилось.

В итоге процент отдаваемых из кеша CloudFlare данных составил (по данным встроенной в эту систему аналитики) около 90%, что есть очень даже хорошо (по сути на эту величину снизилась нагрузка на сервер моего хостинга):

На отдельном аккаунте в CloudFlare (бесплатном) я разместил все остальные свои небольшие проекты. Т.к. правил для страниц можно было создать только три на бесплатном тарифе, то я решил пойти от противного — разрешить полное кеширование всего сайта, запретив потом трогать страницы админки .

Сразу скажу, что сработало как-то не очень. Вместо 90% загрузок из кеша, в этом случае я получил менее 50%. Но тем не менее свои решения я приведу, авось вы мне подскажите где я ошибся. Итак, первым правилом я разрешил кешировать все:

А вторым (этот сайт работает на Вордпресс ) — для страниц админки выбрал режим кеширования байпасс, т.е. не попадание этих страниц в кеш. Вроде все работает и скорость блога существенно выросла, но в аналитике менее 40 процентов трафика идет через CloudFlare (все остальное тянется с сервера хостинга). Почему? Для меня не очень понятно. При этом с работой в админке никаких проблем при этом не наблюдалось, что уже хорошо.

Если у вас сайт на joomla , то там админку можно забайпассить таким образом (наверное):

Domen.ru/admin*

В общем, сами смотрите какой вариант вам выбрать.

На одном из сайтов, подключенных к бесплатному аккаунту CloudFlare, вдруг возникли проблемы (он перестал открываться), поэтому для него я пока просто отключил «облачка» на вкладке «DNS» из верхнего меню:

После этого он начал открываться. Переносить NS записи на старые пока не стал — может быть возникнет желание поразбираться что к чему.

Что делать, если началась DDos-атака и как ее отразить?

Если вы подключились к КлоудФлэр именно из-за идущей в данный момент Ддос-атаки (или она началась после подключения), то ее вполне можно будет отразить или снизить эффект от нее даже на бесплатном тарифе этого сервиса. Для этого достаточно лишь перейти на вкладку «Overview» из верхнего меню и нажать на кнопку «Quick Actions» :

Выберите из выпадающего списка пункт «Under Attack Mode» и данный сервис начнет активно противодействовать Ddos-атаке.

Все пользователи (или боты) будут задерживаться перед обращением к серверу вашего хостинга сервисом CloudFlare на 5 секунд, за время которых он будет пытаться определить реальный ли это пользователь (браузер) или бот.

Реальные пользователи при этом будут наблюдать такую вот картинку на своем экране в течении 5 секунд (до открытия страницы вашего сайта):

Понятно, что такая «непонятная» надпись часть посетителей таки отпугнет — я наблюдал падение посещаемости в режиме «Under Attack Mode» примерно на четверть по отношению к нормальному режиму работы. Но лучше потерять четверть посетителей, чем все 100%. Согласитесь?

К тому же на тарифе PRO (о котором я писал выше) можно вид этой надписи поменять и снизить процент отказов (например, перевести ее на русский и добавить чуток креатива). По-любому возможность замечательная.

Однако, не стоит оставлять сайт в режиме «Under Attack Mode» дольше того времени, пока идет атака, ибо вы не только часть посетителей будете терять, но и все боты поисковиков будут отсекаться от сайта, что со временем не здорово скажется на посещаемости. Поэтому периодически отключайте режим «Under Attack Mode» простым нажатием на кнопку «Disable» (на вкладке «Overview»- см. скриншот выше) и смотрите на результат.

Если сайт опять стал недоступен (Ddos продолжается), то включайте Status: I"m Under Attack! взад. Так продолжайте часа через два мониторить окончание Ддос-атаки, чтобы не держать лишнее время сайт в этом безусловно полезном, но неоптимальном режиме «Под атакой».

На постоянной основе я предпочитаю использовать режим по умолчанию «Medium» . Кстати, поменять режим безопасности можно и без переключения в «Under Attack Mode». Сделать это можно на вкладке «Firewall» (из верхнего меню), выбрав нужный вариант из выпадающего меню кнопки с названием текущего Security Level:

Ну, и «I"m Under Attack!» отсюда тоже можно будет включить.

А в целом

Пока вроде все, что хотел и имею сказать. Полазайте еще по вкладке «Speed» и посмотрите, что там можно использовать. А вообще, извините за столь краткое описание этого безусловно примечательного сервиса, но что-то утомился печатать и скрины делать (видать сегодня не в форме).

В рунете подобного меценатства вкупе с ошеломляющей полезностью я пока не встречал. Посему не посчитал для себя обременительным перейти на тариф PRO с ежемесячным отстегиванием 20$.

В принципе, можно было этого не делать, но так как-то спокойнее, что ли...

CloudFlare посвящен пятый ролик из 6 видеоуроков по теме ускорения сайта , которые, на мой взгляд, имеет смысл посмотреть целиком, чтобы воспринимать картинку оптимизации в целом (нужный ролик можно выбрать из выпадающего списка в левом верхнем углу окна плеера):

Удачи вам! До скорых встреч на страницах блога сайт

Вам может быть интересно

Как добавить видео на сайт, чтобы не пострадала скорость загрузки страницы
Handyhost - как выбрать оптимальный для вас хостинг
Ускорение и защита вашего сайта в облачном сервисе Айри.рф
Измерение и увеличение скорости сайта в GTmetrix, а так же настройка загрузки библиотеки jQuery с Google CDN Как зарегистрировать домен (купить доменное имя у регистратора)
Как найти и удалить неиспользуемые строки стилей (лишние селекторы) в CSS файле вашего сайта