Данный майнер очень часто атакует docker контейнеры, смотрящие наружу. Он сканирует сервер и по заранее подготовленным RCE заползает на сервер.
Если юзаешь контейнеры, бегом проверять версии образов, скорее всего какой-то из них смотрит наружу и давно не обновлялся.
Сделай следующее:
1. Просканируй свой сервер через nmap на наличие открытых портов (если какой-то из них торчать не должен - убираешь и берешь на будущее на вооружение)
2. Проверь версии образов docker / софта - найди тот, который самый старый (обновляешься - берешь на будущее на вооружение)
3. Если есть возможность развернуть содержимое сервера на чистой и свежей ОС - сделай это, скомпроментированный сервер уже != безопасность
У моего клиента на сервере был такой же кейс:
/var/www/app # ps aux
PID USER TIME COMMAND
1 root 0:06 php-fpm: master process (/usr/local/etc/php-fpm.conf) 2159 www-data 0:09 /tmp/kinsing
2328 www-data 18h05 /tmp/kdevtmpfsi
2900 www-data 0:04 php-fpm: pool www
2901 www-data 0:02 php-fpm: pool www
2902 www-data 0:01 php-fpm: pool www
2903 root 0:00 sh
2911 root 0:00 ps aux
Прикол был в том, что был docker и был docker compose, в секции ports (в docker-compose.yml) не были закрыты для внешки контейнеры. Был старый redis, подробности есть здесь.
Лучше делай полный бэкап данных, потом разворачивай на чистом сервере, закрывай от внешки все, что не должно туда смотреть.
Лев Салатов, звучит как sql inj, где-то экранируется id при получении его из запроса?
Если нужно использовать некий символьный код для страниц, а не id, например уйти от site.ru/page/1 на site.ru/page/someshit, тогда нужно ввести столбец строковый slug и уже по нему делать выборку. И опять же, экранирование!
heavig2, пункт 3 может частично помочь, чтобы данные не терялись. На http запросах ничего не изобретешь, тут только сокеты помогут, прям пушить на бэк каждый клик там можешь, ничего не теряя.
Наилучшим вариантом для такого функционала будут сокеты, долбёжка обычными запросами по http никогда до добра не доводит. При высокой нагрузке упадёте просто. С сокетами отпадет надобность переживать, не потерял ли кто-то клики и все ли зарегало.
На примере того же хомяка, он раз в какой-то период (условно 2 секунды), отправляет количество кликов, которые пользователь накликал за это время. Соответственно, на бэкенде просто суммируется это значение с возможными проверками на накрутку (чтобы не прислали фейковое количество, которое явно за 2 секунды не прожать).
Если я правильно тебя понял, то нужно, чтобы и клики регались и тот, кто вышел - не потерял своё настоящее количество. Поэтому решение:
0. Юзер зашел в приложение выгружаешь ему его клики
1. Запускаешь setInterval (ну 5 секунд например) и когда он срабатывает отправляешь запрос на бэкенд с количеством кликов за этот период, не забывая обнулить каунтер не отправленных кликов
2. Количество не отправленных кликов дублируешь в localStorage и обнуляешь его, когда запрос уходит на бэкенд (см. пункт 1)
3. Перехватываешь событие закрытия окна/приложения и шлешь последний запрос на бэк, если не отправленные клики > 0 (этот вариант на самом деле тут по приколу, я обычно так не делаю, поскольку последний запрос не отправится, если у юзера отвалится интернет)
4. Ну и при открытии приложения смотришь, если localStorage не 0, отправляешь запрос на бэкенд
Это как один из возможных сценариев развития.
По факту, если зайдет какой-то веб разраб он сможет себе накрутить клики, просто поигравшись в девтулзах браузера и отправив нужные данные в запросе, просто помни об этом.
Если юзаешь контейнеры, бегом проверять версии образов, скорее всего какой-то из них смотрит наружу и давно не обновлялся.
Сделай следующее:
1. Просканируй свой сервер через nmap на наличие открытых портов (если какой-то из них торчать не должен - убираешь и берешь на будущее на вооружение)
2. Проверь версии образов docker / софта - найди тот, который самый старый (обновляешься - берешь на будущее на вооружение)
3. Если есть возможность развернуть содержимое сервера на чистой и свежей ОС - сделай это, скомпроментированный сервер уже != безопасность
У моего клиента на сервере был такой же кейс:
Прикол был в том, что был docker и был docker compose, в секции ports (в docker-compose.yml) не были закрыты для внешки контейнеры. Был старый redis, подробности есть здесь.
Лучше делай полный бэкап данных, потом разворачивай на чистом сервере, закрывай от внешки все, что не должно туда смотреть.