yodda#: Понятно что по закладкам любой дурак зайдет. А вот если чел просто хочет попасть через их сайт, как и положено у всех нормальных хостингах, то как? Явно там с головой какие то проблемы у администрации начались.
Я им по этому поводу даже тикет писал. Отписку прислали, что "идут технические работы".
Врут, как дышат. Ни один нормальный бизнес не будет стрелять себе в ногу такими "работами".
Короче вы меня окончательно убедили переезжать. Жаль.
yalol#: Подскажите, что за непонятные страницы в статистике, на них есть переходы .? Причем таких страниц много
Блокируйте такие страницы на уровне сервера.
Из-за таких переходов и может падать сайт. Каждый переход на новый URL, в зависимости от настроек CMS и окружения, пытается получить страницу из кэша. Если её там нет - генерирует ответ на живых данных и записывает новый кэш.
Многие CMS/плагины страдают тем, что даже если основной адрес не меняется, но в параметрах URL есть уникальное значение, то страница уже не считается закешированной.
Боты перебирают тысячи "уникальных" страниц с рандомными параметрами и создают нагрузку на сервер, потому что каждый запрос обходит кэш и создаёт новый.
Это называется Cache Busting Attack, Cache Bypass DDoS, Random Query String Attack, Cache Key Flooding и так далее...
На практике, даже если сервер успевает кэш формировать, происходит его переполнение, что приводит к вытеснению действительно важных записей, а иногда и падению сервера. Сервер перезагружаете, кэш пул сбрасывается и на какое-то время его опять хватает.
Так же стоит посмотреть что, как и чем у Вас кэшируется и что для этого используется. Самые простые кэширующие алгоритмы записывают "слепки" страниц на диск в обычный HTML и потом с него их отдают. Системы поумней таким не занимаются и кэшируют только запросы в Redis, например. В зависимости от решения у кэширования может наступать предел.
В вашем случае это, возможно, случайный побочный эффект от работы ботов, а не сама их цель.
И эту проблему еще надо диагностировать, прежде чем подтвердить или опровергнуть, но это я Вам из своей практики говорю, так как часто с таким сталкивался: от целенаправленных атак до неправильной настройки каких-то компонентов, что приводило случайно к плачевным последствиям.
Ghidra всё шикарно делает, но у агента есть встроенный таймаут в 30 минут на операцию, а сначала и через меньший срок ругался, что гидра "зависла". Гидра работает, но чтобы декомпилировать бинарник на 600+ МБ ей нужен не один час работы. В итоге агент в один из заходов просто сожрал весь свой 5-часовой лимит просто на ожидания и какие-то попытки что-то вымутить у гидры в процессе.
Всё решилось отдельным запуском гидры, к отчёту которой агент подрубился через MCP и смог его прочитать.
Так же были траблы:
с обнаружением инструментов: в PATH были прописаны правильные пути, но в терминале инструменты не доступны;
обновился какой-то конфиг у внешнего тула, что сделало его несовместимым, пришлось переустанавливать частично всю rea, дабы разрулить;
агент упёрся в тупик, не мог найти нужные строки, несколько часов он на это убил, поняв, что не там ищет (не тот уровень данных);
и еще 100500 мелких багов и косяков...
Так что REA полезен, но не панацея. Нет тут кнопки "сделай красиво", всё равно надо допиливать и самому немного разбираться, если не в программировании, то хотя бы в архитектуре этой связки.
Что пока еще не пробовал реверс-инженерить - это сайты. Но это следующим этапом.
Да они просто ребрендятся на 3 юрлица, эстонское, американское и русское.
Понятно что по закладкам любой дурак зайдет. А вот если чел просто хочет попасть через их сайт, как и положено у всех нормальных хостингах, то как? Явно там с головой какие то проблемы у администрации начались.
Я им по этому поводу даже тикет писал. Отписку прислали, что "идут технические работы".
Врут, как дышат. Ни один нормальный бизнес не будет стрелять себе в ногу такими "работами".
Короче вы меня окончательно убедили переезжать. Жаль.
Бегите от туда, пока есть шанс. Там творится хрен знает что
в тикетах быстро отвечают же.
По сабжу. Спросил сегодня у юзера, говорит, что с мобайла сайт стал доступен. На домашнем провайдере пока еще нет.
Странно как-то.
Вбить любой адрес кф тоже блокировок не показывает.
да, часть сетей в бане ркн, но часть работает
https://cheburcheck.ru показывает, что блокировок нет.
Откуда инфа о частичных блокировках?
Подскажите, что за непонятные страницы в статистике, на них есть переходы .? Причем таких страниц много
Блокируйте такие страницы на уровне сервера.
Из-за таких переходов и может падать сайт. Каждый переход на новый URL, в зависимости от настроек CMS и окружения, пытается получить страницу из кэша. Если её там нет - генерирует ответ на живых данных и записывает новый кэш.
Многие CMS/плагины страдают тем, что даже если основной адрес не меняется, но в параметрах URL есть уникальное значение, то страница уже не считается закешированной.
Боты перебирают тысячи "уникальных" страниц с рандомными параметрами и создают нагрузку на сервер, потому что каждый запрос обходит кэш и создаёт новый.
Это называется Cache Busting Attack, Cache Bypass DDoS, Random Query String Attack, Cache Key Flooding и так далее...
На практике, даже если сервер успевает кэш формировать, происходит его переполнение, что приводит к вытеснению действительно важных записей, а иногда и падению сервера. Сервер перезагружаете, кэш пул сбрасывается и на какое-то время его опять хватает.
Так же стоит посмотреть что, как и чем у Вас кэшируется и что для этого используется. Самые простые кэширующие алгоритмы записывают "слепки" страниц на диск в обычный HTML и потом с него их отдают. Системы поумней таким не занимаются и кэшируют только запросы в Redis, например. В зависимости от решения у кэширования может наступать предел.
В вашем случае это, возможно, случайный побочный эффект от работы ботов, а не сама их цель.
И эту проблему еще надо диагностировать, прежде чем подтвердить или опровергнуть, но это я Вам из своей практики говорю, так как часто с таким сталкивался: от целенаправленных атак до неправильной настройки каких-то компонентов, что приводило случайно к плачевным последствиям.
можно посмотреть патченный PHP в свете последних уязвимостей, проверить бинарник на наличие кода правки
Для этого достаточно посмотреть версию PHP.
Но для поиска новых уязвимостей - да.
Поставил, за 3-4 дня ради интереса и теста сделал чит для онлайн игры, которого раньше не было )))
Но жрёт токенов немеренно!
REA сама ничего не "вскрывает", а лишь предоставляет инструкции и MCP для работы с внешними декомпиляторами.
Поддерживает Hopper (https://www.hopperapp.com/) и Ghidra (https://github.com/nationalsecurityagency/ghidra). Первый вариант оказался платным и при запуске через MCP не работал, потому что даже в headless режиме без UI ждал какое-то нажатие галочки с согласием на демо режим.
Ghidra всё шикарно делает, но у агента есть встроенный таймаут в 30 минут на операцию, а сначала и через меньший срок ругался, что гидра "зависла". Гидра работает, но чтобы декомпилировать бинарник на 600+ МБ ей нужен не один час работы. В итоге агент в один из заходов просто сожрал весь свой 5-часовой лимит просто на ожидания и какие-то попытки что-то вымутить у гидры в процессе.
Всё решилось отдельным запуском гидры, к отчёту которой агент подрубился через MCP и смог его прочитать.
Так же были траблы:
Так что REA полезен, но не панацея. Нет тут кнопки "сделай красиво", всё равно надо допиливать и самому немного разбираться, если не в программировании, то хотя бы в архитектуре этой связки.
Что пока еще не пробовал реверс-инженерить - это сайты. Но это следующим этапом.