Параноя... Обнаружил у себя на жестком диске логи своей консоли

Если какое-то приложение записывает в файл, затем файл стирает, затем создаёт новый с тем же именем, то будет ли найденный текст соответствовать новому файлу? А старого нету, вместо него новый, с тем же путём, тем же именем, но в других секторах.

Ну ктож под рутом то сидит..

Если какое-то приложение записывает в файл, затем файл стирает, затем создаёт новый с тем же именем, то будет ли найденный текст соответствовать новому файлу? А старого нету, вместо него новый, с тем же путём, тем же именем, но в других секторах.

Нет конечно. grep в привидённой мной форме ищет по сырому содержимому диска. Я вообще-то искал удалённый файл и внезапно обнаружил.

А debugfs с icheck должен определять файлы по номеру блока, и вроде у меня этот блок четыре килобайта. Определил подбором.

Дальше, find / -xdev -inum 111111 должен найти имена файлов. debugfs с ncheck тоже может.

Вот этот файл не находит

Ну ктож под рутом то сидит..

А как по-твоему грепать по жесткому диску без рута?

Swap?

Когда б ты знал какие страсти в .bash_history лежат

В оперативной памяти ваще соддом

Swap?

Я же говорю, root_fs

Когда б ты знал какие страсти в .bash_history лежат

Там только сами команды, а я нашел полный дамп терминала со всем выводом... у меня просыпается параноя...

Но логи то-вы ищите рутовские, не?

Но логи то-вы ищите рутовские, не?

Я и юзерские искал и рутовские, и те и другие находятся.

/var, /tmp, swapfile на той же ФС расположены?

swap в разделе, tmp и var да.

Возможно, ты копипастил содержимое терминала, и эти фрагменты — ошметки временных файлов текстового редактора? Что там у нас любит временные файлы плодить... vim?

в том и дело, что там по всей видимости есть даже вывод терминала во время самой этой команды, который я вроде не копировал...

Ладно, попробую что ли grep -r кусочка подозрительного лога по /var и /tmp

Может быть это иксы при выделении копируют или терминал Xfce... хм

Иксам во временные файлы писать незачем.

в том и дело, что там по всей видимости есть даже вывод терминала во время самой этой команды, который я вроде не копировал...

Попробуй с другим эмулятором терминала. И из чистой консоли.

я

Я бы первом делом посмотрел права на этот лог файл. Потом все процессы и лучше через htop, top, ps просто подменить. Короче думаю нужно понабирать всякую чушь от рута, посмотреть пишется ли оно в этот файл. И если пишется пробовать отследить. Ну, о том что минимум нужно посмотреть, кто последний и когда входил и rhunter/chkrootkit я промолчу.

Я бы первом делом посмотрел права на этот лог файл

В том и дело что я не могу этот файл поймать... логи сохраняются в незаполненные секторы... по крайней мере, debugfs не ловит.

Было бы имя файла, я бы его погуглил и понял.

