views:

113

answers:

3

For an application I'm writing, i want to programatically find out what computer on the network a file came from. How can I best accomplish this?

Do I need to monitor network transactions or is this data stored somewhere in Windows?

+1  A: 

When a file is copied to the local system Windows does not keep any record of where it was copied. So unless the application that created it saved such information in the file then it will be lost.

With file auditing file and directory operations can be tracked, but I don't think that will include the source path with file copies (just who created it and when).

Richard
+1  A: 

Yes, it seems like you would either need to detect the file transfer based on interception of network traffic, or if you have the ability to alter the file in some way, use public key cryptography to sign files using a machine-specific key before they are transferred.

Gian
right, but how? do i need to go into packet sniffing via like winsock or w/e? or is there another solution?
Joshua Evensen
I would agree with Gian, and add that altering the file (at the source machine) is going to be much more robust. But of course it is dependent on having some control over the creation of the files.
nocache
Yeah, that is something I've thought of and it would be ideal, but isn't possible for us. It'd be best if we could, with reasonable reliability, detect files as they come in and figure out who wrote them.
Joshua Evensen
I would suggest in that case that packet sniffing would be the best option, assuming there is no encryption in the transfer protocol you're using. Attempt to detect the start of a transfer, observe the data and calculate a fingerprint, which you store as a (machine,fingerprint) tuple. Then you can compare the fingerprint of a given file against the stored fingerprint to obtain the origin.
Gian
I followed everything there except the "calculate a fingerprint" bit. Do you mean some sort of arbitrary key, or...?
Joshua Evensen
Well, computing a fingerprint is a class of techniques. The technique that will be right for you will depend on the nature of the files. Basically the idea is to use some attributes about the file to compute a code that uniquely identifies it. Something like an MD5 or SHA-1 hash is one example, however you may find other techniques suit your data better (e.g. maybe you only want to inspect the first N bytes of each file).
Gian
A: 

Create a service on either the destination computer, or on the file hosting computers which will add records to an Alternate Data Stream attached to each file, much the way that Windows handles ZoneInfo for files downloaded from the internet.

You can have a background process on machine A which "tags" each file as having been tagged by machine A on such-and-such a date and time. Then when machine B downloads the file, assuming we are using NTFS filesystems, it can see the tag from A. Or, if you can't have a process at the server, you can use NTFS streams on the "client" side via packet sniffing methods as others have described. The bonus here is that future file-copies will retain the data as long as it is between NTFS systems.

Alternative: create a requirement that all file transfers must be done through a Web portal (as opposed to network drag-and-drop). Built in logging. Or other type of file retrieval proxy. Do you have control over procedures such as this?

maxwellb
We'd prefer not to have to do anything at all to the source machine, so none of this is really an option. It would be ideal, but it isn't the situation.
Joshua Evensen