Monday through Thursday from 8 AM to 5 PM, and Friday from 8 AM to 3:30 PM.
Our trial licenses last for 30 Days. If for some reason you need an extension, send an email request to firstname.lastname@example.org.
Our product is shipped on a CD (we use Airborne) and is also downloadable from our website.
Please see the Contact page for more information on how you can contact CyberSoft.
Call us during business hours, tell the operator why you are calling and if they are unable to help you on the spot ask to speak to the President of the company.
If you are a sales person and use this ploy to get to the President your company, will be added to a list that we never purchase from. The phone number is 610.825.4748, and we are available between 8:00 A.M. and 5:00 P.M. Eastern Time (Philadelphia, Pennsylvania USA).
Please see the product compatibility page for more information on product compatbility.
There is no easy answer to this question, it is completely dependent upon several factors including your system architecture, configuration, and load. For example, a system with 12 megs of RAM running a light load might execute VSTK very quickly, on the other hand a large system with 1 gig of RAM that is heavily loaded might cause VSTK to excessively swap. The only way to determine your needs is install VSTK and make adjustments from there.
On the other hand the Avatar program contained in VSTK requires enough disk space to create it's database. Since Avatar uses compression this could be anywhere from 40% to 100% of the material to be archived, plus the database overhead. The easiest way to get a guesstimate is to create a tarball of all the files you want Avatar to manage and note the final size of the tarball. This will be close to the maximum size that the Avatar database needs. After you have figured out the maximum size use the UNIX compress command to compress the tarball. Then note the file size. This will be near the minimum size of the Avatar database.
An additional source of system usage is UAD which uses the hard disk for temporary scratch space when recursively decompressing a compound file. Since the amount of disk space is completely dependent upon the file being decomposed this is impossible to predetermined. You can however direct UAD to use scratch space in any partition or drive of your choice this includes network drives.
Finally the VSTK product when installed on a system uses a insignificant amount of disk space, however even this value will change depending upon your system architecture. Other important factors to consider are whether the binaries are stripped or unstripped, if you are dynamically or statically linking the binaries, and finally the size of the virus databases, which can change multiple times in a week.
These steps have worked for users, who in the past have had problems mounting VSTK CD-ROM.
Couple of Notes:
a. DON'T do steps 1. or 2. with a CD already pfs mounted.
b. If you use 'umount' to unmount a pfs mounted CD, you won't be able to remount another CD using pfs_mount. You will have to kill the pfs daemons first.
c. You must follow all the steps each time you want to pfs mount, if you don't, the CD will mount, but won't show up in 'bdf'. Kinda strange.
d. This info came from HP, so please contact them, see the pfs 'man' page if you have problems.
One of three things could be the problem. The first thing to check is that the Node name you supplied to CyberSoft was correct. The second thing to do is check the LICENSE file and make sure the permanent key was copied and pasted correctly. The third thing to check is that the VSTK_HOME environment variable is set to the directory where the LICENSE file is located on the system.
If you are still having problems, please send us the vtest.log file. This file was generated during the install of the VFind Security Toolkit and is located in the vstk directory. If this file does not exist on your system then please execute the vtest program and pipe the results into a file called vtest.log. Then E-mail the vtest.log file to email@example.com along with a description of your problem.
You can install VFind™ into the "cron" system for automatic execution. We suggest you run it every evening. For more information execute the command "man cron".
Remove the -vlist option from your command list. The -vlist option lists all viruses that the program detected without any chevron's and then exits. If you remove that option, the output from your find command will be scanned by VFind™. The recommended use of VFind™ is in conjunction with UAD. See below:
There is a "scripts" directory included with VSTK that gives examples on how to use the tools in conjunction with each other for better performance.
Both UAD and VFind™ write their help output to stderr, not stdout. It was originally implemented this way so the help wouldn't get lost if accidently used in a pipeline, e.g. uad -h ... | vfind. Recent versions of UAD and VFind™ have more and more options, and recently we made sure that the -h option listed all of them, so now the help output is quite long.
Certainly, usage error messages should be written to stderr, this is a UNIX tradition. And some programs only print help on usage if you specify a bad command-line option. I checked a few other programs, GNU make, Perl, and elm -h write to stdout, pgp5 -h writes to stderr. I think that writing to stdout may be best in this case.
Anyway, it is easy enough to pipe stderr to more or less, in csh:
and in sh:
UAD needs to write scratch files when it is rendering. If the file it is rendering is larger than the available amount of space in the default scratch directory (/tmp) then you will receive this message. UAD will automatically recover from this error, skip the "file" that caused the problem and attempt to continue.
There is very little that can crash CIT. One of the few things that will do it is if you run out of disk space. The UAD program will sometimes cause a system to run out of disk space for a short period of time and it is common to use CIT and UAD together. This problem can be resolved by modifying the invoking script to disconnect CIT from UAD. This can be done by breaking the command line so that the output from CIT goes into a file. At the completion of CIT the file is then read into UAD.
Note also that this line from amavis/av/cyber is wrong:
and should be:
On Solaris 6, /tmp mounted on swap does not support files larger than 2 GB. Previously we had looked through the Sun documentation for Solaris 6 large files but did not find any such restriction mentioned.
So that means that your problem should go away by using UAD's -t option to specify a temporary directory other than the default /tmp/. -t /var/tmp may be used, for example, if /var is on a big enough disk partition.
Download the "eicar.com" test virus and a virus signature for the test virus "eicar.vdl" to your target machine from here and execute UAD and VFind as shown to test the sample.
VFind is not linked with any CyberSoft DNS servers; it uses no Name Service calls, it simply uses uname() to get the Node name to check the license. However, VDL update requires the use of DNS in order to contact CyberSoft's update servers.
VFind is not linked with RPC and it does not make any remote procedure calls.
VFind does not use SetUID, it can be run by root or any user, although it will only read and scan those files readable to the user.
No, you don't need more memory. Every time you start a copy of VFind, machine memory is allocated to it's use. If you run 4 or 5 copies of VFind at the same time, then this will impede the performance of your machine unless you have a large amount of memory. If you need to run multiple copies of VFind, then it is recommended that you upgrade to the Turbo version of whatever toolkit you are using. VFind is single-threaded; it can only do one thing at a time. The Turbo upgrade with the VFind Daemon is multi-threaded; it not only makes VFind able to do more than one thing at a time, but it greatly reduces start-up memory usage because your system is only starting one program.
When running vfind as a non-root user, you should use the flag--vdl-data-file, with a filename somewhere where you have write permission, e.g. vfind --vdl-data-file="$HOME/vdl.dat". This way you won't have any permissions problems when the VDLs are updated.
The vtest program has no command line options. It is normally run at the command line for the purpose of "testing" the system to insure it is ready to run the VFind Security Tool Kit. It will report on:
1. The nodename of the system. This is needed to make an activation key.
2. The number of characters in the nodename. This is necessary because sometimes people use nonvisable characters before or after the nodename.
3. Test to see if the environment variable $VSTK_HOME is set.
4. The location of a valid activation key.
Here is an example of what running a vtest program looks like:
Macintosh:programs peterradatti$ ./vtest
##==> Nodename is Macintosh.local with length of 15
##==> System Date -- Year: 2009 Month: 5 Day: 13 12:23:05
##==> SECURITY: $VSTK_HOME not defined; searching for alternate location.
##==> SECURITY: /LICENSE not found; searching for alternate.
##==> SECURITY: /etc/LICENSE not found; searching for alternate.
##==>>> SECURITY: ./LICENSE not found; no alternate available.
There are a number of possible causes for this error. The most common causes include:
Use the following instructions:
VSTK164 and later customers
A script is provided with VSTK that downloads virus definition updates from www.cybersoft.com and installs the updates. The script, $VSTK_HOME/bin/vdlupdate, requires that the system on which it is installed has access to the internet.
An entry for vdlupdate can be added to crontab to automatically run vdlupdate every day. The $VSTK_HOME/example_scripts/cron_vdlupdate.sh script can be used to add an entry for vdlupdate to crontab. cron_vdlupdate.sh can be editted to set the time of day for performing the update.
These files are used by our automated virus definition update script. The file update.list contains a line with the base name of the tar.Z file with the updated virus definitions and the MD5 sum of that tar.Z file. For example, update.list might contain the line
From this, the update script knows to download vfind13-2005-09-14-10-36-06.tar.Z and after the file is downloaded, it should have the MD5 sum of 2d33d51127b6587aa4782cc6cf3e92b9.
The file update.md5 contains the MD5 sum of the update.list file so that the update script can verify that the update.list file was downloaded correctly and has not been tampered with.
This is normally good. An empty E-mail message means that VFind™ found no viruses and has no messages for you. (Assuming that the message only contains the output of a grep). If you are not comfortable with this, you can force the E-mail to contain a message by modifying the script. Here is an example that you can customize:
There are two big things you can do. The first is to understand that there is a processor load and wall clock cost to the startup of VFind. VFind has to build trees and initialize all of it's engines prior to scanning. If you start VFind for every E-mail message then you are using a large amount of startup overhead for scanning a small amount of data. The answer is to start up VFind and allow it to run in background. There are two easy ways of doing this. The first is to make a daemon process out of VFind/UAD. See above for an easy way to make a VFind daemon using scripts. The second way is to use the SmartScan communication system to talk with VFind. See the white paper on SmartScan (link to old site).
An additional step that will greatly increase the speed at which you can scan E-mail is to start more than one copy of VFind. Your right to use license allows you to start more than one copy on the same licensed system and the products were technically created to not interfere with multiple running copies. There is a great (very) technical white paper by Dr. Rick Perry on optimal queue theory for virus scanning of E-mail. His white paper was actually written using VFind/UAD and the SafeInternetEmail system. You can read his white paper here (link to old site).
VFind correctly identifies all versions of the Bugbear virus. The problem is with the AMaViS system. We suggest that you use the UAD tool with VFind even though the AMaViS system duplicates some of the functions of the UAD tool. In this case we believe that AMaViS is not correctly breaking down the E-mail message thereby passing a still encoded virus attachment to the VFind virus scanner. UAD solves this problem. Oct. 2002.
There are several ways to interface VSTK with E-mail. Whatever way you choose you must be careful not to infringe on any patents. The following is a discussion of the technical means to accomplish this goal. You need to determine for yourself if it infringes any patents or rights in your specific country/local.
The sendmail people have developed an interface that allows you to directly process E-mail for virus scanning from within sendmail. This interface is called libmilter. There is already a lot of free code available using libmilter and milters that can be adapted for use with VSTK. A good place to start looking at these programs is www.sendmail.org.
You can also purchase a product called PerlMx that makes using libmilter with VSTK easy. Take a look at ActiveState
If you decide to write your own libmilter interface be sure to call CyberSoft for technical support.
The AMaVis Mail Virus Scanner is available free from www.amavis.org and works with the VSTK. If you choose to use AMaViS then contact CyberSoft for technical support since the default VFind command string recommended by the AMaViS development group does not take full advantage of the features provided by VFind and UAD.
SOLUTION-3 BOURNE SHELL SCRIPTS
To see what you could do on your own using just Bourne shell scripts and VSTK take a look at SafeInternetEmail. This service was created using just the VFind and UAD tools of VSTK. They were interfaced to sendmail using Bourne shell scripts and one change to the sendmailconfig.cf control file.
SOLUTION-4 DIRECT INTERFACE TO SENDMAIL
A third option is to write a direct interface to sendmail that does what you want. Several companies have done this since there is significant benefits that can be built in such as translation to X.400. Again, we have published software code segments to make this easy to do. Look at the SmartScan white paper.
SOLUTION-5 NETWORK TRAFFIC INTERCEPTER
The Network Traffic Intercepter. (NTI), is included with VSTKCW but not with VSTK or VSTKP. You can upgrade to VSTKCW in order to get the NTI program. Call CyberSoft for pricing.
The NTI system provides real time scanning of all selected tcp/ip and UDP ports. It can scan all E-mail (port 25, pop3 and imap). It can also be used to scan http, ftp and telnet sessions.
NTI is not supported on all system but is currently supported on Sun Solaris 2.5.1 and above and HPUX 11.0 and above. It is also support under Microsoft Windows NT. For more information on NTI, read the Network Traffic Interceptor whitepaper.
SOLUTION-6 CONTRACT OUT THE PROBLEM
Your fifth option is to contract out the problem to us or others. Look at the SafeInternetEmail service. We can install this product as a service on your mail servers in your data center or even supply systems.
CyberSoft includes all supported UNIX platforms on the VSTK/P CD-ROM.
The most important thing to remember is that VSTK/P is locked to a server by Node name. If you are not violating your license agreement then all you should have to do is insure that your new server has the same Node name as the old server. First remove the VSTK/P from the old server, while saving the LICENSE file, then reinstall VSTK/P from the CD-ROM on to the new server. Then copy the LICENSE file to the new machine. After all these steps are completed everything should work fine.
If for some reason you are unable to keep the same Node name then contact CyberSoft and for a small fee we will generated a new LICENSE key.
If you are running the same operating system and keep the Node name the same then VFind should continue to run without interruption. If you upgrade the operating system it should continue to operate but that cannot be determined since it is under the control of the operating system manufacturer.
You can upgrade to the latest version of VSTK for free if your maintenance and support contract is up to date.
If your maintenance and support has expired you will need to bring it up to date before you will be able to update your version of VSTK.
You can contact CyberSoft or your dealer and request a new temporary key, or, if you purchased the product you can apply for a Permanent Activation key by sending an email to firstname.lastname@example.org.