XenForo 2.x с nginx fastcgi_cache - полное кэширование страниц для гостей

[artscripts]

artscripts добавил(а) новый ресурс:

XenForo 2.x с nginx fastcgi_cache - полное кэширование страниц для гостей - Получайте возвращенные данные и сохраняйте их в хранилище дискового кэша в течение настраиваемого

Nginx включает в себя модуль FastCGI, в котором есть директивы для кэширования динамического содержимого, предоставляемого из бэкэнда PHP. Установка этого параметра устраняет необходимость в дополнительных решениях для кэширования страниц, таких как обратные прокси (например, Varnish) или плагины для конкретных приложений. Содержимое также может быть исключено из кэширования на основе метода запроса, URL-адреса, файлов cookie или любой другой серверной переменной.

1...

Узнать больше об этом ресурсе...

 

[-OZ-]

А где можно установить время жизни кеша для гостей в данном случае?

 

[Smalesh]

fastcgi_cache_valid      200 301 302 303 404 5m;

 

[blowzy]

Третий пункт не много не понятен, для точности, что именно из примера по ссылки и куда вставить? И блок ниже из описания ресурса куда? Или это и имеется, что блок из описания ресурса вставить только? Не пробовал, но прочитав описание что делать - этот третий пункт не очевиден.

 

[Smalesh]

Собственно о чем я и говорил - это мануал не для пошагово повторения ctrl+c -> ctrl+v, а требует вдумчивого подхода, имея за плечами хоть какой-то базис.
Ибо после фразы

Для сервера на базе centminmod

третий пункт не может быть не очевидным.

 

[blowzy]

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

 

[Smalesh]

не сбивать читателя лишней для него информацией

А это не ко мне, я об этом говорил давным давно

Мало того, что это заточено под centminmod-only, оно еще и не читабельно. Процентов 10-15 форумчан может поймут в чем дело, для остальных это даже для пошагово копипаста не прокатит.

У Вас недостаточно прав для просмотра ссылок. Вход или Регистрация

Тут более вменяемое Logged In Cookie
Хотя опять же - без должного опыта можно получить проблемы

 

[CrazyHackGUT]

Что ж, вот и настал момент, когда впервые смогли положить форум в обход этого решения. Просто додумались, что роуты входа и регистрации не кэшируются, и начали его "дрочить" на протяжении 5 минут:


Какие ещё есть варианты минимизировать нагрузку на сервер от гостей, помимо Ксеновского кэша?

 

[johnz]

Что ж, вот и настал момент, когда впервые смогли положить форум в обход этого решения. Просто додумались, что роуты входа и регистрации не кэшируются, и начали его "дрочить" на протяжении 5 минут:
Посмотреть вложение 139438

Какие ещё есть варианты минимизировать нагрузку на сервер от гостей, помимо Ксеновского кэша?

Лимиты поставить в самом nginx не пробовали?

limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;

server {
    # ...
    location /login.html {
        limit_req zone=one;
    # ...
    }
}

limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    # ...
    location /store/ {
        limit_conn addr 10;
        # ...
    }
}

 

[CrazyHackGUT]

johnz, стоит это всё, и не помогает. Там много разных адресов. Я бы сказал, очень много.
Пока погрепал по логам и отправил всех гипер-активных в бан на Фларе.

 

[johnz]

johnz, стоит это всё, и не помогает. Там много разных адресов. Я бы сказал, очень много.
Пока погрепал по логам и отправил всех гипер-активных в бан на Фларе.

Я так понял КлаудФлаер подключен и стоит режим - Under Attack? То есть всем принудеиельно показывает JS капчу.
И это все не помогло?

 

[CrazyHackGUT]

johnz, там сейчас какая схема.
Форум работает пассивно не в Under Attack режиме, с Low фильтрацией. Но капча принудительно показывается всем заходящим на /login или /register роуты.
Как только начинается атака, и длится больше 5 секунд (определяется по нагрузке на процессор), на флару идёт отстук, активируется Under Attack и "сбрасываются" все запросы, которые висели у PHP в очереди на обработку (чтобы сбить саму нагрузку в ноль, и дать нормальным клиентам не ждать в очереди обработки говна, а получить быстро страницу/скачать файл/etc.). И сохраняется этот режим не менее 5 минут.
Через 5 минут, если атака "утихла", Under Attack отключается. В противном случае его держит и дальше, и проверяет снова через 5 минут так же.

Вот Under Attack обходят как-то. Не вдавался в детали. Но обходят.

 

[johnz]

Получаеться если они обходят режим Under Attack, то и нет особого смысла тогда включать/отключать этот режим?
Даже если бы он был включен постоянно, то все равно не помогало бы?

 

[CrazyHackGUT]

johnz, не совсем.
Раньше он действительно помогал, когда это всё началось, сейчас его уже обходят, и пользы от него не то чтобы много.

 

[Rolzzandik]

