Dowiedz się, który proces zmienia plik


35

Próbuję znaleźć niezawodny sposób znalezienia, który proces na moim komputerze zmienia plik konfiguracyjny ( /etc/hostsa konkretnie).

Wiem, że mogę użyć, lsof /etc/hostsaby dowiedzieć się, jakie procesy aktualnie otwierają plik, ale to nie pomaga, ponieważ proces oczywiście otwiera plik, zapisuje do niego, a następnie zamyka go ponownie.

Patrzyłem również na lsofopcję powtarzania (-r), ale wydaje się, że idzie ona tak szybko, jak raz na sekundę, co prawdopodobnie nigdy nie uchwyci trwającego zapisu.

Znam kilka narzędzi do monitorowania zmian w systemie plików, ale w tym przypadku chcę wiedzieć, który proces jest odpowiedzialny, co oznacza złapanie go w akcie.

Odpowiedzi:


52

Aby to znaleźć, możesz użyć inspekcji. Jeśli nie jest jeszcze dostępny, zainstaluj i włącz inspekcję swojej dystrybucji.

ustaw obserwację audytu na / etc / hosts

/sbin/auditctl -w /etc/hosts -p war -k hosts-file

-w watch /etc/hosts
-p warx watch for write, attribute change, execute or read events
-k hosts-file is a search key.

Poczekaj na zmianę pliku hosts, a następnie użyj ausearch, aby zobaczyć, co jest zalogowane

/sbin/ausearch -f /etc/hosts | more

Dostaniesz masę wyników, np


time-> Wed Oct 12 09:34:07 2011 type = PATH msg = audit (1318408447.180: 870): item = 0 name = "/ etc / hosts" i-węzeł = 2211062 dev = fd: 00 mode = 0100644 ouid = 0 ogid = 0 rdev = 00: 00 obj = system_u: object_r: etc_t: s0 type = CWD msg = audit (1318408447.180: 870): cwd = "/ home / iain" type = SYSCALL msg = audit (1318408447.180: 870): arch = c000003e syscall = 2 sukces = tak wyjście = 0 a0 = 7fff73641c4f a1 = 941 a2 = 1b6 a3 = 3e7075310c pozycje = 1 ppid = 7259 pid = 7294 au id = 1001 uid = 0 gid = 0 euid = 0 suid = 0 fsuid = 0 egid = 0 sgid = 0 fsgid = 0 tty = pts0 ses = 123 comm = "touch" exe = "/ bin / touch" subj = user_u: system_r: unconfined_t: s0 key = "hosts-file"


W tym przypadku użyłem polecenia touch do zmiany sygnatury czasowej plików, jego pid to 7294, a ppid to 7259 (moja powłoka).


2
„Włącz inspekcję dla twojej dystrybucji” prawdopodobnie powinno zostać nieco rozszerzone. Irytujące powyższe polecenia nie dały mi ani błędów, ani wyników. „/ sbin / auditctl -e 1” również nie pomogło. Uruchomienie demona kontroli w celu zalogowania pomogło - „/etc/init.d/auditd start” (chociaż usunęło to moje reguły, więc musiałem je wprowadzić ponownie).
tobixen

Nie działało dla mnie, ausearchzawsze wraca<no matches>
m0skit0

1
czasami może być konieczne ustawienie wielu audytów, aby uzyskać rzeczywisty proces, który zainicjował modyfikację, jeśli proces ten na przykład wywołuje zewnętrzne polecenie, aby wykonać za niego pracę. tzn. próbowałem dowiedzieć się, dlaczego pozycja crontab użytkownika jest ciągle resetowana. komenda crontab była odpowiedzialna, ale zanim sprawdziłem ppid, z którego wyszła, musiałem również przeprowadzić audyt / usr / bin / crontab, a następnie dopasować znacznik czasu dostępu do crontabu do kontrolowanego wykonania crontab, a następnie sprawdzić to ppid ... które ujawniło, że demon organizacji wymuszał konfigurację crona określonego użytkownika.
Wil

3

Możesz także użyć narzędzi inotify:

  inotifywait -mq -e open -e modify /etc/hosts

14
Auditd jest w stanie udzielić Ci potrzebnych informacji. Chociaż łatwo jest założyć, że inotify pozwoli ci to zrobić - nie zrobi tego, ponieważ nie da ci identyfikatora procesu, który dokonał modyfikacji.
zobiektywizował

2

Po wielu poszukiwaniach znalazłem rozwiązanie, wystarczy użyć tego polecenia: sudo fs_usage | grep [path_to_file]


2
dotyczy tylko MacOS ...
majick

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.