Поэтому я установил Linux-сервер и забыл отключить пароль ssh с открытым текстом, установить denyhosts или включить какую-либо политику паролей. Обычно я запрещаю хосты, и это хорошо работает. В результате пропуска этого важного шага (да, я должен автоматизировать процесс) был взломан пользователь со слабым паролем. Теперь, при условии, что общие разрешения хороши, что я могу сделать, чтобы выяснить, что они сделали, и удалить это?
Кстати, я по натуре программист, а не системный администратор, так что будьте добры!
Вы никогда не можете быть полностью уверены в том, что они сделали с учетной записью пользователя. Но лучше всего начать с файлов истории. * В домашнем каталоге.
Мой совет: скопировать заведомо хорошие / важные данные, а затем удалите все остальное. Злоумышленник мог оставить какие-то неприятные сюрпризы в файлах конфигурации, .bashrc и т. Д.
Вы также должны проверить, есть ли в системе какие-либо файлы, принадлежащие пользователю, и найти запущенные процессы:
# find / -user USERNAME
# ps -a -u USERNAME
На будущее я бы посоветовал включить учет процессов. Затем вы можете проверить ранее запущенные команды с помощью lastcomm.
Если подозреваемая скомпрометированная учетная запись непривилегирована, есть лишь несколько мест, где злоумышленник может скрыть постоянное вредоносное ПО. Очистите эти места как следует, и нет необходимости полностью продувать счет.
Она инициализирует файлы: .bashrc
, .bash_profile
, .profile
, .bash_login
и т. д. Для оболочек, отличных от bash, проверьте соответствующую страницу руководства.
Если система использует systemD, то есть другой вектор через экземпляр systemd --user. Пользовательские единицы systemD входят в ~/.config
и ~/.local
[1].
Cron вакансии. Зависит от вашего стиля cron, но обычно где-то в /var/lib/...
Файл конфигурации рабочего стола. Обычно в ~/.config
и ~/.local
. На всякий случай удалите эти каталоги.
Конфигурация pam_env в ~/.pam_environment
.
Также обратите внимание, что выполнять очистку в работающей системе НЕ безопасно, потому что systemD позволяет задерживать пользователей через вход в систему, что означает, что пользовательские модули могут запускаться при каждой загрузке. К счастью, нужен установленный polkit, чтобы злоумышленник мог задержать взломанного пользователя ... если у вас есть polkit, вы попали в мир боли :)
Следовательно, лучше всего выполнить очистку из initramfs, передав init = / bin / bash в командную строку ядра.
Если у вас есть резервная копия, вы можете сравнить ее с текущей файловой системой, чтобы увидеть, что изменилось. Обратите особое внимание на каталоги, которые обычно находятся в пути, например / bin, / usr / bin, / usr / local / bin, / sbin, / usr / sbin, / usr / local / sbin, / opt / bin, и т.п.
Также ищите руткит: Список средств обнаружения и удаления руткитов Windows
Но вы не можете знать, что вы нашли все, что они сделали. Лучше вернуться к заведомо исправному состоянию (например, к последней резервной копии) и принести с собой тщательно проверенные данные, которые изменились с тех пор. Еще лучше было бы стереть систему и установить IDS перед ее подключением к сети.
Если вы не используете помощник, tripwire или что-то подобное, у вас не так много других вариантов.
Вы должны проверить историю пользователей и историю корней.
Поищите в / tmp подозрительные файлы (исходный код, исполняемые файлы, файлы, принадлежащие этому пользователю).
Использовать http://www.chkrootkit.org/ и / или http://rkhunter.sourceforge.net чтобы проверить систему.
pstree / top / ps aux для проверки запущенных процессов.
Посмотрите лог-файлы в / var / log за конкретное время взлома, если оно у вас есть.
Очистите учетную запись пользователя, переместив важные данные, если таковые имеются. Проверьте историю команд пользователей, чтобы узнать, был ли запущен какой-либо сценарий или какая-либо ненужная команда. Удалите пользователя из системы и удалите домашний каталог. Проверьте, установлены ли какие-либо cronjobs. Подробно проверьте все процессы, чтобы увидеть, были ли какие-либо фоновые процессы, установленные взломанной учетной записью.
Надеюсь, поможет.