I'd like advice on choosing a method to collect file access statistics on NTFS volumes under Windows Vista and Windows 7 (32 & 64-bit). I'd like to count file create/open, delete, read/write accesses for every file.
API hooking is out. I need system-wide counts, and both 32 and 64-bit OS without mucking up the OS. Also, I don't think Shell Notification would work.
I know I could do it by installing a file system filter driver. The Windows DDK has a samples, and that's how Mark Russinovich's FileMon (Sysinternals) works.
I think I might also accomplish this using WMI, but I'm not sure. That is one crazy messed up API. But if Microsoft will gather the stats for me, I'll use it.
So the question is, which method would be best & why. Am I missing another possibility, and would WMI do it?
In windows Vista you can try Reliability and Performance Monitor with User Defined Data Collector Set. Click "New", then go custom, add System counter for file control operations.
The Windows Change Journal should do the job:
http://msdn.microsoft.com/en-us/library/aa363798%28VS.85%29.aspx
It gives you exacly what you need.
Getting the full filename is a bit of a problem but there is a nice article around that describes exacly how to do that.
Related
So, I have a collection of Windows Server 2016 virtual machines that are used to run some tests in pairs. To perform these tests, I copy a selection of scripts and files from the network on to the machine, before performing the tests.
I'm basically using a selection of scripts that have existed around here since before my time and whilst i would like to use other methods, so much of our infrastructure relies on these scripts that overhauling the system would be a colossal task.
First up, i sort out the mapped drives with
net use X: \\network\location1 /user:domain\user password
net use Y: \\network\location2 /user:domain\user password
and so on
Soon after, i use rsync to copy files from a location in /cygdrive/y/somewhere to /cygdrive/c/somewhere_else
During the rsync, i will get errors that "files have vanished" (I'm currently unable to post the exact error, I will edit this later to include this). When i check what's currently in the /cygdrive directory, all i see is /cygdrive/c and everything else has disappeared.
I've tried making a symbolic link to /cygdrive/y in a different location, I've tried including persistent:yes on the net use command, I've changed the power settings on the network card to not sleep. None of these work.
I'm currently looking into the settings for the virtual machines themselves at this point, but I have some doubts as we have other virtual windows machines that do not seem to have this issue.
Has anyone has heard of anything similar and/or knows of a decent method to troubleshoot this?
Right, so I've been working on this all day and finally noticed a positive change, but since my systems are in VMware's vCloud, this may not work for some people. It's was simply a matter of having the VM turned off and upgrading the Virtual Hardware Version to the latest version. I have noticed with this though, that upon a restart, one of the first messages that comes up mentions that the computer is "disabling group policies".
I did a bit of research into this and found out that Windows 8 and 10 (no mention of any Windows Server machines) both automatically update Group Policies in the background, disconnecting and reconnecting mapped drives to recreate them.
It's possible that changing the Group Policy drive from "recreate" to "update" should fix this issue, and that the Virtual Hardware update happened to resolve this in a similar manner.
I would like to create something like "file honeypot" on Windows OS.
The problem I would like to answer is this:
I need to detect that file is accessed (Malware wants to read file to send it over internet) so I can react to it. But I do not know how exacly tackle this thing.
I can periodically test file - Do not like this sollution. Would like some event driven without need to bother processor every few ms. But could work if file is huge enought so it cannot be read between checks.
I could exclusively open file myselve and somehow detect if file is accessed. But I have no idea how to do this thing.
Any idea about how to resolve this issue effectively? Maybe creating specialized driver could help but I have little experience in this.
Thanks
Tracking (and possibly preventing) filesystem access on Windows is accomplished using filesystem filter drivers. But you must be aware that kernel-mode code (rootkits etc) can bypass the filter driver stack and send the request directly to the filesystem. In this case only the filesystem driver itself can log or intercept access.
I'm going to assume that what you're writing is a relatively simple honeypot. The integrity of the system on which you're running has not been compromised, there is no rootkit or filter driver installation by malware and there is no process running that can implement avoidance or anti-avoidance measures.
The most likely scenario I can think of is that a server process running on the computer is subject to some kind of external control which would allow files containing sensitive data to be read remotely. It could be a web server, a mail server, an FTP server or something else but I assume nothing else on the computer has been compromised. And the task at hand is to watch particular files and see if anything is reading them.
With these assumptions a file system watcher will not help. It can monitor parts of the system for the creation of new files or modification or deletion of existing ones, but as far as I know it cannot monitor for read only access.
The only event-driven mechanism I am aware of is a filter driver. This is a specialised piece of driver software that can be inserted into the driver chain and monitor access to files. With the constraints above, it is a reliable solution to the problem at the cost of being quite hard to write.
If a polling mechanism is sufficient then I can see two avenues. One is to try to lock the file exclusively, which will fail if it is open. This is easy, but slow.
The other is to monitor the open file handles. I know it can be done because I know programs that do it, but I can't tell you how without some research.
If my assumptions are wrong, please edit your question and provide additional information.
Specifics:
VC++ 7; Program works on XP, but crashes on Win7; developed using VS2003.NET (old I know but it's what I have to work with and it works fine thank you very much)
I've got a program that runs great on XP (32-bit). However, I've recently tested it with Win7 and all kinds of choas breaks loose. My strong suspicion is how my program deals with registry keys.
NOTE: The program does not create or destroy keys, only queries for keys and returns interesting values. ("Interesting" described below)
In the simplest form, the program reads data from a SCSI attached device, and saves the data to a file on the host PC. The program queries the registry for SCSI adapters and returns the adapter IDs which the program uses to access the device.
To me, it doesn't look like the registry structure has changed from XP to Win7 but not 100% sure. Any insight on that would be great :)
Also, I read at: http://www.techsupportalert.com/content/how-windows7-vista64-support-32bit-applications.htm that the way Win7 does things is like a reflection. Does this change how I should query for the key? If so, any information on how to structure the query would be great.
I think what I need to know is:
Is it as simple as changing the hKey (or lpValueName) in the RegQueryValueEx method?
Or does this mean I need to change some other aspect of the RegQueryValueEx method?
Or something else entirely?
Thank you in advance!
It's worth running your application through the Application Verifier on your own machine first. Of particular interest is the LuaPriv section which will highlight instances where your application is doing operations that don't play well in Vista or Win-7. This should catch any time where you might be consulting registry locations that differ from in XP.
One thing to be aware of is that if you are reading registry entries created by another application then it's possible that they might be in a different place, eg in the 32-bit or 64-bit views, or virtualised to the per-user location (this will typically happen if a process ran thinking it could write anywhere, but didn't have admin privileges, so Windows will sandbox the registry writes into the virtualised area).
I'm looking for a software which will allow me to synchronize files in specyfic folders between my linux boxes. I have searched a lot of topics and what I've found is Unison. It looks prety good but it is not under development anymore and does not allow me to see file change history.
So the question is - what is the best linux file synchronizer, that:
(required) will synchronize only selected folders
(required) will synchronize computers at given time (for example each hour)
(required) will be intelligent - will remember what was deleted and when and will ask me if I want to delete it on remote machine too.
(optionally) will keep track of changes and allow to see history of changes
(optionally) will be multiplatform
Rsync is probably the de facto.
I see Unison is based on Rsync -- not sure if Rsync alone can achieve number 3 above.
Also, see this article with detailed information about rsync, including available GUI's for it.
While I agree Rsync is defacto swissknife for linux users, I found 2 other projects more interesting especially for use case where I have 2 workstations in different locations and laptop, all 3 machines for work, so I felt pain here. I found really nice project called:
https://syncthing.net/
I run it on public server with vpn access where my machines are always connected and it simply works. It has gui for monitoring purposes (basic, but enough infor available)
Second is paid, but with similar functionality on top built in:
https://www.resilio.com/
Osync is probably what you're looking for (see http://www.netpower.fr/osync )
Osync is actually rsync based but will handle number 3 above without trouble.
Number 4, keeping track of modified files can be more or less achieved by adding --verbose parameter which will log file updates.
Actually, only number 5 won't work. Osync runs on most unix flavors but not windows.
I posted this question a while ago regarding where to store non-user specific application data on Linux.
As you can see, I intended to use "/Library/Application Support” on Mac and perhaps "/var/lib" or "/usr/share" on Linux.
On an existing application (currently Windows only) we use “\ProgramData” on Vista & Windows 7 and “\Documents and Settings\All Users“ on Windows XP (both obtained using System.getenv("ALLUSERSPROFILE"), which does not work on Mac or Linux).
The problem I am finding with the Mac & Linux locations (unlike the Windows ones) is that they are not accessible by non-root/admin users, which sort of defeats the purpose of using them.
What is the best practice is this case? We could simply store the application data in the user's home directory. I wouldn't actually be dead against this, as it seems reasonable for the application to appear completely 'new' when a new user tries using it. The main problem this gives us is that each user would have to enter the serial number in order to activate the application (the activation info is part of the 'application data' we need to store). This isn't really ideal.
That said, if there is no real alternative then I suppose it will have to do.
What do you mean by non-user specific application data?
Read-only resources needed by application, such as localization strings or button icons:
on Mac they are stored in application bundle itself, in Resources subfolder
on Linux, they can be stored near application binary, in /opt/<app>/etc for instance.
Read/write properties, such as serial number:
you can consider this information as user-specific application data, so it should go somewhere in $HOME directory
you can consider this information as computer-wide application data, in which case its setting should be perfomed during software installation process, i.e., with administrative privileges.
/Users/Shared/ is writable for everyone. That said, if you need to support computer-wide licenses, the best place for serial numbers, IMHO, is indeed /Library/Application Support. You would have to use Authorization Services once to ask for an admin password and save the serial number there. If a user fails to enter the admin password, save the serial number in ~/Library/Application Support instead.