1. Проверка запущенных процессов (ps ux -u bitrix)
Что показывает ваш вывод:
- `httpd -DFOREGROUND`: Это рабочие процессы веб-сервера Apache. То, что они запущены от пользователя `bitrix`, — это стандартная и правильная конфигурация для "1С-Битрикс: Виртуальная машина". Apache обрабатывает PHP-скрипты сайта.
- `nginx: worker process`: Это рабочие процессы веб-сервера Nginx, который обычно используется как прокси-сервер перед Apache для раздачи статического контента (картинки, css, js). Это тоже абсолютно нормальная часть стандартной конфигурации.
- `ps ux -u bitrix`: Сама команда, которую вы запустили для получения этого списка.
Вывод: На первый взгляд, все процессы выглядят легитимными и ожидаемыми для работающего сайта на Битриксе. Среди них нет ничего очевидно подозрительного (вроде майнеров, IRC-ботов или странных скриптов).
Что стоит улучшить: Вы проверили процессы только пользователя `bitrix`. Злоумышленник мог запустить процесс от другого пользователя, например, `www-data`, `apache` или, что хуже всего, `root`.
Правильная команда для проверки ВСЕХ процессов:bash
ps aux Или, для удобства, можно отсортировать по использованию CPU или памяти с помощью `top` или `htop`:bash
# Установите, если его нет: sudo dnf install htop
htop В `htop` (или `top`) смотрите на процессы, которые активно потребляют CPU/память, и на процессы с подозрительными именами (например, `kswapd0` с нулём вместо "o", или случайный набор букв).2. Проверка заданий в crontab
Что показывает ваш вывод:
- `crontab -l` -> `no crontab for bitrix`
Это означает, что у пользователя `bitrix` нет личных заданий в cron. Это хорошо.
Что стоит улучшить: Это самая частая ловушка. Вы проверили только cron пользователя `bitrix`. Злоумышленники почти всегда добавляют свои задачи в cron от имени `root` или в общесистемные директории.
Обязательно проверьте:
- Cron пользователя `root` (нужны права `sudo` или `root`):bashsudo crontab -l -u root- Общесистемные файлы cron:# Проверяем, нет ли посторонних файлов в этих директориях
sudo ls -la /etc/cron.d/
sudo ls -la /etc/cron.hourly/
sudo ls -la /etc/cron.daily/
sudo ls -la /etc/cron.weekly/ Изучите содержимое всех нестандартных файлов в `/etc/cron.d/`. Часто там можно найти строки с `curl` или `wget`, скачивающие и запускающие вредоносные скрипты. Например: `sudo cat /etc/cron.d/malicious-file`.3. Проверка SSH-ключей
Что показывает ваш вывод:
- `last -i whoami`: Эта команда выполнена некорректно. Она не покажет историю входов для пользователя `bitrix`. Она попытается найти пользователя с именем "whoami".
- `cat ~/.ssh/authorized_keys`: Вы выполнили правильную команду для просмотра ключей, но не предоставили вывод.
Как правильно проверять:
-
Ключи текущего пользователя (`bitrix`):cat ~/.ssh/authorized_keys Внимательно просмотрите каждый ключ в этом файле. Если вы видите ключ, который вы или ваши администраторы не добавляли, — это критический красный флаг. Это означает, что кто-то может зайти на сервер под пользователем `bitrix` без пароля. Немедленно удалите незнакомые ключи.
-
Ключи пользователя `root` (самое важное): Точно так же, как и с cron, злоумышленники в первую очередь пытаются получить доступ к `root`.sudo cat /root/.ssh/authorized_keys Если в этом файле есть посторонний ключ, считайте, что сервер полностью скомпрометирован.
-
История входов в систему: Чтобы посмотреть, кто и откуда заходил на сервер, используйте команду `last` или `lastb`.# Показывает последние успешные входы
last -a
# Показывает последние неудачные попытки входа (очень полезно!)
sudo lastb -a В выводе этих команд обращайте внимание на IP-адреса, с которых происходили подключения. Если видите незнакомые IP из других стран — это повод для беспокойства.Комплексный чек-лист (что еще проверить)
Помимо ваших пунктов, вот полный чек-лист для базового аудита безопасности:
✅ 1. Проверить сетевые соединения: Какие программы "слушают" порты и куда установлены соединения?# Показывает все активные TCP/UDP соединения и процессы, которые их используют
sudo ss -tunap Ищите `ESTABLISHED` соединения с подозрительными IP-адресами.
✅ 2. Проверить системных пользователей: Не появился ли новый пользователь?cat /etc/passwd Просмотрите список в конце файла на предмет незнакомых имен.
✅ 3. Проверить недавно измененные файлы: Злоумышленники часто оставляют веб-шеллы или другие скрипты.# Искать все PHP-файлы в корне сайта, измененные за последние 3 дня
sudo find /home/bitrix/www/ -name "*.php" -mtime -3 Проверьте найденные файлы. Часто вредоносный код обфусцирован (запутан) и использует функции вроде `eval`, `base64_decode`, `gzuncompress`.
✅ 4. Проверить логи аутентификации:# Для CentOS/RHEL/Fedora
sudo journalctl -u sshd | grep "Accepted" Эта команда покажет все успешные SSH-входы. Снова ищите незнакомые IP.
- Процессы: Те, что вы показали, выглядят нормально.
- Crontab: Проверка была неполной. Обязательно проверьте `root` и системные директории.
- SSH-ключи: Команда была верной, но нужно проанализировать результат и обязательно проверить ключи `root`.
Вы на правильном пути. Пройдитесь по расширенным командам, которые я предоставил, и у вас будет гораздо более полная картина состояния вашего сервера.
ps aux --sort=-%cpu | head -n 20 # Посмотреть все процессы в виде дерева, удобно для поиска аномалий pstree -p USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND mysql 1147 3.4 22.4 6370124 1827828 ? Ssl Jul04 560:11 /usr/sbin/mysqld root 814001 0.4 0.1 20960 12416 ? Ss 13:43 0:00 sshd: root [priv] root 814006 0.1 0.1 22352 11776 ? Ss 13:43 0:00 /usr/lib/systemd/systemd --user root 814021 0.1 0.1 19740 8448 ? Ss 13:43 0:00 /usr/lib/systemd/systemd-hostnamed root 1 0.0 0.1 171380 13312 ? Ss Jul04 8:12 /usr/lib/systemd/systemd --switched-root --system --deserialize 31 root 2 0.0 0.0 0 0 ? S Jul04 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S Jul04 0:00 [pool_workqueue_] root 4 0.0 0.0 0 0 ? I< Jul04 0:00 [kworker/R-rcu_g] root 5 0.0 0.0 0 0 ? I< Jul04 0:00 [kworker/R-sync_] root 6 0.0 0.0 0 0 ? I< Jul04 0:00 [kworker/R-slub_] root 7 0.0 0.0 0 0 ? I< Jul04 0:00 [kworker/R-netns] root 9 0.0 0.0 0 0 ? I< Jul04 0:00 [kworker/0:0H-events_highpri] root 10 0.0 0.0 0 0 ? I Jul04 0:00 [kworker/u16:0-events_unbound] root 11 0.0 0.0 0 0 ? I< Jul04 0:00 [kworker/R-mm_pe] root 12 0.0 0.0 0 0 ? I Jul04 0:00 [kworker/u16:1-netns] root 13 0.0 0.0 0 0 ? I Jul04 0:00 [rcu_tasks_kthre] root 14 0.0 0.0 0 0 ? I Jul04 0:00 [rcu_tasks_rude_] root 15 0.0 0.0 0 0 ? I Jul04 0:00 [rcu_tasks_trace] root 16 0.0 0.0 0 0 ? S Jul04 0:11 [ksoftirqd/0] systemd(1)─┬─NetworkManager(728)─┬─dhclient(799) │ ├─dhclient(1095) │ ├─{NetworkManager}(729) │ └─{NetworkManager}(731) ├─agetty(1117) ├─agetty(1640) ├─auditd(602)───{auditd}(603) ├─chronyd(669) ├─crond(947) ├─dbus-broker-lau(656)───dbus-broker(657) ├─firewalld(661)───{firewalld}(785) ├─httpd(743)─┬─httpd(694623) │ ├─httpd(694624) │ ├─httpd(694625) │ ├─httpd(694626) │ ├─httpd(694628) │ ├─httpd(694629) │ ├─httpd(694630) │ ├─httpd(694631) │ ├─httpd(694633) │ ├─httpd(694634) │ ├─httpd(694635) │ ├─httpd(694636) │ ├─httpd(694637) │ ├─httpd(694638) │ ├─httpd(694639) │ ├─httpd(694641) │ ├─httpd(694642) │ ├─httpd(694643) │ ├─httpd(694644) │ ├─httpd(694645) │ ├─httpd(694647) │ ├─httpd(694648) │ ├─httpd(694649) │ ├─httpd(694650) │ ├─httpd(694651) │ ├─httpd(694653) │ ├─httpd(694654) │ ├─httpd(694655) │ ├─httpd(694656) │ └─httpd(694658) ├─irqbalance(662)───{irqbalance}(666) ├─mysqld(1147)─┬─{mysqld}(1157) │ ├─{mysqld}(1158) │ ├─{mysqld}(1159) │ ├─{mysqld}(1160) │ ├─{mysqld}(1161) │ ├─{mysqld}(1162) │ ├─{mysqld}(1163) │ ├─{mysqld}(1164) │ ├─{mysqld}(1165) │ ├─{mysqld}(1166) │ ├─{mysqld}(1167) │ ├─{mysqld}(1168) │ ├─{mysqld}(1169) │ ├─{mysqld}(1170) │ ├─{mysqld}(1171) │ ├─{mysqld}(1172) │ ├─{mysqld}(1173) │ ├─{mysqld}(1174) │ ├─{mysqld}(1175) │ ├─{mysqld}(1176) │ ├─{mysqld}(1177) │ ├─{mysqld}(1178) │ ├─{mysqld}(1179) │ ├─{mysqld}(1180) │ ├─{mysqld}(1181) │ ├─{mysqld}(1182) │ ├─{mysqld}(1183) │ ├─{mysqld}(1184) │ ├─{mysqld}(1189) │ ├─{mysqld}(1190) │ ├─{mysqld}(1191) │ ├─{mysqld}(1192) │ ├─{mysqld}(1193) │ ├─{mysqld}(1194) │ ├─{mysqld}(1196) │ ├─{mysqld}(1197) │ ├─{mysqld}(1198) │ ├─{mysqld}(1204) │ ├─{mysqld}(1205) │ ├─{mysqld}(1206) │ ├─{mysqld}(1207) │ ├─{mysqld}(1208) │ ├─{mysqld}(1209) │ ├─{mysqld}(1210) │ ├─{mysqld}(1211) │ ├─{mysqld}(1212) │ ├─{mysqld}(1214) │ ├─{mysqld}(1758) │ ├─{mysqld}(2381) │ ├─{mysqld}(2988) │ ├─{mysqld}(2989) │ ├─{mysqld}(709081) │ ├─{mysqld}(709082) │ ├─{mysqld}(709083) │ ├─{mysqld}(709084) │ ├─{mysqld}(709085) │ ├─{mysqld}(709086) │ └─{mysqld}(709087) ├─nginx(692842)─┬─nginx(694580) │ ├─nginx(694581) │ ├─nginx(694582) │ ├─nginx(694583) │ ├─nginx(694584) │ ├─nginx(694585) │ ├─nginx(694586) │ └─nginx(694587) ├─polkitd(727)─┬─{polkitd}(734) │ ├─{polkitd}(735) │ ├─{polkitd}(737) │ ├─{polkitd}(738) │ ├─{polkitd}(739) │ ├─{polkitd}(740) │ └─{polkitd}(762) ├─qemu-ga(663)───{qemu-ga}(667) ├─rsyslogd(934)─┬─{rsyslogd}(962) │ └─{rsyslogd}(963) ├─sshd(935)─┬─sshd(814001)───sshd(814016)───bash(814017)───pstree(814562) │ └─sshd(814556)───sshd(814557) ├─systemd(814006)───(sd-pam)(814008) ├─systemd-hostnam(814021) ├─systemd-journal(543) ├─systemd-logind(664) ├─systemd-udevd(562) └─zabbix_agentd(745)─┬─zabbix_agentd(763) ├─zabbix_agentd(764) ├─zabbix_agentd(765) └─zabbix_agentd(766) Краткий вердикт: на основе этого вывода всё выглядит штатно и безопасно. У вас работает стандартный набор сервисов для веб-сервера, и нет никаких очевидных признаков вредоносной активности.Детальный анализ вывода ps aux
Вывод отсортирован по нагрузке на процессор, и это очень показательно.
-mysqld (PID 1147) - 3.4% CPU:
<li>Это процесс сервера баз данных MySQL/MariaDB.
- На веб-сервере, особенно с такой CMS как Битрикс, база данных является одним из основных потребителей ресурсов. Нагрузка в 3.4% является абсолютно нормальной и даже невысокой. Это говорит о том, что база данных работает в штатном режиме.sshd, systemd --user (PID 814001, 814006):
<li>Это процессы, связанные с вашим текущим SSH-подключением к серверу. Они создаются, когда вы логинитесь. Совершенно нормально.kthreadd, kworker, rcu_tasks... (все с PID < 100):
<li>Это ядерные процессы (kernel threads). Они являются частью ядра Linux и отвечают за внутренние задачи операционной системы: управление прерываниями, таймерами, вводом-выводом и т.д.
- Их наличие абсолютно нормально и необходимо для работы системы. На них не стоит обращать внимания при поиске вредоносного ПО. Вывод по `ps`: Ни одного процесса с подозрительным именем или аномальным поведением в этом списке нет.Детальный анализ вывода pstree
Эта утилита очень полезна, так как показывает иерархию процессов (кто кого запустил).
- `systemd(1)`: Это главный процесс в системе (PID 1), который запускает всё остальное. Это правильно для современных дистрибутивов Linux (CentOS/RHEL, Debian, Ubuntu).
- От него запускаются все системные сервисы:
<li>`NetworkManager`: Управляет сетью.
- `auditd`: Система аудита безопасности.
- `chronyd`: Синхронизация времени.
- `crond`: Планировщик задач (cron).
- `firewalld`: Межсетевой экран.
- `httpd`: Веб-сервер Apache. Видно, что один главный процесс запустил множество дочерних для обработки запросов — это его стандартная модель работы (pre-fork).
- `mysqld`: Сервер баз данных. Видно, что у него много потоков (threads) — это тоже стандартная модель работы. Вывод по `pstree`: Дерево процессов не показывает никаких аномалий: нет «осиротевших» процессов или процессов, запущенных из необычных мест. Структура полностью соответствует стандартной конфигурации веб-сервера.Итоговый вердикт и что проверить дальше
Ваши опасения по поводу запущенных процессов, судя по этим данным, не подтверждаются. Система выглядит «здоровой» и работает в штатном режиме.
Для полного спокойствия, как и обсуждали ранее, осталось проверить:
-
Задания в `crontab` (особенно системные и для `root`):
bash Скопировать
Закрыть блокsudo crontab -l
sudo cat /etc/crontab
sudo ls /etc/cron.*/-
SSH-ключи:
bash Скопировать
Закрыть блокcat /home/bitrix/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys Убедитесь, что там только те ключи, которые вы добавляли лично.
-
Открытые порты:
bash Скопировать
Закрыть блокsudo ss -tulnp Проверьте, нет ли неизвестных вам сервисов, слушающих сеть.
Итог: Всё в порядке. Ничего подозрительного нет.
Все открытые порты обслуживаются известными и ожидаемыми системными службами. Давайте разберем каждую строчку.
Анализ открытых портов
Стандартные системные службы:
Порт 68 (UDP) - dhclient: Это DHCP-клиент, который получает IP-адрес для сервера от роутера или провайдера. Норма.
Порт 323 (UDP) - chronyd: Это служба синхронизации времени (NTP). Она слушает только на 127.0.0.1 (внутренний адрес), что безопасно. Норма.
Порт 546 (UDP) - dhclient: Это DHCP-клиент для протокола IPv6. Норма.
Порт 22 (TCP) - sshd: Это SSH-сервер, через который вы подключаетесь для управления сервером. Норма.
Службы веб-сервера (Nginx для Битрикс):
Порт 80 (TCP) - nginx: Стандартный порт для HTTP-трафика (ваш сайт). Норма.
Порт 443 (TCP) - nginx: Стандартный порт для HTTPS-трафика (ваш сайт по защищенному протоколу). Норма.
Порт 8070 (TCP) - nginx: Этот порт в окружении Битрикс часто используется для мобильных приложений (BitrixMobile). Если у вас используется мобильное приложение, то это Норма.
Порт 8893 (TCP) - nginx: Этот порт в окружении Битрикс используется для "Push and Pull server" (модуль мгновенных сообщений, уведомлений, онлайн-чатов) по протоколу HTTP. Норма.
Порт 8894 (TCP) - nginx: То же, что и 8893, но для работы по HTTPS. Норма.
Служба мониторинга:
Порт 10050 (TCP) - zabbix_agentd: На сервере установлен агент Zabbix. Это очень популярная и легитимная система мониторинга. Она собирает метрики (нагрузка на CPU, память, место на диске) и отправляет их на сервер Zabbix. Если вы или ваш администратор настраивали мониторинг, то это Норма. Если вы не знаете, что это, стоит уточнить у того, кто настраивал сервер, но сам по себе этот процесс не является вредоносным.
Общий вывод
Конфигурация сетевых служб полностью соответствует стандартной установке "Битрикс: Веб-окружение" с настроенным мониторингом через Zabbix. Нет никаких неизвестных процессов, слушающих сеть, или портов, которые бы указывали на вредоносную активность.
Вы можете быть спокойны, с этой стороны сервер выглядит "чистым".Анализ портов
1. Порт 8888 (httpd/Apache)
LISTEN 0 511 127.0.0.1:8888 0.0.0.0:* users:(("httpd",pid=...), ...) - Что это? Это ваш веб-сервер Apache (`httpd`).
- Адрес `127.0.0.1`: Это `localhost`. Означает, что Apache слушает соединения только с этого же сервера. Он недоступен извне.
- Зачем это нужно? Это классическая и правильная настройка связки Nginx + Apache. Nginx (который слушает внешние порты 80 и 443) принимает запросы из интернета и перенаправляет их на Apache по этому внутреннему порту 8888.
- Вердикт: Норма. Безопасно.2. Порт 8895 (Nginx)
LISTEN 0 511 127.0.0.1:8895 0.0.0.0:* users:(("nginx",pid=...), ...) - Что это? Это ваш веб-сервер Nginx.
- Адрес `127.0.0.1`: Снова `localhost`, то есть порт только для внутреннего использования.
- Зачем это нужно? В окружении Битрикс это, скорее всего, порт, который Nginx использует для служебных целей, например, для модуля `ngx_http_stub_status_module` (чтобы собирать статистику о работе Nginx) или для внутренней коммуникации с сервисом "Push and Pull".
- Вердикт: Норма. Безопасно.3. Порт 22 ([::]:22) (sshd)
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=935,fd=4)) - Что это? Это SSH-сервер.
- Адрес `[::]`: Это аналог `0.0.0.0` для протокола IPv6. Означает, что SSH-сервер принимает подключения по всем доступным IPv6-адресам сервера. В прошлом выводе мы видели то же самое для IPv4.
- Вердикт: Норма.4. Порты 3306 и 33060 (mysqld) - ВАЖНО
LISTEN 0 55 *:3306 *:* users:(("mysqld",pid=1147,fd=36))
LISTEN 0 70 *:33060 *:* users:(("mysqld",pid=1147,fd=34)) Вот это самый интересный и важный момент во всем анализе.
- Что это? Это ваш сервер баз данных MySQL/MariaDB (`mysqld`).
<li>Порт 3306: Стандартный порт для подключения к MySQL по классическому протоколу.
- Порт 33060: Стандартный порт для подключения по новому X Protocol (используется MySQL Shell и новыми коннекторами).Почему это может быть проблемой?
Выставление базы данных "наружу" — это потенциальный риск безопасности. Это позволяет злоумышленникам пытаться:
- Подобрать пароль к вашей базе данных.
- Использовать известные уязвимости в вашей версии MySQL для получения доступа.Что делать?
-
Задайте себе вопрос: Вам действительно нужен доступ к базе данных с другого компьютера (не с этого же сервера)?
<li>Если нет (сайт и база находятся на одном сервере и общаются локально), то это настоятельно рекомендуется исправить.
- Если да (например, вы подключаетесь к базе с рабочего компьютера или из другого сервиса), то вы должны быть уверены, что:
<li>На сервере работает и правильно настроен файрвол (`firewalld`), который разрешает доступ к этим портам только с доверенных IP-адресов.
- У всех пользователей базы данных установлены очень надежные, сложные пароли. Как исправить (если внешний доступ не нужен): Найдите конфигурационный файл MySQL (обычно `/etc/my.cnf` или в `/etc/my.cnf.d/`) и добавьте/измените в секции `[mysqld]` параметр:
ini Скопировать
Закрыть блокbind-address = 127.0.0.1 После этого перезапустите службу MySQL: `sudo systemctl restart mysqld` (или `mariadb`). После этого база данных будет доступна только локально, что гораздо безопаснее.Итоговый вывод
Ваш сервер настроен так, что веб-компоненты (Nginx, Apache) общаются между собой безопасно по внутренним портам. Однако база данных открыта для подключений извне.
Это не признак взлома, а особенность конфигурации. Но это создаёт вектор для потенциальных атак. Рекомендую проверить необходимость такого доступа и, если он не нужен, ограничить доступ к базе данных только локальными соединениями.Анализ SSH-ключей
-cat /home/bitrix/.ssh/authorized_keys
<li>Результат: Вывод пустой (вы показали это точкой, что, вероятно, означает отсутствие вывода от команды).
- Что это значит: У пользователя `bitrix` нет добавленных SSH-ключей для беспарольного входа. Это хорошо с точки зрения безопасности, так как для входа под этим пользователем (если он разрешен) потребуется пароль.sudo cat /root/.ssh/authorized_keys
<li>Результат:ssh-rsa AAAAB3NzaC1yc2E...= ANSIBLE_KEY_pechco9 - Что это значит: Это публичный SSH-ключ, который позволяет заходить на сервер под пользователем `root` без пароля тому, у кого есть соответствующий приватный ключ.
- Анализ комментария `ANSIBLE_KEY_pechco9`: Это самая важная часть.
<li>`ANSIBLE`: Это название очень популярной системы управления конфигурациями. Системные администраторы используют Ansible для автоматической настройки и развертывания серверов. Это стандартная практика — Ansible "заходит" на сервер по SSH и выполняет нужные команды.
- `pechco9`: Скорее всего, это имя пользователя или хоста, с которого производилась настройка сервера через Ansible.Вывод по ключам
Это, с огромной долей вероятности, легитимный ключ, оставленный системой автоматизации при первоначальной настройке сервера. Сам по себе он не является признаком взлома, а наоборот, указывает на профессиональный подход к администрированию.
Ключевой вопрос для вас: кто такой `pechco9` и кто настраивал сервер с помощью Ansible?
- Сценарий 1 (Безопасный): Если вы, ваш системный администратор или компания-подрядчик настраивали сервер с помощью Ansible, и `pechco9` — это имя вашего пользователя или проекта, то всё в порядке. Этот ключ необходим для управления сервером, и вы знаете его происхождение.
- Сценарий 2 (Потенциально опасный): Если вы абсолютно не знаете, кто такой `pechco9`, и никто не должен был настраивать сервер автоматически, то этот ключ следует считать недоверенным. Он дает полный доступ к серверу неизвестному лицу. В этом случае его нужно немедленно удалить из файла `/root/.ssh/authorized_keys`.Итоговое заключение по всей проверке
Давайте соберем все результаты воедино:
- Процессы (`ps`): Все запущенные процессы являются штатными для веб-сервера на базе Битрикс (Nginx, Apache, MySQL, системные службы). Ничего подозрительного.
- Сетевые порты (`ss -tulnp`):
<li>Веб-сервер и системные службы настроены правильно и безопасно (используют внутренние порты для коммуникации).
- Единственный реальный риск, который мы обнаружили, — это порты базы данных (3306 и 33060) открыты для всего интернета. Это не является признаком взлома, но создает вектор для атак. Финальная рекомендация:
- Первоочередная задача: Закрыть доступ к базе данных извне, если он не требуется. Для этого в конфигурационном файле MySQL (`/etc/my.cnf`) нужно установить `bind-address = 127.0.0.1`.
- Подтвердить легитимность ключа: Уточните у тех, кто настраивал сервер, про ключ `ANSIBLE_KEY_pechco9`. Если его происхождение подтвердится — оставьте его. Если нет — удалите.
В целом, сервер не выглядит взломанным. Обнаружена одна небезопасная конфигурация (база данных), которую стоит исправить для повышения общей защищенности системы.🔍 ПРОВЕРКА НА МАЙНЕРЫ И ВРЕДОНОСНОЕ ПО
🛡️ КОМПЛЕКСНАЯ ПРОВЕРКА БЕЗОПАСНОСТИ:
1. Проверяем подозрительные процессы:
# Процессы с высокой нагрузкой CPU
top -bn1 | head -20
# Подозрительные процессы
ps aux | grep -E "xmr|mine|crypto|xmrig|stratum|pool|nicehash|dero|sumo|ocean" | grep -v grep
# Скрытые процессы
ps aux | awk '{if($3>50.0) print $0}'
# Процессы от необычных пользователей
ps aux | grep -vE "^(root|bitrix|mysql|nginx|apache|systemd)" | grep -v "^USER"
2. Проверяем сетевые соединения:
# Подозрительные внешние соединения
netstat -tupn | grep -E "ESTABLISHED|LISTEN" | grep -vE "127.0.0.1|::1" | grep -vE ":80|:443|:22|:3306|:8888"
# Соединения на майнинг пулы
netstat -tupn | grep -E ":3333|:4444|:5555|:7777|:8333|:9999|:14444|:45700"
# Проверка DNS запросов к майнинг пулам
grep -E "pool|mine|xmr|monero|crypto" /var/log/messages 2>/dev/null
3. Проверяем cron задания:
# Cron для всех пользователей
for user in $(cut -f1 -d: /etc/passwd); do
echo "=== Cron for $user ==="
crontab -l -u $user 2>/dev/null
done
# Системные cron
ls -la /etc/cron*/ | grep -v "^d"
cat /etc/crontab
# Подозрительные задания
grep -r "curl\|wget\|bash\|sh\|nc\|/dev/tcp" /etc/cron* 2>/dev/null
4. Проверяем автозагрузку:
# Systemd сервисы
systemctl list-units --type=service --state=running | grep -vE "ssh|nginx|httpd|mysql|php|system"
# Подозрительные сервисы
ls -la /etc/systemd/system/ | grep -v "^d" | tail -20
ls -la /usr/lib/systemd/system/ | grep -E "xmr|mine|crypto" 2>/dev/null
# rc.local
cat /etc/rc.local 2>/dev/null
cat /etc/rc.d/rc.local 2>/dev/null
5. Проверяем временные директории:
# Исполняемые файлы в /tmp
find /tmp -type f -executable 2>/dev/null | head -20
find /var/tmp -type f -executable 2>/dev/null | head -20
find /dev/shm -type f 2>/dev/null
# Скрытые файлы
find /tmp -name ".*" -type f 2>/dev/null
find /var/tmp -name ".*" -type f 2>/dev/null
6. Проверяем изменённые системные файлы:
# Недавно изменённые файлы в системных директориях
find /usr/bin /usr/sbin -type f -mtime -7 2>/dev/null | head -20
find /etc -type f -mtime -7 2>/dev/null | grep -vE "log|cache"
# Проверка passwd и shadow
ls -la /etc/passwd /etc/shadow
grep -E ":0:" /etc/passwd | grep -v "^root"
7. Проверяем веб-директории на вредоносный код:
# Поиск подозрительного PHP кода
find /home/bitrix/www -name "*.php" -type f -exec grep -l "eval\|base64_decode\|shell_exec\|system\|exec\|passthru" {} \; 2>/dev/null | head -20
# Недавно изменённые PHP файлы
find /home/bitrix/www -name "*.php" -type f -mtime -7 2>/dev/null | head -20
# Проверка прав на файлы
find /home/bitrix/www -type f -perm 777 2>/dev/null | head -10
8. Проверяем логи на взлом:
# Попытки входа SSH
grep "Failed password" /var/log/secure | tail -10
grep "Accepted" /var/log/secure | tail -10
# Подозрительная активность в веб-логах
grep -E "eval|base64|shell|cmd|exec" /var/log/nginx/access.log | tail -10
grep -E "POST.*\.txt|POST.*\.jpg" /var/log/nginx/access.log | tail -10
9. Быстрая проверка ресурсов:
# Использование CPU и памяти
echo "=== ИСПОЛЬЗОВАНИЕ РЕСУРСОВ ==="
echo "CPU: $(top -bn1 | grep "Cpu(s)" | awk '{print $2"%"}')"
echo "RAM: $(free -m | awk '/^Mem:/ {printf "%.1f%%\n", $3/$2*100}')"
echo "Загрузка: $(uptime | awk -F'load average:' '{print $2}')"
echo
echo "=== ДИСК ==="
df -h | grep -E "^/dev"
echo
echo "=== СЕТЬ ==="
ss -s | head -5
10. Установка утилит для проверки (опционально):
# Установка rkhunter для проверки на руткиты
yum install -y rkhunter
rkhunter --update
rkhunter --check --skip-keypress
# Установка ClamAV для проверки на вирусы
yum install -y clamav clamav-update
freshclam
clamscan -r /home/bitrix/www --max-filesize=25M --max-scansize=50M | grep FOUND
📊 СКРИПТ БЫСТРОЙ ПРОВЕРКИ:
cat > /root/security_check.sh << 'EOF'
#!/bin/bash
echo "=== ПРОВЕРКА БЕЗОПАСНОСТИ СИСТЕМЫ ==="
echo
echo "1. Подозрительные процессы:"
ps aux | grep -E "xmr|mine|crypto" | grep -v grep
echo
echo "2. Нагрузка CPU > 50%:"
ps aux | awk '{if($3>50.0) print $2,$3,$11}'
echo
echo "3. Подозрительные соединения:"
netstat -tupn | grep ESTABLISHED | grep -vE "127.0.0.1|:22|:80|:443|:3306"
echo
echo "4. Cron задания с curl/wget:"
grep -r "curl\|wget" /etc/cron* 2>/dev/null | grep -v "#"
echo
echo "5. Исполняемые файлы в /tmp:"
find /tmp /var/tmp -type f -executable 2>/dev/null | wc -l
echo
echo "6. Подозрительный PHP код:"
find /home/bitrix/www -name "*.php" -type f -exec grep -l "eval.*base64_decode" {} \; 2>/dev/null | wc -l
EOF
chmod +x /root/security_check.sh
/root/security_check.sh