WZSysGuard is the best UNIX/Linux intrusion detection and file integrity verification software:
<![if !supportLists]>1. <![endif]>It generates fewer false alarms.
<![if !supportLists]>2. <![endif]>It covers more complete set of security sensitive files by default.
<![if !supportLists]>3. <![endif]>It can detect permanent file changes no matter they were made through normal filesystem calls, disk drivers or during maintenance time when the machine was booted from DVD or network.
<![if !supportLists]>4. <![endif]>Its scan reports are more trustworthy than those generated by other similar function software.
<![if !supportLists]>5. <![endif]>It not only detect critical file changes, but also detect
<![if !supportLists]>a. <![endif]>New filesystem mounted.
<![if !supportLists]>b. <![endif]>New network service started.
<![if !supportLists]>c. <![endif]>New setuid program and device file created.
<![if !supportLists]>d. <![endif]>Firewall rule changed.
<![if !supportLists]>e. <![endif]>Routing table changed.
<![if !supportLists]>f. <![endif]>New kernel module loaded.
Based on PriceWaterHouse's research, more than 50% of businesses have been a victim of security breaches. And quite a number of the security breaches were done by internal staff.
Our WZSysGuard has a web based interface so that your system/application/database administrator can avoid to be trapped by a malicious person through a security trap which is very easy to setup on UNIX systems.
WZSysGuard is the world's most trustworthy, most flexible and customizable UNIX/Linux file change detection software, and it contains a very unique UNIX security trap detection module, and also comes with a network ports monitoring module to help you to detect whether your internal mission critical UNIX server has some abnormal network port opened for possible network intrusion.
Compared with those use kernel filesystem interface based file change detection software (like Tripwire enterprise and Cimtrak), though those software could detect file change more instantly, but may not be able to detect some file changes made through non-filesystem interface; in contrast, WZSysGuard uses SHA 384bit checksum verification algorithm, so as long as this algorithm is safe, no content change will be missed by WZSysGuard when that file is covered.
Open source software, like AIDE, because malicious person can download the source code and modify, generate a modified version to replace original, it's simply not trustworthy.
When we say our WZSysGuard is the world's most trustworthy file change detection software, we have reasons for the claim. Think about this question: all this kind of software should be able to detect normal changes to files made by normal users, what about a malicious person which has access to root account and wants to make some change to a file without being detected, does the software you use have a way to prevent that from happening? And is that reliable? You can imagine, with root access, the malicious person could have many ways to hide his/her activities from detected:
<![if !supportLists]>· <![endif]>By directly changing some components of the detection software.
<![if !supportLists]>· <![endif]>By changing/updating the registry to hide the change of the file.
<![if !supportLists]>· <![endif]>By changing system libraries or shell interpreter used by the detection software for changing the behaviour of the software.
WZSysGuard has following security features to make it the world's most trustworthy file change detection software for UNIX/Linux:
WZSysGuard software can be built up as a filesystem image and burnt to CD/DVD, using NFS export from a Linux/X86 machine and mounted on target machine read only.
<![if !supportLists]>· <![endif]>WZSysGuard software is self-contained; commands in it use its own libraries and commands, so even if the malicious person can change system libraries, that still won't affect the behavior of WZSysGuard's commands.
<![if !supportLists]>· <![endif]>Each WZSysGuard's registry file record has an one-way encrypted code, so malicious person can't change it without being detected.
<![if !supportLists]>· <![endif]>Each of the registry files has its own password/passphrase protected checksum verification file, so even root account won't be able to replace a record in registry file without being detected unless he/she also knows the checksum protection password/passphrase.
<![if !supportLists]>· <![endif]>To regenerate or update the registry file, not only root privilege is needed, but also the specific WZSysGuard administration password which is not a system account password, but dedicated to the WZSysGuard.
<![if !supportLists]>· <![endif]>WZSysGuard's file content change verification is using SHA 384bit algorithm, by today's standard, it's safe. And unlike some kernel filesystem interface based file change detection software, for files covered by classes defined in WZSysGuard, any change to them, no matter using which way, can be detected, provided the SHA 384bit is still safe.
<![if !supportLists]>· <![endif]>WZSysGuard provides the best password/pass phrase protection features you can find today.
WZSysGuard now contains a web based security trap detection and possibility verification interface, so should be used by any mission critical UNIX systems as a standard such that before any privileged account logs on to the mission critical system, the security trap detection should be run through the web interface and only when it doesn't find a change, then can log on to the system; otherwise, security staff should be informed and they should use the web interface to verify whether the change can be determined as no harm or need further investigation.
With WZSysGuard, files on the system are divided into classes, the built-in classes include:
<![if !supportLists]>· <![endif]>etc, this class covers files under the /etc/ directory, which is where system and software configuration files stored.
<![if !supportLists]>· <![endif]>dev, this class covers device files on the whole system except in filesystems with nodev mount option set.
<![if !supportLists]>· <![endif]>acl, this class covers all files with extra ACL entries added in addition to the normal UNIX permissions.
<![if !supportLists]>· <![endif]>link, this class covers all symbolic link files under all default system directories.
<![if !supportLists]>· <![endif]>mod, this class covers kernel modules loaded into kernel during normal operation time.
<![if !supportLists]>· <![endif]>hiddenf, this class covers hidden files under UFS/ZFS/VxFS filesystems. Only our WZSysGuard can help you to detect hidden files on UFS/ZFS/VxFS on supported systems.
<![if !supportLists]>· <![endif]>net, this is a specific class, just as an example to show how flexible WZSysGuard is and what you can do with WZSysGuard. This class is not related with files on the system, but is defined to help you to detect possible network penetration. It works by registering the network ports used by the system and applications under a normal situation, and when you run a scan for the class later, it will compare the ports opened at that time with the recorded ports, if there are new ports opened, the report will tell you. With WZSysGuard, the registry file for the net class also has a password protected checksum verification code, so even if the hacker knows about the class and gained root access, the hacker still won't be able to hide his/her suspicious network activity.
<![if !supportLists]>· <![endif]>fs, this class is for checking if there is any change in device used for filesystem mount, mount point, or number of mounted filesystems.
<![if !supportLists]>· <![endif]>prof, this is the class specifically designed for detecting possible security traps. The class covers files which will be executed during login process, and some commonly used commands, and is customizable.
<![if !supportLists]>· <![endif]>suid, this class covers all normal files with setuid and/or setgid bit set except in filesystems with nosuid mount option set.
<![if !supportLists]>· <![endif]>sysf, this class covers regular files which could be found from all default system directories, except /usr and /etc which are covered in other classes.
<![if !supportLists]>· <![endif]>usre, this class covers executable files and library files under /usr, exclude files under /usr/local/lib/wzsg/ which are used by WZSysGuard only.
<![if !supportLists]>· <![endif]>wzsg, this class covers the files /usr/local/lib/wzsg, which is the WZSysGuard software. This class is not active by default, means by default this class is not registered, but if you want to, you can still get it registered by "wzsgreg wzsg" and scaned by "wzsgchk wzsg". This is another example of how flexible WZSysGuard is.
<![if !supportLists]>· <![endif]>usr, inactive by default, covers all regular files under /usr, except files under /usr/share/man, /usr/local/etc/wzsg and /usr/local/lib/wzsg. When you want to activate this class, you need to move the file wzsgfindusr from /usr/local/lib/wzsg/bin to /usr/local/etc/wzsg/, and move /usr/local/lib/wzsg/wzsgfindusre to /usr/local/lib/wzsg/bin.
If you want WZSysGuard to cover some specific important files which are not covered by the above built-in classes or want to cover them in a small class so the scan can be run more frequently without significantly affect the application performance, you can define your own class[es], simply by creating a executable, named as wzsgfindYourClass, to generate the files' path names and put the executable under /usr/local/lib/wzsg/. Done!!! It's just that simple. And to register the files immediately, you can run "wzsgreg YourClass", and scan the files: "wzsgchk YourClass".
Think about this: if a malicious person creates a device file under /var/tmp/ which has the same major:minor number as /dev/kmem and is set permission as 660 with his normal account as a member in the group, could your software detect such threat? Could that software detect such threat without creating much more false alarm? And how easy is the setup and tune of that software to reliably detect all those security threats?
For more detail of security trap, please refer to the "How to setup security trap detection and verification web interface" under the "How To" menu item