TRIPWIRE
| | ||
Tripwire, like AIDE, is a little different from the other tools discussed so far in this chapter. You use it to audit your files and applications themselves , not the vulnerabilities in those files and applications. Tripwire sits on a system and checks for changes in any files. You can set it up to check important binaries, executables, and configuration files that shouldn't be changing. If a change in the file is detected , Tripwire logs it and can even send e-mail notifications. It's important to note that Tripwire can only detect and notify about file changes; it cannot prevent unauthorized file changes. Nonetheless, Tripwire is a great defense for keeping your systems Trojan-free and making sure that unauthorized people aren't toying around with critical data files.
| Note | Just for a little background, Trojans are applications that appear to be legitimate applications but are actually "hacked" versions of the application that may operate as intended on the surface, but behind the curtains they are hiding or allowing some kind of undesirable system activity. |
Tripwire can run on any number of network devices, Windows, Linux, and Solaris servers. It can also come integrated with the Apache Web Server to monitor any changes to web files and content. Tripwire is a commercial product; you can download an evaluation from http://www.tripwire.com/. However, a separate, open -source Tripwire product is freely available from http:// sourceforge .net/projects/tripwire/. This section will discuss both versions. The actual Tripwire tool works similarly for both versions, but management of Tripwire nodes is much easier with the commercial version.
How does Tripwire monitor files? It watches such things as file size and the computed checksum of the file to come up with a signature that shouldn't change. We'll look at all the different file signature options in the "Understanding Tripwire Policy Files" section.
| Tip | A Unix kernel-based root kit called Knark can actually hide Trojaned system commands from Tripwire. See Chapter 10 for more details. |
Implementation: The Open-source Edition
Let's take a look at the open-source edition available for Linux. Linux RPM packages as well as standard tarballs are available for Tripwire. BSD users should look in the ports repository for Tripwire. No matter what version you install, you have to perform some configuration before you use Tripwire.
Running install.sh
The install.sh script is used to set up Tripwire and must be run with root privileges. When you run it, you'll be prompted to read and accept the license agreement and choose an install location (the default is usually fine). In addition to these standard operations, you'll be asked to provide a site and local passphrase. These are used to encrypt the Tripwire policies, databases, and configuration files to keep them from being tampered with. Once you've entered the passphrases, the script generates keys to use for encrypting your files. You will be prompted for the site passphrase to encrypt your configuration and policy files. It will keep clear-text versions for you to review, just in case you want to change anything.
| Note | Tripwire uses the site key to lock down your Tripwire policies and configuration files. It uses the local key to lock down your Tripwire databases and reports . Setting the site and local passphrases allows you (and only you) to unlock these files for viewing and modification. |
Examining the Policy and Configuration Files
The Tripwire policy file tells Tripwire what files to examine, what types of information to look for, and when to alert you that something has changed. The default installed policy file, twpol.txt, consists of variable and rule definitions. This is covered in more detail in the "Understanding Tripwire Policy Files" section a little later in this chapter. The Tripwire configuration file, twcfg.txt, indicates the locations of files and other preferences that the Tripwire application should use. You normally don't need to change the Tripwire configuration from the default.
Both of these files are encrypted by Tripwire using your site passphrase during install. The actual policy and configuration files that are used by Tripwire are called tw.pol and tw.cfg. They are binary, encrypted files and are installed in the /etc/tripwire directory by default. Tripwire also installs clear-text copies of the policy and configuration files (twpol.txt and twcfg.txt) in case you want to view or modify them. It is recommended that you delete any clear-text copies of the files after you have reviewed their contents. If at a later time you need to modify either of these files in clear-text format, you can use the tools discussed in the "Other Tripwire Utilities" section to accomplish this.
Running Tripwire
Tripwire includes four main operating modes: database initialization, integrity checking, database update, and policy update.
Database Initialization Mode Before you can compare the files on your system with correct signatures, you must establish a baseline for those signatures. Database initialization mode uses the policy file to go through and collect signatures. It uses default values from the config file unless you specify other values on the command line. The following command line launches the database initialization mode:
# tripwire -m i -v
The -m option is used to specify the mode ( -m i indicates database initialization mode). You are asked to enter your local passphrase to access the database, and then Tripwire will take several minutes to examine your files, constructing a database of file signatures. The -v option is used to show progress. Once the database has been created, it is saved in a binary Tripwire Database (.twd) file, writable only by root (usually in /var/lib/tripwire) and encrypted with your local key. The file can be read only by using the twprint command, which is executable only by root. You'll want to make sure that the file and directory permissions on the Tripwire data directories (/etc/tripwire and /var/lib/tripwire by default) prevent other users on your system from viewing or modifying your Tripwire files.
Integrity Checking Mode This is the normal mode of operation for Tripwire. It scans the files on the system looking for any policy violations. Violation reports are stored in the location defined by the REPORTFILE variable in tw.cfg, which is /var/lib/tripwire/report/ by default.
Several options can accompany this command. You can specify alternative file locations for policies, configurations, databases, and reports. You can turn on interactive mode ( -I ), which opens a plain-text version of the report using the default editor after scanning has completed. To keep your reports encrypted, specify the -E option to prompt you for your local passphrase. You can also deviate from the policy by ignoring certain properties ( -i ), checking only certain severity levels ( -l ), checking only for a specific rule by its name ( -R ), or checking only specific files. For example, if we were concerned only with the integrity of the ls command, we could issue this command:
# tripwire -m c -v /bin/ls
Here we're specifying integrity check mode ( -m c ) with verbosity turned on ( -v ). If we don't specify a file at the end of the command, Tripwire checks all files in the database, which is the default. Here it checks only the file /bin/ls.
The following command has Tripwire check only files with a high severity level (above 100):
# tripwire -m c -v -l 100
Severity levels and rule names can be defined in the Tripwire policy file. The i , -l , and R options will make more sense after reading the "Understanding Tripwire Policy Files" section.
| Tip | After generating a report file (which has a .twr extension), you can view it in plain text after the fact using the twprint utility. In fact, you can use twprint to print plain-text output of a Tripwire database (.twd) as well. By default, only the root user can run the twprint utility, which ensures that regular users can't view the contents of those databases and reports. |
After your database has been set up and you're ready to start running regular integrity checks, you can set up a cron job to run Tripwire nightly, weekly, or whenever you like.
Database Update Mode If a file changes and that change is legitimate, you'll need to update the database to keep that change from being continually reported as a violation. To use this mode ( -m u ), you need to find your most recent report file and specify it on the command line using the -r option:
# tripwire -m u -r /var/lib/tripwire/report/host-20030820-235028.twr
This will bring up a text file of the report in your default text editor, which contains a great deal of information about the scan. It will show you each rule name from your policy, the severity, and how many affected rules detected changes.
If you scroll down to the Object Summary section of the report, you'll see what are called ballot boxes for any changes that occurred between the last database update and the last integrity check:
---------Rule Name: Tripwire Data Files (/var/lib/tripwire) Severity Level: 100 ---------Remove the "x" from the adjacent box to prevent updating the database with the new values for this object. Added: [x] "/var/lib/tripwire/originix.twd"
If you leave the x intact, the database will be updated with the change and this will not be reported in future integrity checks. If you remove the x , you're indicating that this is an undesired change and that the database should remain unchanged.
After you've exited the editor, Tripwire will ask for your local passphrase to allow it to update the database if any database changes have been made. You may also choose to accept all changes without previewing them first by specifying the -a option at the end of the command.
Policy Update Mode As you learn more about Tripwire and receive more and more violations that should be considered false positives, you'll want to toy around with your policy. The following command tells Tripwire to update the default policy file to become the new policy outlined by newpolicy.txt:
# tripwire -m p newpolicy.txt
After updating the policy, the database will be updated against the new policy. Again, you'll need your site and local passphrases to be able to access and modify the policy file and database.
We will discuss creating Tripwire policies shortly in "Understanding Tripwire Policy Files."
Other Tripwire Utilities
Tripwire comes with a few other utilities: twprint, twadmin, and siggen.
Twprint As mentioned, twprint has two operating modes: it can be used to print either report files ( -m r ) or database files ( -m d ) in plain text.
Twadmin Twadmin is an administrative front end for creating and viewing configuration files, creating and viewing policy files, adding and removing encryption to files, and generating new encryption keys.
| Caution | You should never use twadmin to create a policy file after an initial policy file has already been installed. Doing so will cause the policy and the database to become out of sync. If you have a policy text file you want to import into Tripwire, use the update policy mode of the Tripwire application (that is, tripwire -m p newpolicy.txt ). |
Siggen The siggen utility can be used to display the hash signatures of any file. These hashes are the signatures used by Tripwire for file content comparison and analysis. The hash formats that are supported by Tripwire are Haval, SHA/SHS, MD5, and CRC32.
Understanding Tripwire Policy Files
The policy file tells Tripwire what it should and shouldn't look for. It is usually encrypted and in binary format, but you can run the command twadmin m p > current-policy.txt to save Tripwire's current binary policy file to a clear-text policy file that you can edit. The syntax of a clear-text policy file can be extremely difficult to understand. It contains variable definitions and rule definitions. Each rule consists of two main parts : a filename or directory name and a property mask. Here is part of an example policy file:
/bin/login -> $(SEC_CRIT) ; /bin/ls -> $(SEC_CRIT) ; /bin/mail -> $(SEC_CRIT) ; /bin/more -> $(SEC_CRIT) ; /bin/mt -> $(SEC_CRIT) ; /bin/mv -> $(SEC_CRIT) ;
Notice how the filename or object name is separated from the property mask by a -> token. SEC_CRIT is a variable defined in the beginning of the file that refers to a valid property mask. Also note that each rule ends with a semicolon ( ; ).
Valid Property Masks Tripwire masks control which properties are watched on each file. Properties preceded by a plus sign ( + ) are watched, while properties preceded by a minus sign ( - ) are ignored. Properties that have no preceding sign are assumed to be watched, in which case all properties that aren't included on the command line are ignored. Table 12-3 shows a description of each of the properties.
| Property | Description |
|---|---|
| A | Last access time |
| B | Blocks allocated |
| C | Create/modify time |
| d | Device ID on which inode resides |
| g | Group ID of the file owner |
| i | Inode number |
| l | File is allowed to grow (good for anything in /var/log) |
| m | Modification timestamp |
| n | Inode reference count (number of links) |
| p | Read/write/execute permissions on the file and mode (setuid, setgid) |
| r | Device ID pointed to by inode (for devices only, i.e., /dev) |
| s | File size |
| t | File type (i.e., text, data, executable) |
| u | User ID of the file owner |
| C | CRC32 hash |
| H | Haval hash |
| M | MD5 hash |
| S | SHA/SHS hash |
| Tip | The i option of the Tripwire integrity check mode ( -m c ) is used to ignore certain properties when performing its check. For example, running the command tripwire m c i "p,s,u" tells Tripwire to perform an integrity check on all files but to ignore any changes to permissions, file size, or user ID of the owner. |
If all you cared about watching was the MD5 hash, file size, permissions, and user/group owners of a file, you would define a rule like this:
/home/myfile -> Mspug
This could also be written like this:
/home/myfile -> +Mspug-abcdilmnrtCHS
To make life easier, Tripwire comes with a few predefined variables that can be used for property masks. These are shown in Table 12-4.
| Variable | Value | Description |
|---|---|---|
| ReadOnly | +pinugtsdbmCM-rlacSH | Watch permissions, inode, inode reference, ownership, file type, file size, device ID, blocks used, modification timestamp, and CRC32 and MD5 hashes. Good for files that shouldn't be changing. |
| Dynamic | +pinugtd-srlbamcCMSH | Watch permissions, inode, inode reference, ownership, file type, and device ID. Don't watch size, timestamps, or hashes. |
| Growing | +pinugtdl-srbamcCMSH | Watch everything for Dynamic but make sure the file is always growing as well. If the file using this property mask suddenly gets smaller, Tripwire will bring it to your attention. Good for logfiles. |
| Device | +pugsdr-intlbamcCMSH | Watch permissions, ownership, file size, device ID and the device the inode points to. Good for device files. |
| IgnoreAll | -pinugtsdrlbamcCMSH | Watch only the presence of the file, none of its properties. |
| IgnoreNone | +pinugtsdrlbamcCMSH | Watch all of the properties of the file. |
You can also define your own property mask variables in the policy file. Remember the SEC_CRIT variable we mentioned at the beginning of this section? SEC_CRIT represents a property mask and is defined as follows :
SEC_CRIT = $(IgnoreNone)-SHa
Any rules that use the SEC_CRIT property mask will watch every property except for SHA hash, Haval hash, and last access time.
Some sensible rule definitions using property mask variables might look like this:
/var/log/messages -> $(Growing); /dev/fd0 -> $(Device); /home/jdoe/.netscape -> $(IgnoreAll); /etc/inetd.conf -> $(ReadOnly);
Rule Attributes Rule attributes can be provided to individual rules or groups of rules, as defined in Table 12-5.
| Rule Attribute | Description |
|---|---|
| rulename | Assigns this meaningful name to a rule or group of rules. Helps in subdividing your rules and making it easier to understand when viewing report summaries from integrity checks. |
| emailto | If Tripwire's integrity check is running with the |
| email-report | option, whenever a rule with this attribute is triggered, an e-mail will be sent to the list of e-mail addresses to follow. Multiple e-mail addresses should be separated by semicolons and surrounded by double quotes. |
| severity | Assigns a level of severity to a rule or group of rules. Values can range from 0 to 1,000,000. This lets you use Tripwire to scan for only certain severity levels of rule violations. You can assign meaningful variable names to severity levels (i.e., medium=50 ). |
| recurse | Tells Tripwire whether it should scan all subdirectories of a directory (a value of true ), whether it should not scan into any subdirectories (a value of false ), or whether it should only scan a certain depth of subdirectories (a numeric value). |
Individual rules can be given attributes by appending them in parentheses at the end of the line, before the semicolon. Groups of rules can be given attributes by including the attributes in parentheses first , followed by the rules to be affected by these attributes in brackets. Following are some sample rules from a policy file:
/var/log/messages -> $(Growing) (rulename = Log, severity = 10); /etc -> $(ReadOnly)(rulename = Etc, recurse = 2); (rulename = Bin, severity = 100, recurse = false, emailto="root;gabriel@home") { /bin/cat -> $(IgnoreNone)-SHa ; /bin/date -> $(IgnoreNone)-SHa ; /bin/dd -> $(IgnoreNone)-SHa ; /bin/df -> $(IgnoreNone)-SHa ; } We've set up a rule called "Log" with a severity level of 10 for the file /var/log/messages. It uses a property mask of Growing, which indicates that Tripwire is checking such things as ownership, permission, and size for changes. The "Etc" rule uses the recurse attribute to tell Tripwire to go only two directories deep when running integrity checks on files and to use the ReadOnly property mask. Finally, the "Bin" rule groups several checks together with a severity of 100. The rule checks four important Unix applications for all property changes except SHA hash, Haval hash, and last access time. If any of these checks discover a property change, both root on the localhost and gabriel@home are e-mailed.
| Tip | Remember the R flag from the Tripwire integrity check mode ( -m c )? You could use this option to have Tripwire check only a certain policy rule name. For example, the command tripwire m c R Bin could be used if we wanted to execute only the checks in rule "Bin." |
Special Rules: Stop Points If you want to scan a directory but skip over certain files, you can use special rules called stop points to ignore those files. Stop points are simply file or directory names preceded by an exclamation point:
/etc -> $(ReadOnly); !/etc/dhcpd.leases; !/etc/motd;
This rule says to make sure everything in the /etc directory is read-only except for the files /etc/dhcpd.leases and /etc/motd.
Directives Finally, the policy file may contain directives that allow you to print diagnostic messages when certain parts in the policy are reached as well as test for certain host conditions. The idea is to allow a single policy file to be used on multiple different Tripwire platforms and OSs. This becomes useful when you consider some of the advantages of the commercial Tripwire version, which are discussed shortly in the "Implementation: The Commercial Edition" section. The available directives are listed here.
-
@@section Begin a new section of the file. This directive can be followed by an argument: FS, NTFS, or NTREG. For the Open Source version, we only care about FS (for Unix file system) sections. NTFS and NTREG sections of the file are used by the commercial Tripwire for watching specific NTFS (NT File System) or Windows registry properties (using different property masks, which will be covered later in the "Editing Policy Files to Support Multiple OSs" section). This allows you to use a single policy file for your entire network. If no argument is specified after the section directive, FS is assumed. There is no need to end a section, as Tripwire will just look for the next section directive and interpret it as the end of the previous section.
-
@@ifhost, @@else, @@endif These directives can be used for host-specific sections of a file. Unlike section directives, @@ifhost directives need to be ended with @@endif directives. This allows you to run a ruleset against only a single host or group of hosts by using something similar to the following: @@ifhost originix badman # define rules for only hosts originix and badman here @@endif
-
@@print, @@error These directives are used to print debugging messages from within the policy file. @@print simply prints to standard output, but @@error will print as well as cause Tripwire to exit abnormally. The following example tells Tripwire to complain if we try to check host cauliflower because we haven't defined any rules for cauliflower yet.
@@ifhost cauliflower @@error "We haven't written any policy rules for host cauliflower yet" @@endif
-
@@end This directive signifies the end of the policy file. Tripwire stops reading the file when it reaches this point.
Using a New Policy File After you've modified or built a new policy file (let's call it newpolicy.txt), use the command tripwire -m p newpolicy.txt to make Tripwire use your new policy and update its signature database accordingly .
Implementation: The Commercial Edition
The commercial edition of Tripwire works in the same way as the open-source version. The applications and file formats are all identical. However, commercial versions are available for nearly every operating system in the workplace, including Windows NT, Windows 2000, Solaris, and others. The big advantage that the commercial edition has over the open-source edition, other than support for more operating systems, is the addition of the twagent utility. The twagent utility allows Tripwire servers to be managed over the network via an SSL connection. The name of this management software is called Tripwire Manager, and it is available for Windows NT, Windows 2000, Solaris, and Linux.
Using Tripwire Manager
Tripwire Manager, shown in Figure 12-10, talks to each individual commercial Tripwire server through the twagent utility. This allows you to deploy Tripwire servers and update policies and databases from a single, central location.
Figure 12-10: Manage multiple agents .
On Windows boxes, twagent runs as a service and can be started and stopped from the Control Panel or Administrative Tools. On Unix boxes, twagent is just another command-line program. You can start and stop it using twagent start and twagent stop .
Adding a Tripwire Server After you've installed Tripwire Server on a machine and have the twagent service running, that machine becomes a Tripwire node. You can add the node to Tripwire Manager in the Tripwire Manager main screen by choosing Manager Add Machines to open the Add Machines dialog box shown in the upcoming illustration. Here you specify the node's IP address and the port on which twagent is listening. You can also group machines together into named groups. When you're finished adding nodes, click the OK button. You'll be prompted to enter the passphrases for the Tripwire Manager console (set when you install Tripwire Manager) as well as the site and local passphrases for the Tripwire node you are adding. Once you have finished this step, the nodes will be registered with Tripwire Manager. All communications between Tripwire Manager and its registered nodes are encrypted.
You can also import machines from a text file containing comma-separated values by clicking the Import button. A sample import file is shown here, where Agent1 is the node's name, Default Group/Demo is the node's group, 192.168.1.105 is the IP address of the node, 1169 is the TCP port on which the twagent node is running, and s_pwd and l_pwd are the site and local passwords, respectively.
"Agent1","Default Group/Demo","192.168.1.105","1169","Memo","s_pwd","l_pwd"
Editing Policy Files to Support Multiple OSs You can view and modify the policy files for all your Tripwire servers using the Tripwire Manager. Select a machine (agent) from the Machine List at the bottom of the Tripwire main window (you'll need to double-click any parent groups to show your nodes) and click the Edit Policy icon. You'll see a window similar to the one shown in Figure 12-11.
Figure 12-11: Modify policies.
Where older versions of Tripwire Manager simply brought up the Tripwire policy file in a text editor, Tripwire Manager 4 attempts to give you a graphical interface for modifying the policy files. In Figure 12-11, you see the first rule that's highlighted is called Windows. It watches all files in $(WINDOWS), which is defined above as C:\WINNT\, for all the NTFS properties defined in the variable $(ReadOnly) , with the exception of the &write property (last write time for NTFS files). The rule then tells us to ignore the file C:\WINNT\SchedLgU.txt. If we were working with the policy file in text format, this section would look something like this:
@@@section NTFS WINDOWS="C:\WINNT\"; EVAL_EMAIL_TARGET="root@hostname"; (rulename = Windows, severity = 100, recurse = 1, emailto=$(EVAL_EMAIL_TARGET)) { $(WINDOWS) -> $(ReadOnly)-&write; !$(WINDOWS)SchedLgU.txt; } | Note | The $(ReadOnly) predefined variable means different things depending on whether or not you're working with a Unix file system (@@section FS) or a Windows file system (@@section NTFS). Where FS uses single-letter property masks, as shown in Table 12-3, NTFS uses a separate set of property masks beginning with an ampersand, which we'll discuss shortly in Table 12-6. |
| Property | Section | Description |
|---|---|---|
| &archive | NTFS | Status of archive flag (on/off) |
| &readonly | NTFS | Status of read-only flag (on/off) |
| &hidden | NTFS | Status of hidden flag (on/off) |
| &offline | NTFS | Status of offline flag (on/off) |
| &temp | NTFS | Status of temporary flag (on/off) |
| &system | NTFS | Status of system flag (on/off) |
| &directory | NTFS | Status of directory flag (on/off) |
| &access | NTFS | Last access time |
| &write | NTFS & NTREG | Last write time |
| &create | NTFS | Time file was created |
| &size | NTFS | File size |
| &msdosname | NTFS | MS-DOS 8.3 formatted name |
| &compressed | NTFS | NTFS Compressed flag |
| &owner | NTFS & NTREG | File owner SID |
| &group | NTFS & NTREG | File group owner SID |
| &dacl | NTFS & NTREG | Discretionary Access Control Listuser/group rights to the file |
| &sacl | NTFS & NTREG | System Access Control Listuser/group that is "responsible" for the file |
| &sdc | NTFS & NTREG | Security descriptor control |
| &sdsize | NTFS & NTREG | Security descriptor size |
| &sha | NTFS & NTREG | SHA hash |
| &haval | NTFS & NTREG | HAVAL hash |
| &md5 | NTFS & NTREG | MD5 hash |
| &crc32 | NTFS & NTREG | CRC32 hash |
| &strm_count | NTFS | Number of NTFS streams |
| &strm_sha | NTFS | SHA hash of streams |
| &strm_haval | NTFS | HAVAL hash of streams |
| &strm_md5 | NTFS | MD5 hash of streams |
| &strm_crc32 | NTFS | CRC32 hash of streams |
| &classname | NTREG | Name of class |
| &nsubkeys | NTREG | Number of subkeys |
| &maxsubkeyname | NTREG | Maximum length of subkey name |
| &maxclassname | NTREG | Maximum length of class name |
| &nvalues | NTREG | Number of values |
| &maxvaluename | NTREG | Maximum length of value name |
| &maxdatalen | NTREG | Maximum amount of data for any value |
| &datatype | NTREG | Type of registry value data |
| &datalen | NTREG | Length of registry value data |
If you refer back to the "Understanding Tripwire Policy Files" section, you should be able to understand the policy file snippet just shown and see how it relates to the GUI displayed previously in Figure 12-11. The commercial Tripwire doesn't shield you from having to learn the policy file syntax, but Tripwire Manager's GUI makes it easier to write one single policy file for all your different operating systems (using the "@@section" directives discussed earlier). You can then distribute that "global" policy file to all your Tripwire nodes by selecting them all and clicking the Distribute File icon.
You may have noticed a Registry tab in Figure 12-11. Remember when we were talking about the @@section directive and how it took one of three arguments: FS, NTFS, or NTREG? We already covered FS in the "Implementation: The Open-Source Edition" section; rules in an FS section are meant for a Unix file system. We also mentioned that NTFS sections are used to watch particular Windows NTFS properties and NTREG sections are used to watch particular Windows Registry properties. To do this, Tripwire uses property masks different from those in Table 12-3, which are meant only for FS sections. Table 12-6 shows the properties defined in NTFS and NTREG sections.
For example, keeping an eye on a change in the last write time of a file or registry key is different for each section type. The following policy file snippet contains rules for watching the last write time on all three types of sections:
HKLM="HKEY_LOCAL_MACHINE"; @@section FS # Alert if the last modification/write time (m) on /etc/passwd has changed /etc/passwd -> +m; @@section NTFS # Alert if the last write time (&write) on c:\winnt\win.ini has changed C:\WINNT\WIN.INI -> +&write; @@section NTREG # Alert if the last access time (&write) on # \HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce # has changed $(HKLM)\Software\Microsoft\Windows\CurrentVersion\RunOnce -> +&write;
Because the property masks differ between FS, NTFS, and NTREG, the predefined property mask variables such as $(ReadOnly) and $(Dynamic) are different as well. Table 12-7 illustrates what each predefined property mask variable means in the NTFS and NTREG sections.
| Variable | Section | Value |
|---|---|---|
| ReadOnly | NTFS | +&archive &readonly &offline &hidden &system &directory &write &create &size &owner &group &dacl &sacl &sdc &sdsize &crc32 &md5 &strm_crc32 &strm_count &strm_md5 |
| ReadOnly | NTREG | +&owner &group &dacl &sacl &classname &nsubkeys &maxsubkeyname &maxdatalen &maxclassname &nvalues &sdc &sdsize &maxvaluename &datatype &datalen &crc32 &md5 |
| Dynamic | NTFS | +&archive &readonly &offline &temp &hidden &system &create &directory &owner &group &dacl &sacl &sdc &sdsize |
| Dynamic | NTREG | +&owner &group &dacl &sacl &classname &datatype &sdc &sdsize |
| Note | The IgnoreAll and IgnoreNone predefined variables also work as expected for both NTFS and NTREG. |
A Graphical Interface to Tripwire Everything accomplished with the Tripwire open-source version can be accomplished with the commercial version but from a single location and with a point-and-click interface. By selecting all the machines in the list, we can quickly run integrity checks on all servers and view the resulting reports (shown in Figure 12-12), update databases, update policies, and more. Tripwire Manager also has scheduling capabilities so that agents will automatically schedule Tripwire scans, allowing you to control the scans from the Tripwire Manager instead of setting up individual cron jobs or Windows Schedulers.
Figure 12-12: Schedule checks.
Figure 12-12 shows the results of an integrity check run against two Tripwire agents/nodes. Not only does Tripwire Manager make it easier to manage servers, but it creates integrity reports that are much more detailed, thorough, and discernable than its Unix counterpart . Clicking the different tabs (Reports, Objects, Violations, and Summary) lets you view the report in different ways.
| | ||
EAN: 2147483647
Pages: 175