AntiVirus for OpenVMS
issinoho
AV solution on their VMS boxes, or (b) come up with some irrefutable
reasons why this is not required.
I know Sophos do some sort of AV solution, but I'm note sure of (a)
its scope of functionality, (b) how expensive it is.
Can anyone point me as to the best advice I should be giving my client
- my initial thought are that the negligible risk makes the cost of
any work wholly unjustified.
Thoughts welcomed.
VAXman-
Dear Client,
VMS is not a Micro$oft product. Enough said.
--
VAXman- A bored certified VMS kernel mode hacker! VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
Barry Treahy, Jr.
>A client is being forced by its security chappies to (a) implement an
>AV solution on their VMS boxes, or (b) come up with some irrefutable
>reasons why this is not required.
>
>I know Sophos do some sort of AV solution, but I'm note sure of (a)
>its scope of functionality, (b) how expensive it is.
>
>Can anyone point me as to the best advice I should be giving my client
>- my initial thought are that the negligible risk makes the cost of
>any work wholly unjustified.
>
IMHO, you will probably never find any viruses crafted for VMS (maybe a
trojan though), but you may have exploits based on GNU software that was
ported to VMS.
If you store PeeCee or Unix content on your VMS system, you could NFS
mount the VMS volumes from a Unix or Linux system and then file scan
those volumes; We do this for our Unix/Linux systems with TrendMicro's
products, but frankly see no need for VMS since we stopped using VMS as
a PeeCee file server many, many years ago...
Barry
--
Barry Treahy, Jr E-mail: Tre...@MMaz.com
Midwest Microwave Phone: 480/314-1320
Vice President & CIO FAX: 480/661-7028
Hoff Hoffman
:AV solution on their VMS boxes, or (b) come up with some irrefutable
:reasons why this is not required.
You will not find irrefutable reasons, and you and the "security chappies"
will and must have a better knowledge of the local system security
environment and local requirements.
:Can anyone point me as to the best advice I should be giving my client
:- my initial thought are that the negligible risk makes the cost of
:any work wholly unjustified.
Please read the security manual. This is your client, after all, and
thus you are the expect. Accordingly, you should already be familiar
with OpenVMS management and with system security recommendations.
If there are Microsoft Windows data or program files stored on OpenVMS,
for instance, these can be infected -- the infection will not adversely
affect OpenVMS itself or OpenVMS applications. (Sophos can scan for
these infections.) Windows application or data files that can be found
on an Advanced Server share can be infected, obviously.
There have been a few worms for OpenVMS, though I've not seen one in some
years now -- the recommendations in the OpenVMS security manual will
typically lock these worms out, and OpenVMS tends to install itself with
security enabled by default. I am not aware of any OpenVMS virus that
is loose in the field, but these and trojan horses and worms are certainly
conceptually possible.
OpenVMS lacks one of the central infection distribution mechanism found
in Microsoft Windows systems: Olé's ability to invoke arbitrary and
untrusted code, either directly or from within what would normally be
considered a data file. I regularly receive mail containing Windows
virii, and to date have found none that can infect OpenVMS -- I will
regularly open and decode the Windows virii mail messages I receive,
just to see what new vermin is now loose in the wild.
Most common vulnerabilities are internal, of course, and breaches of
OpenVMS are more often caused by outdated patch levels or incorrect
system security settings. In either case, the guidelines for running
an NCSC Class C2 environment (in the security manual) can be very
helpful -- logs, security settings, privileges, etc. I would concentrate
on this area first and before I would look for virii -- assuming there
are no Windows shares configured on the OpenVMS server or cluster, of
course. (If there are shares, then these can be infected. But again,
the infections are hazardous only to the overall system load of serving
the files should the infection "get busy", and obviously to the Windows
systems that are the target.)
I will here discount discussions of other resources that can become
infected -- infected Windows-based DNS servers, for instance, can be
a real problem for any platform using the DNS server, whether or not
the local platform itself is directly infected.
There have been various discussions of virii on OpenVMS over the years.
Please visit the newsgroup archives for details. Also please see the
OpenVMS Frequently Asked Questions (FAQ) section entitled "Are there
any known viruses for OpenVMS?" -- barring a secuity hole found within
OpenVMS, and barring a (better) viral transmission mechanism within
OpenVMS, there are other security-relevent issues that I would concern
myself about (first).
---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com
John Brandon
> AV solution on their VMS boxes, or (b) come up with some irrefutable
> reasons why this is not required.
As previously stated, there are no PC-like viruses on VMS. However that does
not mean that a priveleged user can not create a worm or do some damages. A
secure VMS system requires proper management and maintenance.
> I know Sophos do some sort of AV solution, but I'm note sure of (a)
> its scope of functionality, (b) how expensive it is.
a) We use SOPHOS on our VMS platform. It has a SCAN only functionality, though
there is a provision for a Pathworks interface - which we do not use. The SCAN
allows for ID, disenfect, and deletion of a virus.
b) How cheap is cheap? Losing your data is not cheap.
Contact a sales-rep at www.sophos.com for pricing.
I found it reasonable.
You can also download a trial copy from their site.
> Can anyone point me as to the best advice I should be giving my client
> - my initial thought are that the negligible risk makes the cost of
> any work wholly unjustified.
>
> Thoughts welcomed.
If the VMS site is closed and secure then I would not worry too much about it.
However, as in our VMS environment, we have FTP from UNIX and Win/xx clients to
and from the VMS servers, we extensively use Advanced Server (PW) to allow our
Win/xx clients to access their user directories for purposes of download, file
storage (Word, Excel, documents, etc.), and such. If this is the case, I would
suggest that a virus scanner be used to clean all VMS accounts, PW shares, and
common areas that a Win/xx client has access to.
If you would like to contact me, please do so...
J*o*h*n B*r*a*n*d*o*n
VMS Systems Administrator
firstname.lastn...@dalsemi.com
Bob Ceculski
There are no known viruses for VMS! The following came from ...
http://www.sophos.com/support/faqs/savopenvms.html
1.1. Can my OpenVMS system become infected with a virus?
There are currently no known viruses which infect OpenVMS systems.
However, it is often useful for an OpenVMS system to scan files for
viruses which infect other operating systems.
This may be the case when an OpenVMS system is used
As a file server for PCs and Macs (e.g. Pathworks/Advanced Server).
To provide an ALL-IN-1 file cabinet.
For processing email with attachments (e.g. PMDF).
In addition, Sophos Anti-Virus for OpenVMS installed as an InterCheck
Server can provide on-access logging for client PCs.
-----------------------------------------------------------------------
... in other words, unless you are storing either thru pathworks
or smtp (PMDF) or some other means non-vms (windoze) files, you
could pre-virus scan them on VMS before they get to the windoze
client, otherwise you are JUST WASTING YOUR MONEY, because as
defcon9 proved you can't hack a properly configured VMS box ...
Point Secure has a product it showed at defcon9, but it is for
intrusion detection and not virus scans ... if they don't
understand this, have them read from the point secure site the
defcon9 article in this ...
Bob Ceculski
as I was saying in my previous post, have your security geniuses
read from this about the defcon9 event ...
Larry Kilgallen
> A client is being forced by its security chappies to (a) implement an
> AV solution on their VMS boxes, or (b) come up with some irrefutable
> reasons why this is not required.
Antivirus products for Microsoft are based on scanning for patterns shown
by known viruses. No company to date has issued an Antivirus product for
VMS since nobody has discovered a VMS Virus in the wild.
If you find a VMS Virus, my company will endeavor to build a defense
against it, for a fee. I am sure others here would make a similar
offer.
Until then, Steve Hoffman's notion about reading the security manual
is a good one, and my company already has a product that will check
your security settings :-).
Kerm
against a list of (or all) executibles and record the resulting
checksums. Run CHECKSUM at a later date and compare the two listings.
You can easily detect which files have changed in any way. Wrap a
little DCL around this and you can narrow the list of files you need
to be concerned about. (Assuming you have enough policy and
information) you can then tell whether or not any executible has
changed without authorization.
Alan Winston - SSRL Admin Cmptg Mgr
>AV solution on their VMS boxes, or (b) come up with some irrefutable
>reasons why this is not required.
>
>I know Sophos do some sort of AV solution, but I'm note sure of (a)
>its scope of functionality, (b) how expensive it is.
I won't quote what they quoted me two years ago, but it was more than my
poor little gov/university lab could afford. (They wanted to charge by user
for every user that ever touched the system.)
It was very effective, in conjunction with PMDF, at virus-scanning incoming
messages and doing the right thing with them, and could also have been used
to scan executables that were going to be deployed by Pathworks. It's easy
to automate picking up the virus signature files, and it generally seems to
be a good product.
>
>Can anyone point me as to the best advice I should be giving my client
>- my initial thought are that the negligible risk makes the cost of
>any work wholly unjustified.
There's certainly very little risk of a virus that affects your VMS
installation. Sophos will help you if you're serving files to PCs, whether via
mail, web, or Pathworks/Samba.
-- Alan
--
===============================================================================
Alan Winston --- WIN...@SSRL.SLAC.STANFORD.EDU
Disclaimer: I speak only for myself, not SLAC or SSRL Phone: 650/926-3056
Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA 94025
===============================================================================
Jeff Cameron
d0141774.03081...@posting.google.com, "issinoho"
<issi...@slayme.com> wrote:
» HP OpenVMS PointSecure customer letter
http://h71000.www7.hp.com/openvms/ps_letter.html
» OpenVMS.Compaq.com PDV-Systemse GmbH
http://h71000.www7.hp.com/openvms/brochures/pdv/
» 2/19/03Cernersuccess
http://h71000.www7.hp.com/openvms/brochures/cerner/
These all site that at the 2002 DEF CON 9 Hackers convention, OpenVMS was
declared unhackable.
You can also search the VMS website for virus and anti virus for lots of
good support material.
However there are packages that do antivirus for open VMS but they only
filter out Windows, MAC, and Unix virii.
There is no database of VMS virus for antivirus software to check against,
because there is no history of a VMS virus.
I also remember many years ago (when it was still DEC, before Compaq) at a
DECUS convention in Anaheim, the put a VMS system online, and published a
username and password for a normal user account and challenged anyone to
break in. Nobody suceeded.
When the government wakes up and realizes there must be security standards
for the internet, VMS will be back with a roar!
Nic Clews
>
> A client is being forced by its security chappies to (a) implement an
> AV solution on their VMS boxes, or (b) come up with some irrefutable
> reasons why this is not required.
Ask your customer support centre.
We did (a bit back when we were asked exactly the same thing) and got
two standard documents talking about OpenVMS and being immune to worms
and viruses.
One is titled:
What you should know about HP OpenVMS and Malicious Code
and the other:
Viruses and HP OpenVMS
Each document about worms and viruses respectively.
Ironically, it is the people switching off DECnet and LAT who are making
the problem worse, the inherent reliability of these protocols are being
compromised by a dirty network where anything goes.
--
Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences
nclews at csc dot com
VAXman-
>On 8/19/03 7:39 AM, in article
>d0141774.03081...@posting.google.com, "issinoho"
><issi...@slayme.com> wrote:
>
>> A client is being forced by its security chappies to (a) implement an
>> AV solution on their VMS boxes, or (b) come up with some irrefutable
>> reasons why this is not required.
>>
>> I know Sophos do some sort of AV solution, but I'm note sure of (a)
>> its scope of functionality, (b) how expensive it is.
>>
>> Can anyone point me as to the best advice I should be giving my client
>> - my initial thought are that the negligible risk makes the cost of
>> any work wholly unjustified.
>>
>> Thoughts welcomed.
>
>
>» HP OpenVMS PointSecure customer letter
> http://h71000.www7.hp.com/openvms/ps_letter.html
...and still pushing their "Security Snapshot" which sends security info
in plain test over a TELNET connection (which logs in in plain text too).
Here's what Hoff said on Eisner in the security conference:
Subj: Notefile SECURITY Note 399.19
<<< EISNER::DRA1:[NOTES$LIBRARY]SECURITY.NOTE;1 >>>
-< SECURITY >-
================================================================================
Note 399.19 I'm an auditor - give me all your passwords 19 of 19
EISNER::HOFFMAN "Hoff; OpenVMS Engineering" 19 lines 19-AUG-2003 17:44
--------------------------------------------------------------------------------
Allowing access to backup archives is just as hazardous as allowing
access to the live system SYSUAF is just as hazardous as sending
copies of SYSUAF off-site is just as hazardous as connecting into
the password authentication mechanisms is just as hazardous as an
untrusted privileged user.
Main, Kerry
> >A client is being forced by its security chappies to (a) implement an
AV solution on their VMS boxes, or (b) come up with some irrefutable
reasons why this is not required.
Not really "proof", but rather a pretty good statement of support for
OpenVMS wrt to virus issues from an established Anti-virus company:
+++
http://www.sophos.com/support/faqs/savopenvms.html
" 1.1. Can my OpenVMS system become infected with a virus?
There are currently no known viruses which infect OpenVMS systems.
However, it is often useful for an OpenVMS system to scan files for
viruses which infect other operating systems.
This may be the case when an OpenVMS system is used
- As a file server for PCs and Macs (e.g. Pathworks/Advanced Server).
- To provide an ALL-IN-1 file cabinet.
- For processing email with attachments (e.g. PMDF).
In addition, Sophos Anti-Virus for OpenVMS installed as an InterCheck
Server can provide on-access logging for client PCs."
+++
Regards
Kerry Main
Senior Consultant
Hewlett-Packard (Canada) Co.
Consulting & Integration Services
Voice: 613-592-4660
Fax : 613-591-4477
Email: kerryDOTmain@hpDOTcom
(remove the DOT's and replace with "."'s)
OpenVMS DCL - the original .COM
Peter Weaver
>... Talking about Sophos
> I won't quote what they quoted me two years ago, but it was
more than
> my poor little gov/university lab could afford. (They
wanted to
> charge by user for every user that ever touched the system.)
I do not know if it is still the case, but at one time Sophos
would give you a VMS license if you bought X PC licenses, X PC
licenses were a lot cheaper than one VMS license.
--
Peter Weaver
Weaver Consulting Services Inc.
Canadian VAR for CHARON-VAX
www.weaverconsulting.ca
warren sander
Update: August 2002
Date: March 1991
Hewlett-Packard Company
HP Services
Software Security Response Team (SSRT)
What you should know about HP OpenVMS and Malicious Code
Computer "viruses" have become more widespread recently and have
gained significant publicity not just because of the damage that they may
directly do, but because they point out the ease of which potentially
serious damage could be done. A computer Virus may be referenced as a
special form of "Trojan horse" software. Viruses and Trojans are classified
as "malicious code" software that may perform a useful function, but also
may contain hidden functions that could perform any number of socially
unacceptable acts such as deleting files, creating a denial of service,
creating new user accounts, or displaying bogus information. To date there
have been no confirmed or reported cases of an operable OpenVMS virus.
There have been reports that were verified rather as malicious code.
It should be pointed out that, with few exceptions, reported viruses have
been in the personal computer environment rather than the traditional vendor
developed operating systems. One reason for this is the lack of system
controls in most PC systems to protect programs and data. In a PC, the
typical virus attacks a specific target or object, such as the boot block of
a newly mounted disk, or a particular application or utility. In OpenVMS,
all the obvious points of attack such as the file structure or known system
programs are protected. Thus, a virus has a much harder problem to solve and
this added difficulty makes the virus harder to write and easier to detect
when it tries to propagate. OpenVMS system controls and customers'
organizational and procedural controls on acceptable user behavior on
business computer systems have made the introduction of malicious code more
difficult but certainly not impossible in the traditional computing
environment. HP is aware of the seriousness of computer security and the
need to protect our systems against malicious code.
HP will continue investigating alternatives to protect OpenVMS systems
from malicious code. Through your HP account team, you can be kept informed
of progress.
In the interim, HP provides a Guide to OpenVMS VAX System Security as
part of the OpenVMS documentation set and our Educational Services offers
courses and seminars in OpenVMS Security optimizing the security of computer
systems and networks in general. They also include an overview of how HP
ensures security of information in its product design, and the current tools
and services we offer to help you implement system security. For further
information about implementing anti-virus security measures, contact your HP
Services account team.
ATTACHMENT "A"
RECOMMENDATIONS TO DETER OR DETECT MALICIOUS CODE
o Prohibit the installation of unauthorized computer software
that is in executable (binary) form.
o If public software is to be used, the source code should be
carefully checked for potential, malicious code.
o Public bulletin board software or software from the web are examples
of what should be considered unauthorized software that could harbor
malicious code.
*Note: The degree of checking of all outside software may depend upon
the trust one has in the provider and the resources of the software
provider.
o Ensure compliance with software change control procedures to protect
against an insider's introduction of malicious code.
o Warn your privileged users, e.g. system managers and system
programmers, from executing (or even deleting) potential malicious software.
o Regularly monitor the modification dates of critical software such
as system files.
o Review the User Authorization Files to ensure all entries have been
indeed authorized.
o Check the file protection settings for unauthorized changes or
weaknesses (e.g. World read or write)
o Monitor abnormal system activity or degraded performance that may
indicate a change in the security state.
o Maintain and monitor audit trails and system accounting information
for abnormal patterns.
o Never install unsolicited demo programs.
o Maintain a regular backup strategy for all data.
o Keep backup media secured.
Copyright 2002 Hewlett-Packard Company
Hewlett-Packard Company shall not be liable for technical or editorial
errors or omissions contained herein. The information in this document is
subject to change without notice. Hewlett-Packard Company and the names of
HP products referenced herein are trademarks and/or service marks of
Hewlett-Packard Company. Other product and company names mentioned herein
may be trademarks and/or service marks of their respective owners.
----------------------------------------------------------------------------
-------------------------------------------------
Source: Hewlett-Packard Company
Software Security Response Team (SSRT)
HP Services
Statement date: March 1991, update August 2002
Subject: Viruses and HP OpenVMS
At the present time, the generic name of "virus" includes Trojan horse
programs, worm programs, combinations of these and other malicious code.
To date there have been no confirmed or reported cases of an operable
OpenVMS virus.
In the architecture of OpenVMS the potential points of viral vulnerability
such as common system programs and file structure are protected. This
protection makes the environment difficult to write/execute 'virus like'
functions, and easy to detect 'virus like' replication activities. Also, the
OpenVMS system controls and available controls for organizational,
procedural and user behavior make the introduction of viruses extremely
difficult in this traditional computing environment.
Copyright 2002 Hewlett-Packard Company
Hewlett-Packard Company shall not be liable for technical or editorial
errors or omissions contained herein. The information in this document is
subject to change without notice. Hewlett-Packard Company and the names of
HP products referenced herein are trademarks and/or service marks of
Hewlett-Packard Company. Other product and company names mentioned herein
may be trademarks and/or service marks of their respective owners.
----------------------------------------------------------------------------
------------
"Nic Clews" <sendspamhere@[127.0.0.1]> wrote in message
news:bhv8bi$57s$1...@lore.csc.com...
Mike Bartman
wrote:
>There's an undocumented utility with VMS, CHECKSUM.EXE. Run it
>against a list of (or all) executibles and record the resulting
>checksums. Run CHECKSUM at a later date and compare the two listings.
> You can easily detect which files have changed in any way.
The concept is good, but this implementation is inadequate. The
checksum.exe utility was intended to detect patch level compatibility
for installations, it wasn't intended as a security tool. Some past
crackers have added junk to the end of their changes such that the
checksum as computed by checksum.exe comes out the same...this would
make a hacked file look fine to such a test.
A long time ago at a previous job, I wrote another version of
checksum.exe. It had the same interface, so you could swap one for
the other in a command procedure, but mine did two checksums using two
different polynomials, then combined them in the output value. To get
the same checksum out of the program you'd have to fool both checksum
methods simultaneously. That seemed kind of tricky to me at the time,
but I'm not a math whiz so maybe I was wrong. If anyone knows about
this sort of thing, I'd be happy to talk about it offline.
There is a checksum library function provided with OpenVMS, so writing
a program like mine isn't all that hard, or all that many lines of
code, and it should make a file change monitor a bit more secure...if
you encrypt the file that records the prior checksums, or at least run
a checksum on *it* and ask a human (i.e. you) or some other
trustworthy source to check the records to see if it has been messed
with since the last run.
-- Mike Bartman
----------------------------------------------------------------
To reply via e-mail, remove the 'foolie.' from the address.
I'm getting sick of all the SPAM...
----------------------------------------------------------------
Larry Kilgallen
> A long time ago at a previous job, I wrote another version of
> checksum.exe. It had the same interface, so you could swap one for
> the other in a command procedure, but mine did two checksums using two
> different polynomials, then combined them in the output value. To get
> the same checksum out of the program you'd have to fool both checksum
> methods simultaneously.
LJK/Security lets you substitute your own checksum routine.
> There is a checksum library function provided with OpenVMS, so writing
> a program like mine isn't all that hard, or all that many lines of
> code, and it should make a file change monitor a bit more secure...if
> you encrypt the file that records the prior checksums, or at least run
> a checksum on *it* and ask a human (i.e. you) or some other
> trustworthy source to check the records to see if it has been messed
> with since the last run.
The other approach is to store the file of prior checksums on CDROM.
LJK/Security does _not_ do that (but does store it on another node).
Doc.Cypher
On Wed, 20 Aug 2003, Mike Bartman <om...@foolie.omniphile.com> wrote:
<snip>
>A long time ago at a previous job, I wrote another version of
>checksum.exe. It had the same interface, so you could swap one for
>the other in a command procedure, but mine did two checksums using two
>different polynomials, then combined them in the output value. To get
>the same checksum out of the program you'd have to fool both checksum
>methods simultaneously. That seemed kind of tricky to me at the time,
>but I'm not a math whiz so maybe I was wrong. If anyone knows about
>this sort of thing, I'd be happy to talk about it offline.
Many open source packages are distributed with a detached PGP or GPG
signature. What is actually signed is a hash of the file(s). Hash
functions such as MD5 or SHA can be used easily but modifying a file and
having it produce the same hash is computationally unfeasible. I have
taken the MD5DIGEST.EXE routine out of the WASD web server and used this to
write a list of filenames and hashes to floppy (along with a copy of
MD5DIGEST.EXE).
Doc.
- --
OpenVMS: Eight out of ten hackers prefer *other* operating systems.
[New Key - Get via finger] http://vmsbox.cjb.net
-----BEGIN PGP SIGNATURE-----
Version: N/A
iQEVAwUBP0P9cnzQ2lmQ+jlnAQGN5Af/XBESviEctXDTTqbwGpZ9guCBu91qvVgV
ghFzxncHcQjCybbRYqIC1fW5BVi6uL9Tz0NFMZ4bJcB6XotcubS4v33VFEehkZEb
10QKWdWKXKOUa21kqiXnv8PLznFwih/UP4RdP7Pp2F+NetW0n5keu+cXnjdKrbDc
fgi2LwoVu3i0BVIZy7dMO8Nh2/xiMX32Mb/9QBD6GtvR98MIUgEyKgXw0gXB0rkZ
fEHFsVCEfO3yA4C5M4IOBzLVE3XNAquswL2CLpPatyIivQoASvWkTTzrXT0Ub7zR
Jnh0v36gtOn6hTXfhAkf2xSGgyCOTA4OxCy+M7Nxn1CmgxJkr1p+9w==
=6Mx4
-----END PGP SIGNATURE-----
Mike Bartman
wrote:
You can do that...once CDROMs get invented. I *said* this was in the
distant past, didn't I? The latest from MicroSoft was MS-DOS 3.0 at
the time I wrote that code, and it was running on PC-XTs and PC-ATs.
*I* was using a VAX-8650 and a VAX-11/785 at work, with a VT-320 clone
as a terminal. There were no CD-ROMs, let alone ones that let you
write your own CDs. We had 9-track 1600 bpi mag tapes...and we LIKED
them! :^)
-- Mike "you kids nowadays, just don't know how good you got it...
;^)" Bartman --
Larry Kilgallen
> On 20 Aug 2003 20:52:07 -0500, Kilg...@SpamCop.net (Larry Kilgallen)
> wrote:
>
>>In article <v678kvcgd39mn6mb5...@4ax.com>, Mike Bartman <om...@foolie.omniphile.com> writes:
>>
>>> There is a checksum library function provided with OpenVMS, so writing
>>> a program like mine isn't all that hard, or all that many lines of
>>> code, and it should make a file change monitor a bit more secure...if
>>> you encrypt the file that records the prior checksums, or at least run
>>> a checksum on *it* and ask a human (i.e. you) or some other
>>> trustworthy source to check the records to see if it has been messed
>>> with since the last run.
>>
>>The other approach is to store the file of prior checksums on CDROM.
>
> You can do that...once CDROMs get invented.
Since you said "writing a program like mine" I figured we were talking
about people who would be implementing anew.
Brian Tillman
>AV solution on their VMS boxes, or (b) come up with some irrefutable
>reasons why this is not required.
VMS Mail is not an active agent; i.e. it does not try to execute whatever is
contained in the messages it receives. Also, most users on a properly
configured VMS system have no privilege to modify important system files, so
viruses have no ability to attack. The worst case is that a virus might
alter a user's own files or affect a user's own process. Recovery is easy:
delete the offending program and restore damaged files from backup. There
is no registry in VMS that specifies files to be automatically run at boot
time. That's done by a read-only (to the general user) file that is human
readable and to any modification can be easily seen.
>I know Sophos do some sort of AV solution, but I'm note sure of (a)
>its scope of functionality, (b) how expensive it is.
Sophos' VMS-based antivirus does not scan for VMS-hosted viruses. It scans
for PC-hosted viruses being passed through the VMS system.
--
Brian Tillman Internet: Brian.Tillman at smiths-aerospace dot com
Smiths Aerospace Addresses modified to prevent SPAM.
3290 Patterson Ave. SE, MS 1B3 Replace "at" with "@", "dot" with "."
Grand Rapids, MI 49512-1991
This opinion doesn't represent that of my company
Larry Kilgallen
>>A client is being forced by its security chappies to (a) implement an
>>AV solution on their VMS boxes, or (b) come up with some irrefutable
>>reasons why this is not required.
>
> VMS Mail is not an active agent; i.e. it does not try to execute whatever is
> contained in the messages it receives.
Of course there are viruses that have nothing to do with email,
so any discussion of viruses should address those as well.
(Not that such a discussion would portray VMS in any less stellar terms.