Контроль действия по моему компьютеру.

Вам на самом деле нужно tail -f или был бы что-то как less +F ? Так как это кажется на тихое желание интерактивного пейджера это кажется мне, было бы намного легче придерживаться с less чем повторно реализовать тот самостоятельно.

Заключительное примечание: Вы рассмотрели tail -f file | less?

16
30.11.2012, 18:08
5 ответов

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

Сначала необходимо проверить если inotify включен в ядре:

pbm@tauri ~ $ zcat /proc/config.gz | grep CONFIG_INOTIFY
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y

Следующая вещь сделать установить inotify-tools. Инструкции для различных дистрибутивов, которые Вы могли найти на уровне страницы проекта - это должно быть в репозиториях всех основных дистрибутивов.

После этого inotify готов работать:

inotifywait /dirs/to/watch -mrq

(m = не выходите после одного события, r = рекурсивный, q = тихий)

Например - вывод после ls /home/pbm

pbm@tauri ~ $ inotifywait /bin /home/pbm -mq 
/bin/ OPEN ls
/bin/ ACCESS ls
/bin/ ACCESS ls
/home/pbm/ OPEN,ISDIR 
/home/pbm/ CLOSE_NOWRITE,CLOSE,ISDIR 
/bin/ CLOSE_NOWRITE,CLOSE ls

Важная вещь состоит в том, чтобы правильно установить каталоги для часов:

  • не смотреть / рекурсивно - существует большое чтение-запись к /dev и /proc
  • не наблюдайте свой домашний dir рекурсивно - при использовании приложений существует большое чтение-запись директорам конфигурации приложения, и браузеры представляют директоров

В /proc/sys/fs/inotify/max_user_watches существует параметр конфигурации, который показывает, за сколько файлов можно наблюдать одновременно. Значение по умолчанию (для хинду) о не настолько высоко, поэтому при установке наблюдателя на /home/ Вы могли превысить предел. Вы могли увеличить предел при помощи echo (корневой необходимый доступ).

echo 524288 > /proc/sys/fs/inotify/max_user_watches

Но перед этим необходимо читать о последствиях того изменения.

Опции, которые могли быть интересными для Вас:

  • -d = режим демона
  • -o file = вывод в файл
  • --format = указанный пользователями формат, больше информации в man inotifywait
  • -e EVENT = за развитием какое событие должно следиться (например, access, modify, и т.д., больше информации в man)
8
27.01.2020, 19:48
  • 1
    Чтобы иметь установку длятся между системным сбросом, на Debian можно сделать echo 524288 >> /etc/sysctl.conf && service procps restart. Каков эквивалент в хинду? вещь –  tshepang 23.11.2010, 22:14
  • 2
    I, которую Вы имеете в виду echo "fs.inotify.max_user_watches = 524288" >> /etc/sysctl.conf. В хинду Вы могли использовать тот же метод, но sysctl.conf получен /etc/init.d/bootmisc сценарий init. –  pbm 23.11.2010, 22:23
  • 3
    на самом деле это-/etc/init.d/sysctl. –  OneOfOne 23.11.2010, 23:08

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

Различные вещи уже зарегистрированы в системных журналах, обычно в /var/log (некоторые системы используют другое местоположение такой как /var/logs или /var/adm). В соответствии с нормальной конфигурацией, все логины и монтирование зарегистрированы среди других. Если Вы волнуетесь по поводу стираемых журналов, можно настроить удаленный вход (как сделать, это зависит от реализации системного журнала, но это обычно - одна или две строки для изменения в конфигурационном файле на отправителе и на получателе).

Если Вы или Ваше распределение не отключили эту опцию, каждый файл имеет время доступа (“atime”), который обновляется каждый раз, когда файл читается. (Если файловая система смонтирована с noatime или relatime опция, atime не обновляется.) atime может фальсифицироваться с touch -a, но это обновляет ctime, таким образом, он оставляет трассировку. (Даже корень не может непосредственно удалить эту трассировку, необходимо обойти код файловой системы.)

Различные программы имеют историю сессии. Легко удалить или фальсифицировать, если злоумышленник не забыл делать так. Bash сохраняет ~/.bash_history, браузеры имеют тенденцию писать много материала в их каталоге профиля и так далее. Можно также найти выразительные ошибки или предупреждения в ~/.xsession-errors или /var/log/Xorg.0.log или другое системно-зависимое местоположение.

Много нельдов имеют процесс, считающий ¹ функция. Посмотрите, например, GNU бухгалтерское руководство утилит, запись в руководстве FreeBSD или практическом руководстве Linux или руководстве Соляриса. После того, как включенный, это записывает, какой пользователь, запущенный, что процесс, когда (это регистрируется execve вызовы), и возможно немного больше. Существует большая интересная информация, которую это не регистрирует, такие как файлы, к которым получает доступ процесс.

Если Вы хотите контролировать все доступы к файловой системе, можно обеспечить ее через loggedfs. Очень легко заметить, думает ли парень для взгляда.

Существуют более всесторонние программы входа, но они могли бы потребовать дополнительной поддержки ядра. На Солярисе, FreeBSD, NetBSD и  Mac OS X, существует dtrace (существует происходящий порт Linux, но я не знаю, достиг ли он применимой стадии). Можно также проследить определенные процессы через интерфейс к ptrace системный вызов, например strace на Linux; это может вызвать значимое замедление.

¹ Что-то это не находится в Википедии? Nah, это - сумасшедший разговор.

7
27.01.2020, 19:48

Взгляните на Fail2ban и DenyHØsts.

1
27.01.2020, 19:48
  • 1
    Fail2ban смотрит на журналы доступа для создания определенных действий (например, запрещая IP), но он не генерирует эти виды журналов доступа. DenyHosts полагаются на оболочки tcp для запрета IP, снова, это не связано с OP. –  Barthelemy 23.11.2010, 14:31

Это не точно, что Вы ищете, но некоторые приложения сохраняют список недавно полученных доступ файлов. Кроме того, GNOME сохраняет тот список, к которому можно получить доступ от его Панели.

Другие фиксация должна использовать Журнал Действия GNOME, хотя в прошлый раз я проверил, это не вело учет действия CLI и только интересовалось связанным с файлом действием (чтение, редактируя), игнорируя другие операции.

Можно также посмотреть внутри /var/log каталог, где набор программ хранят их журналы.

1
27.01.2020, 19:48

Принимая достаточно naïveté на стороне Вашего взломщика, можно просто бросить script -qft $USER-$$ 2> $USER-$$-time в его/Ваш соответствующий сценарий входа в систему для контроля его терминальных взаимодействий и воспроизведения с соответствующими командами scriptreplay.

Для контроля доступа уровня файла я рекомендую присоединить strace -fe open с соответствующим входом к sshd и фильтрацией для сессий входа в систему (или возможно лучше просто сделать это от. Предупреждение: Огромные выводы, начиная с выполнения чего-либо в современной системе касается большого количества файлов. Если Вы просто хотите контролировать определенные файлы, взглянуть на auditd и его инфраструктуру поддержки.

Сессии и попытки входа в систему могут быть собраны из системного журнала согласно другим ответам.

1
27.01.2020, 19:48

Теги

Похожие вопросы