Introduction
The first design of the IMSc Network Topology was based on the premise that most users would connect to the main servers using xterms or vt100 terminals. This changed once many users got proper computers on their desktops.
The current security policy is based on the premise that local machines are properly configured by the system administrator and only machines that are outside the IMSc network could become "hostile".
The current network topology design is based on the above policy together with the desire to minimise the conflict with existing usage of the system as it was in the xterm days.
The changing user scenario.
-
Users are increasingly bringing laptops and other portable devices to the network.
-
Many users want to connect from home without going through the IMSc modem phone lines. Similarly, users who are out-station would like to access the network "as they do from the campus".
-
Users are increasing control over their desktop machines so that the configuration of these machines is outside the control of the system administrator. In particular, such systems could acquire viruses or worms or be "Trojan"-ed.
Goals
The proposed changes should minimise conflict with current utilisation. At the same time we need to ensure that the IMSc systems are available for use in a trustworthy way.
(In what follows the term User refers to an authenticated user.)
A. Users should be able to send and receive mail from their desktop machines or from their home or from out-station locations.
B. Users should be able to log in to IMSc servers from all the above locations.
C. Users from the LAN should be able to access the Internet.
Current Topology
++++++++++ ======== ========= ========================
+INTERNET+----|Router| |Access| |Mail and other servers|
++++++++++ ======== ========= ========================
| | ...... |
--------------------------------------------------------------------
| External Backbone
================
|Firewall(Agni)|
================
| Internal Backbone
--------------------------------------------------------------------
| ........ | | |
======== ========================== ================== |
|Banyan| |Kaveri and other servers| |Desktop Machines| |
======== ========================== ================== |
Internal Backbone |
--------------------------------------------------------------------
| | |
=========== ============ ==============
|PPPServer| |DHCPServer| |WirelessHubs|
=========== ============ ==============
| | | |
===========
| Modems |
===========
Proposed Topology
++++++++++ ======== ===============
+INTERNET+----|Router| |Server zone I|
++++++++++ ======== ===============
| |
--------------------------------------------------------------------
| External Backbone
===================================== ================
|Authenticating/Masquerading gateway|---|Server Zone II|
===================================== ================
| Internal Backbone
--------------------------------------------------------------------
| | | |
=========== ============ ============== ==================
|PPPServer| |DHCPServer| |WirelessHubs| |Desktop Machines|
=========== ============ ============== ==================
| | | |
===========
| Modems |
===========
Detailed Description
Server Zone-I would contain servers that are primarily for users from outside the LAN. Thus the DNS Zone servers, the Mail exchanger, the httpd accelerator and mirrors would reside there.
The Authentication/Masquerading gateway would combine the role of the current agni with that of access2. Connections from the Internet to the internal backbone or server zone II would be denied unless authentication has been obtained. Connections from the internal backbone to the Internet would be masqueraded automatically. Connections to server zone-II would be restricted based on the authentication obtained.
Server Zone-II would contain servers that are primarily for LAN/VPN type usage. This means NFS, backup, Mail spool, Web Hosting, SMTP, IMAP, POP, etc.
Authentication
There are many ways to perform authentication but it is assumed that all users can learn SSH key-based authentication. This authentication will be independent of logins to specific hosts. (However, a user may set up an account to accept the same key for SSH logins).
Once one user is authenticated from a particular host (identified by IP address) all users on that host will obtain access to the forwarding services of the Gateway. Hosts that are not on the LAN will be granted access for a limited time subject to renewed authentication.
Changes required from sysadmin point of view
The Authenticating/Masquerading Firewall will need to be setup.
A Web-based database of passphrase-encrypted private key to be provided for users without access to USB/Floppy/CD/Laptop.
Provide sample "standard" configurations based on bootable CD's which will allow users to remotely access the network after giving the passphrase.
Changes required from user point of view
IMSc Desktop Users will need to generate an ssh key and provide the passphrase to unlock this key after logging in.
For external usage of the network. Users who do not have (or know how to use) a USB/Floppy/CD/Laptop on which to carry their passphrase-encrypted private key can store it on the Web server and download it with a "common" password. Once users have more familiarity with the system they should remove their key from this storage mechanism.
Benefits
While opening up the network to allow greater access to non-local users, this configuration also provides protection to the key services.
The security support mechanism can be limited to the Server Zone-I, Zone-II and the Authenticating/Masquerading Firewall.
Even un-authenticated users on the LAN (such as visitors to the IMSc) will be able to transparently access the internet. Once they authenticate they will also be able to access the Servers in Zone-II.
Known Lacunae
The users must learn a bit about key-based logins. In particular, it is up to the users to ensure that the un-encrypted private key remains private!