Unerklärliche Zugriffe auf smb-gemountetes NAS

[soulsurfer42]

Hallo Forum,
vielleicht fällt hier ja jemandem eine Erklärung ein. Bei uns ist eine virtuelle Maschine, auf der Ubuntu 8.10 (Desktop, nicht Server) läuft, (u.a.) für die Erstellung von Backups zuständig. So werden einige Daten auch auf ein NAS gesichert, das in einem Nebenraum steht. Die Sicherung passiert täglich um 13:00 Uhr mit flexbackup und dauert allenfalls ein paar Sekunden. Das NAS ist per smb eingebunden.

Irgendwann fiel mir auf, dass die Festplatte des NAS ununterbrochen rödelte. Nach einigem Suchen und mit Hilfe von Wireshark konnte ich feststellen, dass das besagte virtuelle Maschine war. Dabei wurde auch auf Ordner zugegriffen, die nichts mit dem Backup zu tun haben konnten.

Dieses Verhalten kommt mir merkwürdig vor, denn ich habe der Kiste ganz sicher nicht gesagt, dass sie das NAS auslesen soll.

Hat jemand eine Erklärung? Die Sache ist mir nicht geheuer, weshalb die Backups derzeit nicht laufen - wie Ihr Euch vorstellen könnt, ist das kein Dauerzustand...

Vielen Dank im Voraus,

Christian

[marce]

klingt nach irgendwelchen Index-Diensten, Locate-DB, ...

Schau Dir einfach mal die Prozessliste an, wenn entsprechend was am laufen ist...

[Stormbringer]

Etwas ähnliches habe ich mal im Oktober oder November beobachtet.
Es war, wie sich nachher herausstellte, ein XP oder Vista-System mit aktivierter 'Automatisch nach Netzwerkordnern und Druckern suchen' und der MS- oder Google-Desktopsuche ... da wurden einfach alle im Netzwerk befindlichen shares durchsucht.

[soulsurfer42]

Hallo,

vielen Dank für Eure Antworten. In der Prozessliste bin ich nicht recht fündig geworden. Die Abfrage geht allerdings wohl definitiv von dem Ubuntu-Rechner aus - ich habe heute Nachmittag nochmal ein Notebook mit zwei Netzwerkkarten dazwischen gehängt und Wireshark befragt.

Es bleibt merkwürdig. Hier spricht außer mir (und ich bin selbst wahrlich nicht besonders bewandert) kein Mensch Linux. Die Abfragen des Rechners tragen stets den Hinweis, es handele sich um "RAndX"-Abfragen. Ich werde da nicht schlau draus.

Weiß vielleicht jemand von vergleichbaren Indexierungsprogrammen unter Linux, auf die ich das Ergebnis von "ps aux | less" untersuchen könnte?

Bedankt und entschuldigt die späte Rückmeldung - Arbeit...

Gruß,

Christian

[Aqualung]

Lass mal


sudo tcpdump -vv -s 65535

auf der Ubutu-VM laufen und poste den output.

[soulsurfer42]

So, das hat leider einen Moment gedauert - ich musste mich erstmal erkundigen, was dieses tcpdump macht, damit ich hier nicht versehentlich unsere Unternehmensgeheimnisse poste. Ich hoffe, Ihr helft mir trotzdem weiter. Ein Auszug mit tcpdump ergibt folgendes:


