AVSS
+ Windows + Internet = AVSS/NET
The AVSS software is based on the
M programming language, database manager, and operating system. M has had multi-user and multi-tasking capabilities in the DOS environment since the mid-1980s. These capabilities facilitate automatic communications between AVSS sites, as, for example, between hospitals and local health departments. The M operating system requires complete control over critical computer resources, such as communications ports, in order to accomplish this goal. The M database manager also requires a dedicated environment to insure its integrity. Traditional AVSS must be installed under DOS 6.22 or in a VAX minicomputer environment. Attempting to run DOS-based AVSS on Windows platforms is not recommended and the AVSS Project does not support this approach. It is now possible however, to run AVSS under Windows using the client-server approach. This product, called AVSS/NET is described below. AVSS/NET requires the following components for each AVSS user site:1. AVSS/NET COMPONENTS
SSH (Secure SHell): SSH is a secure protocol that replaces existing TCP/IP protocols such as Telnet. SSH must be supported by both the client and the server. It provides strong authentication and secure communications over insecure channels. SSH prevents illicit network snooping ("Packet Sniffing"), whereby unencrypted text can be read by unauthorized parties. AVSS/NET uses SSH and three distinct components to efficiently and securely communicate confidential vital records information over the Internet:
Client Workstation: A Windows 2000 workstation that can connect to the Internet via a local ISP or LAN. This "Thin Client" must also have a terminal emulation program capable of supporting SSH communications protocol. SecureCRT is the program used by AVSS/NET. It allows for an encrypted SSH session using a user name and password authentication security and 56 to 256 bit triple DES ciphers for session data encryption. Encryption is started before authentication.
Encryption Server: A UNIX computer running SSH. This server provides users with secure login connections, file transfer, and TCP/IP connections over the Internet. It uses cryptographic authentication, automatic session encryption, and integrity protection for all transferred data. RSA is used for key exchange and authentication, and symmetric algorithms for encrypting transferred data. The Encryption Server has two network interfaces, one that connects to the Internet, and a second connects to the AVSS Server directly and uses a private IP address.
AVSS Server: A Windows 2000 server running AVSS for Windows with Telnet support connected to the Encryption Server with a private address.
2. AVSS/NET CONNECTIONS
As shown in the AVSS connection diagram, the AVSS/NET connection process is as follows:
The Client Workstation loads the SSH software (SecureCRT) and tries to make a connection to the Encryption Server. The Encryption Server checks its database to see if the Client Workstation is coming from a trusted source then prompts the Client for authentication. When the Client Workstation successfully connects to the Encryption Server, the Encryption Server then connects to the AVSS Server. The user is then prompted with the traditional Start AVSS? greeting and normal AVSS operations can begin.
3. AVSS/NET BENEFITS
1. Windows-based so that an AVSS workstation can run other applications such as word processing..
2. Obviates the need to have a dedicated telephone line for a modem and the extra space for specialized hardware.
3. Eliminates system management responsibilities such as backups and troubleshooting problems.
4. More reliable and responsive.
5. Obviates the need for annual AVSS updates that usually require site visits.
6. Makes possible more frequent (than annually) updates.
7. Security: AVSS/NET will protect against:
a. Viewing the content and type of communication by anyone other than AVSS/NET users.
b. IP Spoofing, where a remote host sends out packets that pretend to come from another, trusted host.
c. IP source routing, where a host can pretend that an IP packet comes from a trusted host.
d. DNS spoofing, where an attacker forges name server records.
e. Interception of clear text passwords and other data by intermediate hosts.
f. Manipulation of data by persons in control of intermediate hosts.
With respect to security, by placing the AVSS Server in a private network, outside access is locked out. The only way to access the AVSS Server is either directly by means of the AVSS Server console or indirectly by using a SSH Workstation through the Encryption Server, i.e., by using AVSS/NET.
Once connected to the AVSS Server by means of AVSS/NET the user will see the same, familiar interface as before so there is no need for retraining users. DOS-based AVSS is now running on a Windows 2000 platform both at the client and at the server.
4. AVSS/NET FIREWALL (for added security)
Both the Encryption Server and AVSS server sit behind an IP based packet filtering firewall. All incoming and outgoing packets are inspected and analyzed. IP spoofing is prevented by only allowing packets that have identical incoming and outgoing destinations. The firewall also prevents ALL incoming network traffic from directly reaching the AVSS Server; this prevents any type of direct penetration from an untrusted source. The firewall allows only incoming TCP Port 22 for SSH to access the Encryption Server. System logs for the Encryption Servers (there are actually two for redundancy) are sent on a private network to a local Log Server located behind the firewall. The firewall prevents all incoming traffic outside of the AVSS Project subnet from reaching the Log Server. The Log Server collects and analyzes the incoming logs from the Encryption Servers for abnormal activity every five minutes. When abnormal activity is found, the Log Server emails security@avss.ucsb.edu with excerpts from the log files.
Updated September 20, 2002, by RL Williams