In the beginning (Nov 1993), there was a spare Sun3 server.
The Sun3 was some years beyond its original warranty, with no real hope
of timely hardware support from Sun (now Oracle). It had been kept running
partly because it was a complete set of spare parts for an identical Sun3 which was still in active use at the time.
This machine became the first firewall to stand guard for the new
SAP R/3 systems in AMS. It was renamed "filter.utcc.utoronto.ca"
("Filter" for short), and it was loaded up with the open source
"FireWall ToolKit" software (FWTK
[1]
) from Trusted Information Systems (TIS).
One security issue of that day was the vulnerabilty of passwords to
"sniffing". At that point, most network traffic was unencrypted and
anyone with a direct connection to a LAN would have been able to "sniff"
the LAN to watch while a neighbour typed in a password.
The Filter firewall dealt with "password sniffing" by requiring users
to run the open source S/Key
[2]
program to generate a one-time password
for each new connection (once a one-time password is entered, it's no
longer valid so even if it had been "sniffed", it could never be used again).
An initial stumbling block for the Filter firewall was the SAPgui program.
The early SAPgui had not been designed with proxy firewalls in mind.
SAPgui expected to have direct contact with the SAP servers.
To get SAPgui to work with Filter, the FWTK software was modified to
poke around inside the SAPgui data stream
[3]
and replace the SAPgui user's address with the firewall's own address.
This let the SAP server behind the firewall know that it should be
talking back to the proxy firewall, instead of directly to the client.
R3verify:
In 1994, a new version of SAPgui meant the earlier poke+replace firewall
customization no longer worked. But SAPgui users still had to
authenticate themselves to the Filter firewall somehow. The solution
became R3verify
[4]
- an independent adaptable call-back scheme developed
locally, with Mark Acfield writing the Windows and Mac portions using
Visual Basic. R3verify had been designed to handle plain passwords
and S/Key passwords. It would soon handle SecurID passcodes, as well.
Poort, Gaat:
Filter stood guard on its own for the AMS servers until the arrival
( late in 1994 ) of dedicated vendor-supported hardware for firewalling:
Poort and Wachthond (IBM RS6000's running AIX) and Gaat and Ingang (Cisco 4000 routers).
Also arriving on campus in 1994:
SecurID two-factor authentication.
FWTK software had included support for SecurID cards
by way of the SecurID/ACE programming interface
[5].
The last piece of the new AMS gateway was installed in Dec 1994 when
the Gaat router was put into place. Gaat had an X.25 link to SAP Inc
which gave them secure access to provide remote support to AMS's SAP
server software.
Gaat would run until Oct 2015 when it was powered
off with all the other Poort/SecurID-related hardware.
Splash:
By 1998, Rogers "WAVE"
[8]
(Internet over tv-cable) meant it was possible
to access the campus networks from home without having to dial-in and
the SSH program meant it was possible to do so securely.
The Splash firewall was built to allow SSH access to AMS from off-campus.
To connect to the SAP servers, Splash users had to login with SSH and
then point their SAPgui connections through their SSH tunnels
[6].
Splash would later include:
an endpoint for the IPsec VPN that replaced the X.25 link between AMS and SAP (2002)
an OpenVPN gateway that allowed user VPN access to AMS (2005).
Y2K:
By 2000, Poort's hardware (IBM-RS6000) was 5 years old.
It was replaced with a pair of generic Intel servers (Mix and Toss).
The new servers were configured such that one system did all the work
while the other (the "hot spare") was prepared to take over if it
detected that the first system had failed.
Splash was also updated with the same generic Intel hardware.
These would be the generic Intel systems which would end up running
as Poort and Splash until Oct 2015.
RAG:
By 2006, the software license for SecurID on MVS had become expensive.
The RAG firewall (ROSI Authentication Gateway)
was built to allow
SecurID to be used for accessing MVS without having to actually use
SecurID on MVS itself: users were to be authenticated by the RAG
firewall (with its cheaper SecurID software license) and then RAG
would forward the now-authenticated user connections onward to MVS.
As with Poort, RAG was a proxy firewall using FWTK.
In RAG's case, users connected to MVS with TN3270 -- a Telnet terminal
emulator for connection to IBM mainframes. Fortunately, the FWTK
package had included a telnet proxy. But FWTK's Telnet proxy on RAG
had to be very heavily modified in order to achieve its objective
[7]
of handling-and-replacing SecurID passcodes.
RAG's server hardware (a pair of Intel systems: dish + mop) would run
until Nov 2013 when RAG was converted to a VMware virtual machine.
Sep/Oct 2013:
Aladdin's eToken (the replacement for SecurID) begins rolling out on campus in Fall of 2013.
Sep/Oct 2015:
The main SecurID server (Rascal) is disconnected in Septempber.
All other firewall systems (Poort, Splash, CAN, Gaat) are powered off in October having lasted at least three time longer than expected.
FWTK is a proxy firewall package -- in order to connect to servers
behind the firewall, users must connect to the firewall itself and
then the firewall connects to the servers. In 1993, VPNs and
transparent firewalls were not yet available.
SAPgui used/uses its own binary data format. SAPgui communication
streams had to be analyzed byte-by-byte to find the position of the
user address. Fortunately, that address was always to be found in
the same position in the stream so it was possible to use a template
for swapping the user address with the firewall address.
A user on Windows (and later on Mac) would start a "listener" program
just before starting the SAPgui itself. Upon receiving the SAPgui
connection from the user, the firewall would:
try to make a separate connection to the user's listener (call back).
exchange authentication information over the call-back connection.
on successful authentication, forward the user's SAPgui connection to the SAP server.
SecurID/ACE provided Sun4/Sparc-compatible binaries to allow
developers to compile SecurID support into their programs.
However Filter was a Sun3 (Motorola-68020, not Sparc) and the first
Poort was an IBM RS6000. Fortunately, SecurID/ACE also provided API
source code to allow FWTK to be recompiled on Filter+Poort with
SecurID support. This API source would be used again later when
FWTK and SecurID had to be ported to Intel platforms.
Splash users would launch their SSH client with specific port-relays
configured. Splash users would then point their SAPgui connections to
the local side of their SSH connection. The SAPgui traffic would be
encrypted within the SSH connection. When the SAPgui traffic "emerged"
from the tunnel on the Splash side, Splash would forward that traffic
onward to its appropriate destination.
SSH customizations for Splash:
allow for non-local/non-Unix account names.
consult the Poort firewall for user authentication.
(PAM was not widely used at that point).
consult the Poort firewall for user access permissions.
locate username and SecurID passcode in the raw data.
[ there were different TN3270 clients in use (IBM Personal
Communications, Hummingbird, Entire Connect) and each put their
username and passcode data in different locations in the stream ]
authenticate the username using SecurID.
generate a passticket [a REX script]
replace the SecurID passcode with the REX passticket
(ie. edit the TN3270 raw data on-the-fly).