13:08:28.309913 IP (tos 0x10, ttl 64, id 20618, offset 0, flags [DF], proto TCP (6), length 88) noname.ssh > 172.16.3.45.3138: P, cksum 0xa0be (correct), 3303061487:3303061535(48) ack 2367990979 win 13464
13:08:33.347869 IP (tos 0x10, ttl 64, id 20619, offset 0, flags [DF], proto TCP (6), length 152) noname.ssh > 172.16.3.45.3138: P, cksum 0x39cc (correct), 48:160(112) ack 1 win 13464
13:08:33.347900 IP (tos 0x0, ttl 128, id 59975, offset 0, flags [DF], proto TCP (6), length 40) 172.16.3.45.3138 > noname.ssh: ., cksum 0x8db8 (correct), 1:1(0) ack 160 win 65535
13:08:28.323505 arp who-has fritz.fonwlan.box tell noname
13:08:28.324652 arp reply fritz.fonwlan.box is-at 00:1c:4a:52:00:62 (oui Unknown)
13:08:28.324675 IP (tos 0x0, ttl 64, id 25172, offset 0, flags [DF], proto UDP (17), length 70) noname.47288 > fritz.fonwlan.box.domain: [udp sum ok] 60328+ PTR? 45.3.16.172.in-addr.arpa. (42)
13:08:28.325641 IP (tos 0x0, ttl 64, id 1437, offset 0, flags [none], proto UDP (17), length 70) fritz.fonwlan.box.domain > noname.47288: [udp sum ok] 60328 NXDomain- q: PTR? 45.3.16.172.in-addr.arpa. 0/0/0 (42)
13:08:28.444177 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 70) noname.mdns > 224.0.0.251.mdns: [udp sum ok] 0 PTR (QM)? 45.3.16.172.in-addr.arpa. (42)
13:08:28.537924 IP (tos 0x0, ttl 32, id 18741, offset 0, flags [none], proto TCP (6), length 386) noname.netbios-ssn > noname.58051: P, cksum 0xeca3 (correct), 2471582390:2471582736(346) ack 1470309017 win 65535
>>> NBT Session Packet
NBT Session Message
Flags=0x0
Length=342 (0x156)

SMB PACKET: SMBtrans2 (REPLY)
SMB Command = 0x32
Error class = 0x0
Error code = 0 (0x0)
Flags1 = 0x80
Flags2 = 0x1
Tree ID = 3 (0x3)
Proc ID = 28912 (0x70f0)
UID = 0 (0x0)
MID = 34172 (0x857c)
Word Count = 10 (0xa)
TRANSACT2_OPEN param_length=2 data_length=284
TotParam=2 (0x2)
TotData=284 (0x11c)
Res1=0x0
ParamCnt=2 (0x2)
ParamOff=56 (0x38)
ParamDisp0 (0x0)
DataCnt=284 (0x11c)
DataOff=60 (0x3c)
DataDisp=0 (0x0)
SetupCnt=0 (0x0)
smb_bcc=286
Handle=0 (0x0)
Attrib=Data=
Data: (284 bytes)

[gelöscht]

WARNING: Short packet. Try increasing the snap length



13:08:28.538311 IP (tos 0x0, ttl 64, id 2725, offset 0, flags [DF], proto TCP (6), length 118) noname.58051 > noname.netbios-ssn: P, cksum 0xec85 (correct), 1:79(78) ack 346 win 65535
>>> NBT Session Packet
NBT Session Message
Flags=0x0
Length=74 (0x4a)

SMB PACKET: SMBtrans2 (REQUEST)
SMB Command = 0x32
Error class = 0x0
Error code = 0 (0x0)
Flags1 = 0x0
Flags2 = 0x1
Tree ID = 3 (0x3)
Proc ID = 28912 (0x70f0)
UID = 0 (0x0)
MID = 34173 (0x857d)
Word Count = 15 (0xf)
TRANSACT2_QPATHINFO param_length=8 data_length=0
TotParam=8 (0x8)
TotData=0 (0x0)
MaxParam=2 (0x2)
MaxData=4000 (0xfa0)
MaxSetup=0 (0x0)
Flags=0x0
TimeOut=0 (0x0)
Res1=0x0
ParamCnt=8 (0x8)
ParamOff=66 (0x42)
DataCnt=0 (0x0)
DataOff=0 (0x0)
SetupCnt=1 (0x1)
smb_bcc=9
Parameters=
Data: (8 bytes)
[000] 07 01 00 00 00 00 00 00 \007\001\000\000\000\000\000\000
Data=