Еще раз перечитал и понял. А если просто что-нибудь типо: «grep root@darkstar -R /» сделать, находится что-нибудь? Да gxneur/xneur(хотя если это не домашняя тачка, то Х'ы там в принципе наврядли есть) не стоит случаем if any?

Ну, о том что минимум нужно посмотреть, кто последний и когда входил и rhunter/chkrootkit я промолчу.

ну а о том что если взломщик получил рута, то никогда тебе не покажет себя в ластах и rhunter/chkrootkit его вряд ли поймают промолчу я.

я, когда параноя накрывает, делаю так:

качаю с офф сайта rpm и зависимости к нему. затем ставлю этот рпм из руками (т.е. распаковываю на другой машине и просто переношу файлы, окторые потом копирую).

затем проверяю где лежат исполняемые файлы.

потом все исполняемые файлы я проверяю с помощью (моего нового rpm) как то так find / -type f -perm -o=x -exec rpm -q --whatprovides {} \; | grep 'no packages found' - не должно быть исполняемого файла который никто не провайдит. если такой есть - его в отдельный noexec каталог.

далее проверяю подписи всех файлов с помощью того же rpm. если у конфига подпись битая, гляжу глазами. если у файла - однозначно переустановка пакета.

далее проверяю все конфиги (ssh, http, sudoerc..)

сплю спокойной

далее проверяю все конфиги (ssh, http, sudoerc..)

все важные конфиги (стараюсь проглядеть все запускаемые сервисы, особенно ssh, ftp, http, sudoerc)

да, перед тем как делать whatprovides и прочие манипуляции с rpm надо ещё проверить ключи.

ну а о том что если взломщик получил рута, то никогда тебе не покажет себя в ластах и rhunter/chkrootkit его вряд ли поймают промолчу я.

rkhunter/chkrootkit найдут тот же svh5, а эту штуку используют очень часто и мало кто вытирает «комменты» этой штуки из файлов в ее поставке. Ласт опять же смотреть стоит в любом случае. Тем более если брал кто-то знакомый, или просто забыли замести следы. Таки да в нормальных дистрибутивах top после подмены ругнется на приоритет или еще что-то, уже не помню, но такое поведение сразу должно показаться странным. И опять же в том же htop все будет видно ибо его не подменяли. rkhunter же покажет скрытое и.т.д в отсчете и у него достаточно высокий процент ложного срабатывания, что тут как раз кстати, с его отсчета будет своего рода основа для уже ручной проверки. В любом случае вряд ли будет применено что-то экстравагантное. А самописные биндшелы на том же перле палятся в два счета. А вообще и тот же .bash_history удалять шредаром в случае чего вряд ли будут. А так если уже такое каким-то образом допустил, то имхо сразу восстанавливаем с бекапа, которые лежал в защищенном месте. Но в общем переустанавливаем, ведь если такое допустил, то и бекап вряд ли есть Ну имхо сначала лучше бы расследовать перед этим, почему и как.

Дальше, find / -xdev -inum 111111 должен найти имена файлов. debugfs с ncheck тоже может.

Вот этот файл не находит

Вот я и спрашиваю, если удалили тот файл, которому этот блок принадлежал, затем создали новый файл с тем же именем, что должно найтись? Новый файл, следы удалённого, или ничего?

Но если находятся логи, которые никуда не должны писаться, тогда что-то ещё.

Вот я и спрашиваю, если удалили тот файл, которому этот блок принадлежал, затем создали новый файл с тем же именем, что должно найтись?

Во-первых, в Ext* система файлов двууровневая, у каждого файла есть inode, а имена файлов — это не более чем записи в специальном файле типа d (directory), причём одному айноду может соответствовать сколько угодно имён. Когда все имена айнода удаляются, он помечается как неиспользуемый.

Если ты создашь новый файл с тем же именем, то скорей всего он будет создан в другом месте жесткого диска, значит найдёт и его содержимое и содержимое старого файла. Однако, через некоторое время, содержимое старого файла будет затёрто новыми файлами (поэтому если что-то случайно удалил, сразу же следует выключить комп или хотя бы перемонтировать файловую систему только на чтение.

Логи терминала по идее писаться никуда не должны, но они пишутся. Хотя может это Xfce Terminal такой умный?

Кстати, у mopsene вроде как раз Slackware с Xfce.

Можешь проверить?

Да, есть. Проработала минут 10 и выдала:

root@darkstar:~# dmesg | grep err

Сейчас, наверное, еще найдет. Причем я запускал из-под openSuse. Диск со слакой пал смертью храбрых, общий у openSuse и Slackware диск это /home. Копать туда. Сейчас попробую сузить круг подозреваемых прозреваю, что это пишет konsole или terminal.

P.S. Могу повторять кого-то, тред не читал.

P.S. Могу повторять кого-то, тред не читал.

Никого кроме тебя не нашлось с Xfce и Slackware

Сейчас попробую сузить круг подозреваемых прозреваю, что это пишет konsole или terminal.

Я думаю, что это пишет Terminal, но что-то в этом не так, не должны приложения писать мимо существующих файлов в неразмеченное пространство.

root@darkstar:~# dmesg | grep err

Вот, похоже на то что у меня. Ты грепал с оффсетом? Если да, попробуй найти айнод. Не знаю, как у тебя, а у меня сектор по 4096 байт, так что надо оффсет делить на это число что бы получить номер сектора, который можно скормить debugfs. Выяснено экспериментальным путём, путём сравнения результата debugfs bmap от файла и оффсета, найденного grep со строкой из файла.

Если тебе удастся узнать имя файла с этой фигнёй, то можно будет просто по нему погуглить или погрепать в исходниках Terminal

общий у openSuse и Slackware диск это /home

Я грепал только по корневому разделу Slackware, /home у меня тоже отдельно, потому туда я складывал логи.

Это что-то другое. В консоль вывалился также этот тред, очевидно, что это ошметки чего-то. Может буфера? Сохраняются только те команды, которые ты выделял мышкой?

Вот как это выглядит http://ompldr.org/vYnk2cg

Не понятно, ты какой раздел грепаешь-то? /home? Или /?

Не, /dev/sda1 (/) и /dev/sda2(/home).

Не, /dev/sda1 (/) и /dev/sda2(/home).

В /home ты наверное и найдёшь кеш браузера. Вообще, у тебя хостнейм может быть не darkstar

Вот как это выглядит http://ompldr.org/vYnk2cg

поковыряй debugfs-ом вот эти зелёные оффсеты, похоже таки на дамп терминала. Ещё попробуй dd или чем-то наподобие сдампить окрестности этого оффсета с устройства и посмотреть, от чего эти фрагменты

Сохраняются только те команды, которые ты выделял мышкой?

Не знаю, возможно.

Хм...

debugfs 1.41.14 (22-Dec-2010)
Block	Inode number
4059438633	<block not found>

Вот и у меня, ни по одному из блоков ничего не нашлось.

Так что насчёт попытки дампа окрестностей этого оффсета? Там только сама команда или целый кусочек лога из консоли?

4059438633

У тебя винт на 15 терабайт или ты забыл поделить на размер блока?

(хотя нет, по одному из оффсетов нашелся какой-то питоно-скрипт из комплекта опенофиса, но почему он попал в поиск не представляю)

У меня по текущему хостнейму одни java.net.UnknownHostException. Пробую их ковырять, записать куда-нибудь выдернуть, получаю только:

0+0 записей считано
0+0 записей написано
скопировано 0 байт (0 B), 0,000425674 c, 0,0 kB/c

Ты знаешь английский? Давай напишем Патрику? Помню приятель тоже писал ему по какому-то глупому вопросу, он ответил. Только я плохо умею составлять письма на английском.

Забыл поделить, но это ничего не меняет, остальное я искал правильно.

скопировано 0 байт (0 B), 0,000425674 c, 0,0 kB/c

какой командой? какой оффсет?
укажи count=1 хотя бы

Ты знаешь английский?

В чатах кое-как на нём общаюсь

Давай напишем Патрику?

Зачем ему писать, если проблема может быть вообще в моём компьютере? Надо вначала выловить, что за хрень туда пишет и почему, а потом уже писать, если это руткит или серьёзный баг, и не Патрику, а в список slackware-security

какой командой? какой оффсет?

dd, 284633.

Зачем ему писать, если проблема может быть вообще в моём компьютере?

И в моем? Так не бывает.

Только несколько блоков снял при помощи dd, вот что получилось http://ompldr.org/vYnk4Yg .

На домашнем сервере к счастью не нашёл, а вот на ноуте есть та же очень подозрительная хрень.

Debian stable, gnome2, gnome-terminal

Именно рутовый раздел ( у меня sda2 -> lvm -> luks -> ext4 )

anonymous_sama высказал правильную идею:

Потом все процессы и лучше через htop, top, ps просто подменить. Короче думаю нужно понабирать всякую чушь от рута, посмотреть пишется ли оно в этот файл. И если пишется пробовать отследить

Попробую отследить через blktrace | blkparse. Как раз пару дней свободные, а тут даже не паранойя, а здравый смысл бьёт тревогу.

Кстати позволю себе небольшой оффтоп. x64 дистрибутив дает очень интересный плюс. Просто дело в том, что практически все руткиты, которые есть в относительно публичном доступе и которые идут уже с бинарниками для подмены включают в себя только x32 бинарники.

У меня x86_64

Подтверждаю - Ubuntu 11.04(смотрел в мир около 3 суток)
На стабильном дебиане отсутствует(смотрит в мир постоянно)

Не спасет от руткита в репозитории и лени проверить хеш-суммы.

Да, помню как-то через стандартную обновлялку убунты проигнорировал предупреждение о том, что ключи не совпадают и обновил. Может владелец зеркала вредит?

У меня тоже самое, отписал сюда:
Исследование swap-раздела ОС, ушедшей в suspend to disk

У меня на рут разделе был /tmp, но его я уже снес, забил вроде все место.
Так же сократил количество резервированных блоков до 0%, забил все место файлами.
Но мои данные все равно грепаются. :)

Да. Проверьте где у вас /tmp.

Я все же не думаю что это бекдор или троян, скорее всего два варианта:
- Либо мы чего то все не учитываем.
- Либо какая то часть системы юзает диск вместо оперативки для каких то целей.