Я только что заметил странные каталоги, хранящиеся на обоих в /tmp в двух моих ящиках CentOS.
На одной машине временный каталог называется /tmp/www4-679109 в то время как на моей второй машине временный каталог /tmp/sos_e6X9_3.
Оба этих подозрительных каталога содержат четыре подкаталога: etc proc sys var.
Папка etc в этом подозрительном дереве каталогов содержит идентичную копию моего главного файла конфигурации sendmail submit.cf. /tmp/sos_e6X9_3/etc/mail/submit.cf и /etc/mail/submit.cf. Это заставляет меня думать, что каким-то образом sendmail использовался для ретрансляции почты. Хотя я не могу проверить, были ли файлы почтовых журналов безрезультатными, но это так.
Также этот подозрительный странный каталог содержит в себе какие-то файлы журнала аудита. (/tmp/sos_e6X9_3/var/log/audit/audit.log.1)
Фрагмент содержимого файла журнала:
type=LOGIN msg=audit(1293719401.416:2772543): login pid=6662 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=557197
type=LOGIN msg=audit(1293719401.417:2772544): login pid=6660 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=557198
type=LOGIN msg=audit(1293719401.418:2772545): login pid=6649 uid=0 old auid=4294967295 new auid=599 old ses=4294967295 new ses=557199
type=LOGIN msg=audit(1293719401.420:2772546): login pid=6665 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=557200
type=USER_ACCT msg=audit(1293719401.423:2772547): user pid=6668 uid=0 auid=4294967295 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='PAM: accounting acct="root" : exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)'
type=USER_START msg=audit(1293719401.424:2772548): user pid=6653 uid=0 auid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='PAM: session open acct="root" : exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)'
Что больше всего беспокоит меня с этими подозрительными файлами и каталогами на моих ящиках CentOS, так это то, что, похоже, это каталог, похожий на procfs в /tmp/sos_e6X9_3/proc. Единственная разница с /tmp/sos_e6X9_3/proc и /proc это в /tmp/sos_e6X9_3/proc нет видимой информации о процессе.
Я поддерживал обе машины CentOS в актуальном состоянии и не вносил никаких изменений в sendmail, которые каким-либо образом сделали бы его уязвимым (если только sendmail не был уязвим сразу после установки).
У кого-нибудь есть идеи / отзывы о том, почему были созданы эти подозрительные временные файлы и папки?
ОБНОВЛЕНИЕ: похоже, что подозрительные файлы были созданы утилитой sosreport, когда мы работали со службой поддержки Red Hat над другой проблемой. Я проверил журнал, и отметки времени совпадают с отметками времени подозрительных файлов и каталогов. Спасибо за вашу поддержку и отзывы. Вы молодцы!
Я бы определенно сразу запустил chkrootkit и rkhunter. Если вы можете загрузить двоичный файл для netstat, lsof, ls, less и ps и запустить их напрямую, тогда вы лучше поймете, что делают коробки.
Обратите внимание, что этим загруженным чистым двоичным файлам следует доверять только для этого сеанса входа в систему. Загружайте их каждый раз, когда они вам нужны. Я видел, как файлы перезаписывались при каждом входе в систему после компрометации.
Если вы можете использовать брандмауэр для всего, кроме вашего админского IP-адреса для SSH на несколько минут, тем лучше, пока вы запустите эти тесты.
Во время тщательных поисков машины ищите НИЧЕГО разное. От форматированного цветного вывода «top» до скорости загрузки «w».
Каталог sos, который вы нашли в / tmp, создается при выполнении команды sosreport. Это служебная программа Red Hat, которая собирает системную информацию, которая полезна для службы поддержки Red Hat при устранении неполадок в вашей системе. Насколько я знаю, это бесполезно в CentOS, но поскольку CentOS основан на RHEL, поэтому он там (предположение).
Изменить: я скучал по твоему смелый напечатайте, что вы узнали, что это связано с sosreport.
Независимо от того, действительно ли вы найдете руткит, я бы:
Да, это немного параноик, но обычно это более быстрый путь к исправлению, чем попытки изучить проблему и проявить смекалку.
Похоже из OP, что это почтовый сервер. Если это так, у вас есть дополнительная проблема в том, что ящик может отправлять зараженную почту. Я не освобожу очередь своей почты до тех пор, пока не буду абсолютно уверен, что ее не переписывают по пути.