Пользователи, гости, боты

[daitepiva]

Анализирую таблицу ibf_sessions на предмет количества пользователей, гостей и ботов онлайн (за 15 минут).

 

Получается так:

- пользователи - записи, в которых идентификатор пользователя больше нуля (member_id>0) или же другой вариант с тем же результатом - имя и идентификатор пользователя не пустые (member_id!=0 and member_name!='');

- гости - записи, в которых имя и идентификатор пользователя пустые (member_id='' and member_name='');

- боты - записи, в которых идентификатор сессии заканчивается на "_session" (id like '%_session');

 

У меня получается так:

members=843 guests=3754 bots=8963

В сумме примерно соответствует числу, отображаемому в панели управления админки в строке "Состояние системы пользователей онлайн".

 

Вроде всё верно, но в результате получается огромное количество ботов и небольшое количество пользователей. До этого, в версии движка 2.4, общее количество было примерно таким же, а пользователей получалось примерно в два раза меньше чем гостей и ботов.

 

Для проверки посмотрел какие боты попадаются:

      1 MSN

      4 Baidu

     11 BrandWatch

     11 Yandex

     20 Majestic12

     25 Ahrefs

     27 Bing

     40 Yahoo

     53 Alexa

   1258 Google Mobile

   6987 Google

 

Ничего лишнего.

 

Что я делаю не так? А как у вас?

 

[FatCat]

6987 Google

Это количество хитов за 15 минут или количество открытых сессий на бота?

 

В любом случае это много. Грузит сервер.

[daitepiva]

Это открытые сессии, причём за последние 15 минут.

Я ограничил активность Гугл-бота через консоль вебмастера на Гугле. Там было указано максимальное количество запросов - 10 в секунду. Поменял на 5. В течение суток количество ботов резко упало раз в 5. Правда резкого снижения нагрузки я не заметил.

 

[Denis Chursinov]

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

[daitepiva]

Ну да, юзер-агент штука не надёжная. Но в данном случае резкое снижение количества ботов после изменения настройки указывает, что это всё-таки Гугл. Фейковые Гугл-боты если и есть, то заметного влияния не оказывают.

 

Я особо на юзер-агент не ориентируюсь, только для ознакомления. Для блокировки чересчур активных адресов буду ориентироваться на айпишники вне зависимости от типа пользователя. Вот вчера с одного айпишника нагенерили около пяти тысяч гостевых сессий в течение минут 10-15. Нагрузка, конечно, была такая, что сайт не  отвечал вообще. Load-average превысил сотню, а количество запросов в очереди MySQL было около 400.

 

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

[FatCat]

Лучше всего было бы встроенное в движок принудительное кеширование для гостей

У меня другой костыль, и мой мне нравится больше.

Во-первых, сессия гостей жестко привязана к айпишнику - идентификатор сессии эмдепятка айпишника. Только авторизованным пользователям дозволяется иметь несколько сессий с одного айпишника - эмдепятка от айпишник+логин. Ботам независимо от айпишника одна сессия на бота.

Во-вторых, в функции апдейта гостевой сессии проверяется время предыдущего обращения, и если прошло меньше 2 секунд, посетитель получает страницу ошибки с текстом просьбы не совершать двойных кликов. Одновременно в специальное поле-счетчик добавляется единичка.

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

В результате не только отсеивается всякая шваль, но и в случае ДоС-атаки форум не так легко положить.

[Denis Chursinov]

Все равно же требуется проинициализировать все, прочитать таблицу сессий, в случае ДДОСА не очень эффективно.

Такое нужно делать на уровне nginx. Ставим ограничение на количество обращений к некоторым локейшенам. При превышении юзер получает экзотическую ошибку, например 429. 429 ошибки складываются в отдельный лог. Лог читает fail2ban и при достижении нужного количества в единицу времени добавляет IP в файрволл или в черный список nginx.

[FatCat]

Все равно же требуется проинициализировать все, прочитать таблицу сессий, в случае ДДОСА не очень эффективно.

Нагрузка на сервер примерно в 50 раз меньше, чем при генерации обычной страницы топика.

 

 

 

 

Такое нужно делать на уровне nginx

Согласен. 

Но я сделал в движке, сделал на php. Я не сисадмин, и даже не программист. Я просто врач, умеющий пользоваться поиском гугл и собственной логикой.

Как результат, phpforum.su - на шаред-хостинге - начинает притормаживать при плотности атаки 5-6 тысяч обращений в минуту с разных айпишников. Когда лупит с одного айпишника больше 50 запросов, нагрузка вовсе минимальная: никакие переменные не инициализируются, к БД не подключаемся - бан по айпишнику. При очень мощной атаке у меня есть опция перезаписывать эйчтиакцесс. Правда, был случай, когда форум таки положили: буквально за несколько часов многогиговый акцесс-лог переполнил квоту дискового пространства.

[daitepiva]

Во-первых, сессия гостей жестко привязана к айпишнику - идентификатор сессии эмдепятка айпишника. Только авторизованным пользователям дозволяется иметь несколько сессий с одного айпишника - эмдепятка от айпишник+логин. Ботам независимо от айпишника одна сессия на бота.

Т.е. если идёт запрос с некоего айпишика, но в БД есть уже другой ИД сессии для этого айпишника, то клиент получает сообщение об ошибке? А как же клиенты за NAT-ом или прокси? Их может быть десятки и даже сотни с одного айпишника. А ещё, насколько я знаю, браузеры открывают по несколько сессий к сайту чтобы загружать объекты с него в несколько потоков. Получается, чтобы нормально работать с сайтом требуется обязательно залогиниться?

 

А ботов от людей вы как отделяете?

 

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

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

 

Ставим ограничение на количество обращений к некоторым локейшенам.

К каким? Заранее же непонятно на какой адрес будут долбиться атакующие. Скорее всего это будет главная страница, но не факт.

К тому же, сейчас атаки настолько распределённые, что обращений будет очень много, но с разных айпишников, так что все и не перебанишь.

 

Всё-таки я больше за принудительное кеширование. Я делал вот так - средствами nginx-а пытался по кукам отделить гостей от авторизованных пользователей. Гостей перенаправлял в кеш, который хранился в nginx, например, одну минуту (у меня форум часто обновляется). Получалось, что все обращения гостей в течение минуты получали ответ из кеша. Однако, проблема оказалась в том, что с куками какая-то путаница - зачастую те или иные куки (ИД юзера или группы, хеш и т.п.) могут быть или не быть вне зависимости от того гость это или авторизованный пользователь.

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

 

Есть ещё другая идея. В том же nginx-е разделить запросы POST и GET между двумя апстримами (php-fpm), POST-запросы будет обрабатывать основной апстрим, подключенный к основной БД, а GET-запросы уйдут ко второму апстриму, у которого будет своя копия скриптов сайта и обращаться он будет к реплике БД. Конечно, сложновата схема и требует дополнительных ресурсов. Но самая главная проблема - отставание репликаций MySQL. Может получиться так, что пользователь написав сообщение (в основную БД) не увидит его (из реплики).

[FatCat]

Т.е. если идёт запрос с некоего айпишика, но в БД есть уже другой ИД сессии для этого айпишника, то клиент получает сообщение об ошибке?

Нет конечно. Апдейтится имеющаяся сессия. Новая сессия не создается.

 

Изменено 22 Марта 2017 пользователем FatCat