Спасибо. Это режим DO, но я вернусь и доработаю настройку SSL. Это не режим Full (strict), а режим Full, который, как я полагаю, взаимодействует с Let’s Encrypt.
Я также включил защиту от ботов и ботов ИИ, а также добавил один очень специфичный гео-блок сервера.
Да, это странно. Некоторые из моих сайтов работают в режиме «Full», другие — в режиме «Full (Strict)». Это довольно необычно, учитывая, что все они работают на одном веб-сервере, ха-ха. Когда включите CloudFlare, проверяйте каждые несколько часов и попробуйте использовать VPN, чтобы обойти кэш DNS вашего провайдера и т. д. Думаю, один из моих сайтов использует только режим «Strict SSL» для origin pull, и в противном случае выдаёт ошибки, ха-ха. Если у меня возникает ошибка SSL, я просто меняю настройку на рабочую и оставляю её так. Из примерно 30 сайтов, на которых я использовал CloudFlare, у 100 % из них мне пришлось корректировать эту настройку через день или около того.
Я не сталкивался с ошибками SSL при просмотре, даже находясь в сети через VPN.
Только что проверил Qualys и получил оценку B четыре раза.
IP-адрес все это время не был защищен. При этом, как только вы добавите Cloudflare в цепочку, прямые запросы по IP-адресу станут невозможны. Правильно ли я понимаю?
В любом случае я сменю IP-адрес сервера.
В некоторой степени. Они не могут напрямую атаковать сайт или базу данных. Однако история DNS является общедоступной. Сайты вроде https://dnshistory.org/ и другие сохраняют её записи. Поэтому они всё ещё могут организовать DDoS-атаку на IP-адрес. Обычно я замечаю, что DDoS-атаки на конкретные IP-адреса случаются редко, если злоумышленники не знают, что на них размещено. Это пустая трата их DDoS-трафика, так как они не видят никаких результатов от своих действий.
Вау. Ваш последний график на панели управления удивительно похож на мой, но у вас более значительный объем трафика.
Возможно, и сроки совпадают. Реальный рост начался примерно 7 дней назад.
Кажется, было две фазы.
Сначала небольшой рост, который сохранялся в течение нескольких дней — казалось, это приятное увеличение трафика, а затем последовал второй этап с резким всплеском.
Ваши географические локации тоже идентичны.
Действительно похоже на одну и ту же волну.
Сейчас не могу опубликовать сравнительные графики.
Главным виновником оказался ASN Huawei в Сингапуре. Как только он был заблокирован, этот трафик рухнул.
Еще одним последствием стало то, что метрики AdSense практически мгновенно пришли в негодность.
Начиная с 2019 года Huawei начала инвестировать в Сингапур как в центр искусственного интеллекта.
Один и тот же ASN Huawei из Сингапура обрабатывал трафик из Мексики и Гонконга.
Кто-нибудь знает, как это работает? Подмена местоположения?
Также обратите внимание на ваши «другие» колонки по отдельности. Это может быть удивительно, шокирующе или и то, и другое!
Даже если вы не подвергаетесь DDoS-атаке. Я нашел полезным этот гайд, размещенный в сообществе Cloudflare на их форуме (Discourse), так как он сфокусирован на возможных точках действия, которые можно проработать.
https://community.cloudflare.com/t/mitigating-an-http-ddos-attack-manually-with-cloudflare/302366
Когда пиковый трафик от роя достиг максимума, показатель отказов подскочил выше 80% — обычно при обычном трафике он находится в диапазоне от низких до средних 20%.
Во время всплеска активности я могу подтвердить, что среднее время взаимодействия также резко снизилось, как и в вашей аналитике, @piffy, и на этот раз наблюдается аналогичное падение.
Обычно я не обращаю внимания на эту метрику, но сделал это, так как вы опубликовали свой график. Я считаю, что среднее время взаимодействия или показатель отказов — это хорошие индикаторы того, что с качеством и типом трафика что-то серьёзно не так.
Странно, что я вижу ещё один скачок показателя отказов до почти 80% на данных за один день , но при этом нет всплеска. Уровень трафика выглядит нормальным, то есть как до всплеска.
Данные аналитики были с задержкой: наблюдается небольшой всплеск, примерно 30% от предыдущего мега-всплеска. Та же картина повторяется. Единственное отличие — CF справляется с этой нагрузкой, и сервер продолжает работать, но это плохо, так как это разрушает метрики вовлечённости пользователей.
Мое решение состояло в том, чтобы заблокировать все страны, где нет португальских говорящих, но я всё ещё получаю высокий трафик из своей страны — США, и из Германии.
Мне кажется, что Бразилия является основным источником таких атак, поэтому моя попытка не удалась. У меня 20 активных участников, но 2 миллиона запросов в месяц по количеству.
Невероятно, что мой инстанс продолжает получать трафик из Федериверсо, даже когда плагин отключён. Я устал и не знаю, как решить эту проблему.
Что касается защиты от атак через Cloudflare, вот что помогает мне:
Боты
Правила WAF 1)
ASN — вызов JS применён / ASN = 136907
(локации в порядке убывания трафика)
Проверьте, не атакует ли вас тот же ASN, например @piffy. Этот трафик выглядел как реальный в Google Analytics: он поднял показатель отказов до 80% и обрушил вовлечённость пользователей. По всей видимости, это также негативно влияет на RPM/CPC в AdSense.
Правило WAF 2)
Гео-вызов JS применён (в порядке убывания трафика)
Кажется, снова вырос поток запросов через Cloudflare, и те же географические регионы лидируют. Поэтому я применил гео-вызов JS к этим трём основным источникам.
Это вмешательство направлено прежде всего на восстановление здоровья аналитики и метрик вовлечённости пользователей. Данный трафик больше не создаёт нагрузки на сервер, поскольку Cloudflare обрабатывает большую часть запросов через кэширование и защиту от ботов, однако в целом метрики серьёзно искажаются. Это агрессивный трафик.
Я обновлю информацию, если увижу улучшение метрик аналитики, AdSense и т.д.
Я сделал это, и теперь снова заблокировал все страны, применив другие правила. На какое-то время достаточно было только управления вызовами, и, похоже, источники атак замедлились.
Теперь моя вовлечённость выросла на 131%, а уровень отказов снизился на 16%. Я предполагаю, что это импульсивное поведение со стороны Play Store, поэтому мне нужно подождать пару недель, чтобы понять, является ли этот рост ботами или легитимным трафиком.
Правило WAF №2 успешно отсекло лишний трафик, применив JS-задачу с гео-фильтрацией.
Ранее соотношение было примерно 4:1
Cloudflare:OriginServer
Теперь оно приблизилось к 1:1.
Эти регионы по-прежнему отправляли огромный объем трафика.
Система аналитики выдавала предупреждения об аномалиях, а метрики в ней оставались хаотичными.
Adsense серьёзно пострадал: RPM страниц упал почти до 0,00$ на фоне всплеска. Похоже, Adsense определил это как подозрительный трафик и приостановил учёт.
Дашборд
Вот как выглядели дашборды: последние 5 дней показатели ниже, поскольку с этого момента была развернута защита Cloudflare. Если бы её не включили, нет причин полагать, что этот трафик перестал бы расти.
Для сравнения: трафик по категории Other (красный) в самый пиковый день был почти в 10 раз больше, чем трафик по категории Anon (зелёный). Позвольте этому осесть. 
Надеемся, что в ближайшие 2–3 дня ситуация стабилизируется.
Задача: JS не дает того же эффекта, что и управляемый режим. Я применил почти то же самое — блокировку прямых ссылок на медиафайлы и библиотеки, такие как CSS и JS, и это работает. Блокировка осуществляется по рефереру (прямой доступ из вкладки = заблокировано). Это помогает мне снизить потребление трафика и загрузку процессора.
Я оставлю JS Challenge в силе на некоторое время, поскольку пока CSR (уровень успешного прохождения вызова) = 0%.
Я попробую Managed после того, как трафик стабилизируется и/или CSR начнет показывать сбои.
Сейчас соотношение CF:OS выглядит как ещё более тесное 1:1.
Состояние Mitigated заняло место и резко выросло.
Меня интересует, почему атаки продолжаются, если они блокируются JS после определённого периода (всё-таки они не очень изощрённые?), и будут ли попытки проникновения через другие ASN и географические локации?
Если это произойдёт, я попробую Managed для любых новых векторов атак.
Поскольку JS Challange имеет ту же цель, но худшую эффективность, чем ‘Manage Challange’, возможно, она устарела, так как эта опция не показывает мне капчу, а просто отклоняет меня как легитимный трафик, как это делает ‘managed’.
Я нашел эту тему на meta, которая, как мне кажется, представляет глубокий интерес и, вероятно, лучше всего будет смотреться как отдельная тема Cloudflare Security WAF (Web Application Firewall) + Discourse?
Ещё один полезный ресурс — https://radar.cloudflare.com/
Я сказал, что обновлю тему, и вот обновление.
В целом, защита от Cloudflare на бесплатном тарифе отлично подошла как решение на данный момент, то есть на ближайшее короткое время.
В каком-то смысле я жалею, что не знал, что Cloudflare можно использовать с Discourse, но как-то упустил эту информацию.
Различные меры по защите с использованием Cloudflare почти мгновенно остановили ложный трафик из Сингапура, Гонконга и Мексики (вероятно, поддельные источники).
Вчера и сегодня наблюдалась тенденция: те же источники трафика, похоже, прекратили попытки, так как объём резко упал. Примерно столько времени и потребовалось, чтобы они, возможно, сдались.
Однако пока ещё рано делать окончательные выводы.
Также мне стало легче выявлять другие кратковременные атаки и бот-трафик.
Полагаю, что Cloudflare в конечном итоге нейтрализует эти атаки примерно через 30–60 минут. Именно на всплески, обслуживаемые Cloudflare, стоит обращать особое внимание: это упрощает определение исходных ASN или географических локаций и добавление их в чёрный список или применение соответствующих правил WAF.
Ссылка на Radar https://radar.cloudflare.com/bots/ оказалась очень полезной для оценки качества ASN. Я выделил несколько кластеров серверов WOW, которые, как я предполагаю, относятся к серверам World of Warcraft 
. Они постоянно появлялись во время всплесков.
Я также заметил, что трафик вернулся к более обычным уровням и стал более стабильным и равномерным по ритму.
Показатели AdSense почти вернулись к норме или, по крайней мере, начали восстанавливаться (то есть даже плохой RPM лучше, чем отсутствие RPM!) 
Это, вероятно, первый раз, когда я видел, как трафик создаёт такую нагрузку на сервер, что сервис начал с трудом справляться. В данном случае, помимо других мер, таких как смена IP-адреса сервера, Cloudflare в целом стал отличным быстрым и управляемым решением, особенно когда нет времени на эксперименты или необходимых навыков для настройки nginx и подобных инструментов во время нарастающих атак. Благодаря этому Droplet с минимальной спецификацией работает почти в режиме простоя, имея запас мощности за пределами своих технических характеристик.
