However, just protecting the file against possible intruders is not enough. There must be a way for an admin to know if a file hack has been attempted. This is where File Auditing (event logging, if you will) comes in handy. With NTFS, you can keep track of who has tried to access what file, and if they succeeded. To enable file auditing, use the following steps:
But what good is protecting your data if it simply gets corrupted when the system crashes? Here too, NTFS has a solution. NTFS has superior data recovery capabilities (compared to FAT and FAT32). Each I/O operation that modifies a file on the NTFS volume is viewed by the file system as a transaction and can be managed as an atomic unit. When a user updates a file, the Log File Service tracks all redo and undo information for the transactions. If every step of the I/O process succeeds, then the changes are committed to disk. Otherwise, NT uses the Undo log to roll back the activity and restore the disk to a state before the changes were made. When Windows NT crashes, NTFS performs three passes upon reboot. First, it performs an analysis phase where it determines exactly which clusters must now be updated, per the information in the log file. Then it performs the redo phase where it performs all transaction steps logged from the last checkpoint. Lastly, it performs the undo phase where it backs out of all incomplete transactions. Together, these steps ensure that data corrupt is kept to a minimum.
Yet Another Cool (But Scary) Feature:
At this point, you probably think NTFS is pretty cool. But there is one other cool feature in NTFS that is documented, but not very well publicized (for obvious reasons as you will see). What I am referring to is filestreams (Unix users will be familiar with this feature). To illustrate the concept if filestreams, let’s first picture any file (whether it be a document, a exe or a jpeg) as a garden hose. When you access the data in the file, that data flows through the file in a continuous stream, like water flows through a garden hose. In a typical file, there is only a single data stream, the default stream. All data written to and read from the file comes out of that stream. When Explorer displays (or the command interpreter) reads the size of the file, it is reading the data stored in that stream. In FAT and FAT32, this fact was of little concern since any file could only be given a single stream (the default). However, this all changes in NTFS, which allows any given file to have multiple data streams. This is akin to a garden hose that has within it multiple smaller hoses, each with its own stream of water flowing. In fact, each stream can contain different types of data. One data stream could be a text document, while another could contain WAV file data, another that contains executable code, and yet another that contains jpeg data. You can almost think of files with multiple data streams as a special kind of folder with multiple files stored within it.
To illustrate my point, let’s create a text file with multiple filestreams:
What you’ll see is the text “This is what you’ll see.” The other string of text “This is what you won’t see” is in the file, but it is stored in a separate file stream called hiddenStream. And since most programs do not read data from any stream other than the default stream, that data is hidden from the user. To view the contents of the hidden stream, do the following:
At this point, you should be getting chills, because filestreams brings up some very disturbing possibilities for writing viruses and such. A virus writer could conceivably write the executable code for his virus into a hidden stream of a text file! This way, normal virus scanners would not find the harmful code. To activate the virus, the malicious programmer need only to write a catalyst program that performs a seemingly innocuous file read operation from a text file. The worst part of all of this is that hidden streams are difficult to detect because data written into the file stream is NOT calculated as a part of the file’s size. So you could have a text file that contains 20 bytes of text and 2 megs of executable code and show up as 20 bytes. Even worse, any user could create files with hidden streams, even your guest account users (assuming they can write to a directory).
Thankfully, the situation is not hopeless. For one, hidden file streams can be detected via the use of Windows APIs. Secondly, all hidden streams are lost when the file is copied to a non-NTFS partition. So conceivably, anti virus firms can write scanners that scan form hidden streams. To the best of my knowledge, there haven’t been any serious viruses written to take advantage of this particular feature in NTFS. For now, you can rest easy knowing that the end isn’t quite here yet. But definitely keep filestreams in mind, for if there is a security weakness, somebody will find it sometime.
There you have it – the three most common file systems in a nutshell. I hope this article has been at least mildly entertaining for some of you.