Вот Under Attack обходят как-то. Не вдавался в детали. Но обходят.

Надо создавать кастомное правило в файрволле и юзать действие "Legacy captcha"

 

[CrazyHackGUT]

Rolzzandik, вчера уже DreamTails на это навёл

 

[valik228]

@johnz, там сейчас какая схема.
Форум работает пассивно не в Under Attack режиме

здравствуйте.
я тоже столкнулся с ДДОС-ом и если можно у меня к вам несколько вопросов.
у меня система весьма "детская" - сайт на домашнем сервере, подключенном по весьма "быстрому" гигабитному каналу и вся эта кухня работает через CloudFlare (такое решение было исторически, в связи со специфичностью контента, то есть как метод сокрытия айпи сервера и борьбой с роскомнадзором много лет тому). тарифный план бесплатный и тратить даже 20 баксов до недавнего времени не было никакой надобности, да и вообще проект не коммерческий...
и здесь кроется один основной как по мне нюанс - я не могу отключить вовсе CloudFlare и заняться фильтрацией у себя средствами линукса, iptables, сриптов анализаторов логов, "отключением азии" и т.д. (хотя опыт есть и немалый, и я бы справился, если бы не забили канал).
так вот, с месяц тому я тоже столкнулся с ДДОСом и мне какое-то время удавалось с ним справляться подтюнивая сервер и роутер, настраивая кеширование и т.д.. но они все время поднимают поток и вот что интересно - огромное кол-во ботов все же прорывается хотя на CloudFlare включен режим "under attack". и в конце-концов сначала они уложили весьма мощный, современный роутер (с двумя гигами ОЗУ и 4мя ядрами. банально закончилась память на conntrack, а отключить его я не могу, потому как на линке еще и домашние уст-ва и нужен NAT) и сейчас, как я понимаю, уже подбираются к укладыванию линка (у меня уже 8 процессов nginx отвечают за кеширование, что заметно напрягают 14-ядерный зеон хасвелл).
и вот здесь первый вопрос - мне вообще поможет как-то платный тариф CloudFlare? дело в том, что бесплатный не помогает вообще - ява-скрипт защита работает но огромное кол-во ботов все же тупо долбят в корень сервера). исходя из вашего опыта как вы считаете, отличаеются ли платные тарифы в плане защиты от ддос? или может быть стоит забить на CloudFlare и заняться поиском нормального антиддос-решения?
и второй вопрос - вы писали что как-то фильтруете в панели CloudFlare ботов. я у себя такой функции не нашел, это из-за бесплатного тарифа? или просто плохо искал?
буду весьма признателен за ответ. спасибо..))

upd:
один вопрос снимается частично - я такки нашел в панели управления CloudFlare возможность блокировать по айпи и множеству иных параметров. это конечно мне наука: век живи - век учись. но почему он так неочевидно называется, блин - WAF??!! неужели нельзя было раскрыть эту аббревиатуру..))
в общем теперь стал иной вопрос - как автоматизировать добавление айпи? я понимаю что есть апи, наверняка какие-то инструменты и т.п. возможно даже что-то готовое есть, что бы не изучать гору документации, а так сказать сразу в бой? подскажите пожалуйста если в курсе.


upd:
на данный момент вроде бы удалось побороть банальным rate limit-ом на стороне Cloudflare. всего-то нужно было внимательно пройтись по интерфейсу cloudflare и чуток покумекать...
но все равно остались некоторые вопросы, например почему огромное кол-во ботов проходит через JS-проверки ихнего фильтра. или вот, например, включил принудительно "юзать капчу" вместо JS-проверки, поставил максимальный уровень безопасноти и... и все равно не вижу никакой капчи, да и в логах везде JS Challenge, которое боты проходят без труда...

 

[MxR]

то есть как метод сокрытия айпи сервера

Наверное я Вас могу расстроить. Но Cloudflare не скрывает Ваш IP, он даже мне надцать раз выдавал IP адреса чужих сайтов.
+ Xenforo имеет возможность для пользователей, узнать IP сервера на котором стоит сайт. О чем знают не много людей, и пожалуй я об этом тоже рассказывать не буду, т.к пусть так оно и остается.
Но CF все еще хорош, для его использования Вам обязательно нужен веб-сервер после него которому Вы доверяете. Как раз этот сервер и может быть фильтрующим/кэширующим.
Классическая схема: CF <> Фильтрующий сервер <> Веб-сервер размещающий контент. В таком случае те кто обратятся в CF получат от него данные о фильтрующем сервере.
PS, в КФ есть возможность ставить капчу вручную для нужных страниц при требуемых условиях.

 

[johnz]

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

разговор по поводу изображений и не использовании proxy для изображений?

 

[MxR]

разговор по поводу изображений и не использовании proxy для изображений?

Скорее даже использовании проксирования/скачивания медиа средствами форума без прокси перед загружающим сервером. Это один из них.