Вопрос или проблема
Сначала я заметил, что есть процесс с именем kswapd0, использующий 100% 4 из 8 ядер ЦП. Я убивал его несколько раз, а затем добавил в /etc/sysctl.conf строку
vm.swappiness=10
После этого появился другой процесс с именем kauditd0, снова использующий 100% 4 ядер.
Я стал искать в файле /var/log/messages записи о ssh-входах. Я не слишком боялся, потому что вход по паролю по ssh был отключен и был возможен только с помощью закрытых/открытых ключей, а все мои ключи имеют надежные пароли (длиной от 20 до 25 символов и не содержащие стандартных слов или слогов), но невероятно, я нашел вход по публичному ключу от пользователя test (которого я использовал 2 года назад для – ну – тестов и с тех пор больше не использовал) из TOR-релея, и сотни попыток входа по публичным ключам для пользователя root (без успеха).
В папке /home/test я нашел подпапку .configrc7 с множеством оболочечных скриптов и исполняемым ELF-файлом с именем kswapd00. Кроме этого, в файле /home/test/.ssh/authorized_keys был единственный публичный rsa-ключ с комментарием “mdrfckr” в конце, плюс файл cron /var/spool/cron/crontabs/test со следующим содержанием:
# НЕ РЕДАКТИРУЙТЕ ЭТОТ ФАЙЛ - редактируйте мастер и переустановите.
# (cron.d установлен 4 нояб. 2024 года, 10:28:44)
# (Версия Cron -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
*/30 * * * * /tmp/.kswapd00 || /home/test/.configrc7/a/kswapd00 > /dev/null 2>&1
5 6 */2 * 0 /home/test/.configrc7/a/upd>/dev/null 2>&1
@перезагрузка /home/test/.configrc7/a/upd>/dev/null 2>&1
5 8 * * 0 /home/test/.configrc7/b/sync>/dev/null 2>&1
@перезагрузка /home/test/.configrc7/b/sync>/dev/null 2>&1
0 0 */3 * * /var/tmp/.X22d-unixX/.rsync/c/aptitude>/dev/null 2>&1
Все файлы в /var/tmp и /tmp существуют с правами владельца test:test.
Прежде чем я (в качестве своего стандартного пользователя, давайте назовем его “std”) пробовал несколько тем для firefox, чтобы сделать его немного красивее, и во время этого, вдруг firefox стал непригодным к использованию, т.е. казалось, что какие-то совершенно странные стили css захватили. Это произошло примерно в то время, когда началось чрезмерное использование ЦП, так что, возможно, это был момент, когда они могли получить доступ к моему компьютеру. Но это было как “std”, так почему все остальные действия были выполнены от имени пользователя “test”? Это было для сокрытия действий?
Может быть, есть кто-то, кто знает об этом и может мне помочь?
Я понимаю, что это не тривиально, но все, что я хочу, это получить несколько подсказок о том, как кто-то мог получить доступ к моему компьютеру, хотя вход по паролю ssh был запрещен, и никаких других портов, кроме ssh, не было открыто. Я и с электронной почтой крайне осторожен.
Я могу предоставить подозрительные файлы или папки, если это необходимо.
Любая информация будет оценена, спасибо.
.
Ответ или решение
Крипто-майнеры могут получить доступ к вашему компьютеру различными способами, даже если вы предприняли меры безопасности, такие как отключение входа по паролю по SSH. В вашем случае имеет место несколько факторов, которые могли способствовать этому инциденту. Рассмотрим детали и возможные уязвимости:
1. Уязвимости старых учетных записей
Если вы использовали учетную запись test для тестирования и не удалили ее после завершения, то данная учетная запись остаётся уязвимой, особенно если она не имеет актуальных механизмов безопасности. Убедитесь, что все неиспользуемые учетные записи удалены или заблокированы.
2. Испорченное программное обеспечение
Ваши наблюдения о странных процессах, таких как kswapd0 и kauditd0, говорят о том, что на вашем устройстве могут быть запущены вредоносные программы. Крипто-майнеры часто используют скрытые процессы для майнинга, что и может объяснять высокую загрузку процессора. Вредоносные программы могут быть установлены путём:
- Заражённых приложений: Установка расширений или тем в браузере, которые не были проверены, может привести к компрометации вашего устройства.
- Фишинг: Переход на заражённые сайты или открывание небезопасных вложений в электронных письмах может привести к загрузке вредоносного ПО.
3. Уязвимости SSH-ключей
Хотя вы указали, что вход по паролю отключён, учетная запись test была доступна через публичный ключ. Важно убедиться в безопасности ваших SSH-ключей:
- Контроль доступа: Проверьте файл
~/.ssh/authorized_keysна наличие подозрительных записей (что вы уже сделали). Убедитесь, что нет легкодоступных ключей. - Сложность паролей: Каждый ключ должен иметь надежную фразу-пароль. Если фраза-пароль скомпрометирована, злоумышленник может использовать ключ для доступа.
4. Краткосрочные меры
Чтобы уменьшить шансы дальнейших атак, выполните следующие действия:
- Удалите небезопасные учетные записи: Удалите или деактивируйте учетную запись
test, если она больше не используется. - Проверка на наличие вредоносного ПО: Запустите антивирусные сканирования и утилиты для выявления вредоносных процессов и файлов.
- Усиление защиты SSH: Измените настройки SSH, чтобы только определённые IP-адреса могли подключаться.
5. Долгосрочные рекомендации
Создайте целостную стратегию цифровой безопасности:
- Регулярные обновления: Убедитесь, что ваше программное обеспечение и операционная система обновлены до актуальных версий, так как обновления часто содержат исправления безопасности.
- Мониторинг: Настройте системы мониторинга для отслеживания подозрительной активности и аномалий в производительности системы.
- Образование пользователей: Обучите себя и своих коллег по безопасности основам защиты данных и программного обеспечения, включая идентификацию фишинга и безопасное использование расширений.
Заключение
Получение доступа к вашему компьютеру злоумышленниками может произойти через различные уязвимости. Ключевые действия, которые вы можете предпринять, включают защиту учетных записей, анализ подозрительных процессов и установление регулярного мониторинга системы. Постоянный контроль над безопасностью вашего устройства позволит значительно снизить риск повторного доступа.