Pagina 1 van 1

[redhat] loggen NFS verkeer

Geplaatst: 04 sep 2008, 16:45
door vimas
Sinds iets meer dan een jaar heb ik een NFS server in dienst (RedHat EL4U4) waarop een 20 tal clients connecteren. Alle clients delen dezelfde databestanden en hebben daarom dezelfde rwx rechten.

Nu blijken zijn er twee keer een hele boel files gewist, Terwijl de gebruikers wijzen naar "de computer" vermoed ik dat de wisopdracht veroorzaakt wordt door een van de NFS clients. Om dit aaan te tonen wil ik het NFS protocol loggen zodat er bij elke wis (unlink) call een lijntje met tijdstip, ip adres en bestandsnaam geregistreerd wordt.
Via /proc/sys/sunrpc/nfsd_debug kan ik wel verbose logging genereren doch de gegevens die ik zoek ontbreken.

Heeft iemand een idee hoe ik de NFS verbindingen kan monitoren, bv met ngrep zodat de unlink call zichtbaar wordt?

Geplaatst: 04 sep 2008, 20:20
door Styno
Ik denk dat je op rh eerder in de richting van 'auditd' moet gaan zoeken
snelle google. De kans bestaat er wel in dat je nog wat extra gaat moeten opsnorren om de link te leggen naar ip omdat je met een nfs server zit die voor iedereen open staat.

Waarom eigenlijk op deze manier de files sharen?

Geplaatst: 04 sep 2008, 23:54
door vimas
Auditd kan me wel vertellen wanneer en welk bestand gewist wordt doch niet wie (IP adres) er voor verantwoordelijk is. Op Solaris hebben ze hiervoor een nfslogd doch voor RH ontbreekt deze. Daarom dat ik er via een ngrep probeer uit te komen. Ik herken wel de bestandsnamen in de paketten doch weet niet hoe de unlink call verstuurd wordt.

De files worden geshared door een werkgroep van Mac gebruikers die allemaal dezelfde (foto) bestanden bewerken. Ze zitten op een afgeschermde LAN en dus is er geen extern gevaar.

Geplaatst: 05 sep 2008, 08:30
door Styno
Ik begrijp vanwaar de opstelling komt, maar denk niet dat het de beste manier van implementeren is. Op deze manier kan zelfs zonder kwaad opzet een foutje gebeuren waardoor net de files verdwijnen die er echt wel hadden moeten blijven staan.
Er bestaan specifieke producten voor filesharing van unix fs naar afs/cifs/... bv. Helios met authentificatie naar passwd/nis/ldap/ad/... Kost wel iets en wat werk voor te implementeren (er zijn bedrijven in Belgie die dit product ondersteunen - pm) maar op lange termijn zie ik toch meteen de voordelen.

Dit is mischien niet meteen het antwoord dat je zoekt, maar ik heb momenteel geen RH nfs server bij de hand zodat ik specifiek mee kan zoeken.

Geplaatst: 05 sep 2008, 08:52
door Styno
Bon, toch ff verder mee gegaan..
De volgende zetten zowel debug voor rpc als nfsd aan.

Code: Selecteer alles

echo 32767 > /proc/sys/sunrpc/rpc_debug
echo 32767 > /proc/sys/sunrpc/nfsd_debug
Remove van de file 'test' door IP '10.0.0.1' geeft het volgende:

Code: Selecteer alles

Sep  5 06:47:28 architect kernel: [  673.692301] svc: socket ffff88000fd72100 TCP data ready (svsk ffff8800107d3c00)
Sep  5 06:47:28 architect kernel: [  673.692324] svc: socket ffff88000fd72100 served by daemon ffff88000f7fa000
Sep  5 06:47:28 architect kernel: [  673.692368] svc: server ffff88000f7fa000, pool 0, socket ffff8800107d3c00, inuse=2
Sep  5 06:47:28 architect kernel: [  673.692370] svc: tcp_recv ffff8800107d3c00 data 1 conn 0 close 0
Sep  5 06:47:28 architect kernel: [  673.692392] svc: socket ffff8800107d3c00 recvfrom(ffff8800107d3cac, 0) = 4
Sep  5 06:47:28 architect kernel: [  673.692395] svc: TCP record, 112 bytes
Sep  5 06:47:28 architect kernel: [  673.692407] svc: socket ffff8800107d3c00 recvfrom(ffff88000efa1070, 3984) = 112
Sep  5 06:47:28 architect kernel: [  673.692409] svc: TCP complete record (112 bytes)
Sep  5 06:47:28 architect kernel: [  673.692410] svc: socket ffff88000fd72100 served by daemon ffff88000f19c000
Sep  5 06:47:28 architect kernel: [  673.692414] svc: got len=112
Sep  5 06:47:28 architect kernel: [  673.692421] svc: svc_authenticate (1)
Sep  5 06:47:28 architect kernel: [  673.692432] svc: socket ffff88000fd72100 busy, not enqueued
Sep  5 06:47:28 architect kernel: [  673.692433] svc: calling dispatcher
Sep  5 06:47:28 architect kernel: [  673.692435] nfsd_dispatch: vers 3 proc 12
Sep  5 06:47:28 architect kernel: [  673.692441] nfsd: REMOVE(3)   28: 00070001 0002e90f 00000000 755fd5e9 7246dba6 dcfeb28b test
Sep  5 06:47:28 architect kernel: [  673.692445] nfsd: fh_verify(28: 00070001 0002e90f 00000000 755fd5e9 7246dba6 dcfeb28b)
Sep  5 06:47:28 architect kernel: [  673.692498] nfsd: fh_lock(28: 00070001 0002e90f 00000000 755fd5e9 7246dba6 dcfeb28b) locked = 0
Sep  5 06:47:28 architect kernel: [  673.692597] svc: server ffff88000f19c000, pool 0, socket ffff8800107d3c00, inuse=3
Sep  5 06:47:28 architect kernel: [  673.692599] svc: tcp_recv ffff8800107d3c00 data 1 conn 0 close 0
Sep  5 06:47:28 architect kernel: [  673.692602] svc: socket ffff8800107d3c00 recvfrom(ffff8800107d3ca8, 4) = -11
Sep  5 06:47:28 architect kernel: [  673.692604] RPC: TCP recvfrom got EAGAIN
Sep  5 06:47:28 architect kernel: [  673.692605] svc: got len=-11
Sep  5 06:47:28 architect kernel: [  673.692608] svc: server ffff88000f19c000 waiting for data (to = 900000)
Sep  5 06:47:28 architect kernel: [  673.703461] svc: socket ffff8800107d3c00 sendto([ffff88000f781000 124... ], 124) = 124 (addr 10.0.0.1, port=949)
Sep  5 06:47:28 architect kernel: [  673.703469] svc: server ffff88000f7fa000 waiting for data (to = 900000)
Het IP staat er alvast in, hoe ze te mappen is me niet duidelijk, maar dit kan je wel een goed idee geven als er een hoop files in 1x aan het verdwijnen is.

Geplaatst: 14 okt 2008, 15:37
door vimas
Na enig zoeken heb ik dan toch log bij elke verwijderde file:

In onderstaand script, capteert tcpdump de eerste 400 characters in elk nfs pakket. Telkens een bestand gewist wordt, verschijnt er een lijntje met een tijdsaanduiding, 'remove' en filenaam op de pipe. grep schrijft deze lijn in de loglile NFS.remove

$ cat nfsremove.sh
#!/bin/sh
/usr/sbin/tcpdump -s 400 -v -T rpc port nfs|/bin/grep remove >NFS.remove