13:08:28.538807 IP (tos 0x0, ttl 32, id 18743, offset 0, flags [none], proto TCP (6), length 40) noname.netbios-ssn > noname.58051: ., cksum 0x0429 (correct), 346:346(0) ack 79 win 65535
13:08:28.548266 IP (tos 0x0, ttl 32, id 18745, offset 0, flags [none], proto TCP (6), length 190) noname.netbios-ssn > noname.58051: P, cksum 0x6caf (correct), 346:496(150) ack 79 win 65535
>>> NBT Session Packet
NBT Session Message
Flags=0x0
Length=146 (0x92)

SMB PACKET: SMBtrans2 (REPLY)
SMB Command = 0x32
Error class = 0x0
Error code = 0 (0x0)
Flags1 = 0x80
Flags2 = 0x1
Tree ID = 3 (0x3)
Proc ID = 28912 (0x70f0)
UID = 0 (0x0)
MID = 34173 (0x857d)
Word Count = 10 (0xa)
TRANSACT2_QPATHINFO param_length=2 data_length=88
TotParam=2 (0x2)
TotData=88 (0x58)
Res1=0x0
ParamCnt=2 (0x2)
ParamOff=56 (0x38)
ParamDisp0 (0x0)
DataCnt=88 (0x58)
DataOff=60 (0x3c)
DataDisp=0 (0x0)
SetupCnt=0 (0x0)
smb_bcc=90
Parameters=
Data: (2 bytes)
[000] 00 00 \000\000
Data=
Data: (88 bytes)

[gelöscht]

WARNING: Short packet. Try increasing the snap length



13:08:28.549035 IP (tos 0x0, ttl 64, id 2726, offset 0, flags [DF], proto TCP (6), length 132) noname.58051 > noname.netbios-ssn: P, cksum 0x3859 (correct), 79:171(92) ack 496 win 65535
>>> NBT Session Packet
NBT Session Message
Flags=0x0
Length=88 (0x58)

SMB PACKET: SMBtrans2 (REQUEST)
SMB Command = 0x32
Error class = 0x0
Error code = 0 (0x0)
Flags1 = 0x0
Flags2 = 0x1
Tree ID = 3 (0x3)
Proc ID = 28912 (0x70f0)
UID = 0 (0x0)
MID = 34174 (0x857e)
Word Count = 15 (0xf)
TRANSACT2_QPATHINFO param_length=22 data_length=0
TotParam=22 (0x16)
TotData=0 (0x0)
MaxParam=2 (0x2)
MaxData=4000 (0xfa0)
MaxSetup=0 (0x0)
Flags=0x0
TimeOut=0 (0x0)
Res1=0x0
ParamCnt=22 (0x16)
ParamOff=66 (0x42)
DataCnt=0 (0x0)
DataOff=0 (0x0)
SetupCnt=1 (0x1)
smb_bcc=23
Parameters=
Data: (22 bytes)

Sagt das jemandem etwas? Das Phänomen hatte sich zwischenzeitlich verabschiedet, weshalb ich warten musste, bis ich aussagekräftigen Output generieren konnte. Wireshark teilt dabei übrigens mit, dass immer nur ein bestimmtes Verzeichnis abgefragt wird, in dem ein weiteres, nicht von der virtuellen Maschine verwaltets Backup sein Zuhause hat.

Für jede Hilfe dankbar,

Christian

[marce]

editiere das Posting bitte und verwende die [code]-Tags - so kann das ja keiner lesen.

[soulsurfer42]

Hallo Forum,

eine Erklärung für das merkwürdige Verhalten habe ich zwar immer noch nicht - aber trotzdem eine Lösung gefunden.

Ich habe das Paket "smbclient" neu installiert - danach war Ruhe.

Manchmal kann es so einfach sein. Danke für die Antworten,

Christian

[oziris]

Warum hat eigentlich keiner an Logs gedacht. Samba kann sehr detailliert loggen.