Kapil Hari Paranjape
The author believes that computer and network security can only be achieved with a certain confidence level when worked out in collaboration with numerous other individuals with similar goals. One way to build such a ``web of trust'' is that those interested must declare their interest and start documents such as this one and update it as others point out bugs. Advertisement is thus one goal and a desire to complete my incomplete knowledge is the other.
I provide here some brief antecedents that may be relevant in establishing some trust in my readers. (I believe that other authors of such documents should provide similar details).
I have been involved in setting up computers and networks since 1987 when the first ``personal'' computers were installed in the Tata Institute of Fundamental Research, Mumbai.1 During a one-year sabbatical in 1990-91 at the University of Chicago, I got interested in Operating Systems through the work of R. Stallman on GNU and that of A. Tannenbaum and his MINIX system. On my return to TIFR, I set up a UUCP connection with the main TIFR network to collect mail using Bruce (surname forgotten)'s 386 enhancement of MINIX (which allowed one to run a lot of GNU software); as TIFR moved to TCP/IP this link became a SLIP link which then became an ethernet (thin) link when cables were laid. We experimented with the Linux kernel version 0.11 and 0.12 but only switched to it around version 0.99 in early phase of its release. On moving to the Bangalore Centre of the TIFR in 1993 the SLIP link to the IISc, was set up. A GNU/Linux based network was also set up at the Indian Statistical Institute, Bangalore the next year. Since moving to the IMSc in 1996, I have been an active member of the group that tries to organise and manage the system here.
On the threats side, I missed the first wave of ``Stone'' and other viruses when they hit India, however, we had our share of threats created by ill-trained users removing or damaging software. In collaboration with T. Bhattacharya a partition locking mechanism was set up in 1988-89 that limited the damage caused by users mistakenly editing binaries. However, this system only accentuated the problems when the ``Stone'' virus struck. The first set of serious network threats that I saw were at IMSc. We have had 3 break-ins due to buffer-overflow exploits--I was present on one occasion and due to the presence of mind of the system administrator we avoided an outright attack by switching off the router! On the other two occasions I was again away from IMSc. Due to the people present a complete recovery was made. More recently we were subject to a ping-flood which we again choked off by re-configuring our router.
As a parallel stream, starting with N. Koblitz book and lectures in 1988(?) I got interested in elliptic-curve cryptography. At the TIFR, Bangalore centre I followed this interest to give a course on computing with curves over finite fields. Since then I have tried to read everything on computational algebra and number theory and related cryptography that I can find. I have used PGP since 1990, but switched over to GnuPG not so long ago.
My real ``hat'' is that of an Algebraic Geometer which is the basis for my research career and continues to be my primary interest (I think!).
Based on the dictum
In security as in mathematics ``authority'' is no substitute for competence and personal verification.this document raises questions that a system administrator should introspect on to decide how secure the system is and how its weak points could be strengthened. The questions have a certain paranoia about them will sometimes appear humorously so. This should not detract from the fundamentally serious nature of the exercise.
The three kinds of threat faced by a computer network are (in various guises) data pilferage, data corruption and data flooding/starving (denial of service). The questions posed below should be looked at from the point of view of these threats.
Since the security questions to be examined at the time of installation are different from those that relate to maintaining security, these are separated below.
Some of the questions below may appear to target the assembled computer network as compared with ``branded'' machines. However, closer examination and experience suggests that this is not so.
How sure are we of the the hardware with which we run our systems? Can we think of any reason why the supplier of the hardware would introduce surveillance devices or minor faults in the system which could be exploited? How dependable is the supplier to replace broken or defective equipment?
We should note that the bulk purchase of machines through public tender, which is the routine manner in which large organisations equip themselves for computer networking, is not safe unless the antecedents and the continued dependability of the suppliers is part of the decision making process. Long before computers were on the scene, banks have been broken into because the locksmith had a master key.
Can we examine the hardware, rearrange it, replace it? Do we have the capability (screw-driver compliance)? Can we add hardware from a different vendor (compatibility/interoperability)?
Beware of vendors that tie you in to them for upgrades as they can threaten your financial security. You may be forced to upgrade a working and secure network due to the breakdown of a small piece. In the process of upgrade a ``backdoor'' could be fitted in. This was actually done in the case of the ``upgrade'' of the embassy of the USA in the USSR.
Moving on to maintenance questions, we note some of the questions regarding continued support have already been asked above.
As your organisation becomes more and more dependent on computer networks has it acquired more skills in this area? Do you depend on external sources for locating hardware faults? For fixing them? If your organisation depends critically on external connectivity do you have a back-up arrangement in case of failure of the external link(s)?
The physical security of machines is obviously quite important.
Do you have sufficient checks on who has physical access to the machines in your network--the routers, the servers, the cables? Could surveillance devices pick-up your network activity--do you operate a Faraday Cage? How secure is the power supply to your network? Can you integrate biometric scans into your network if necessary?
How authentic is the software running on your system? Do you have a clear record of every licence/registration number for the software that you purchased? Is the software digitally signed or otherwise authenticated by the manufacturer/writer/distributor? Do you allow users of the system to install their own software? To modify configuration files? For themselves, or for everyone else?
At the time of installation it is important to configure the software well. Once users get used to working around software which is badly configured it is hard to get them to avoid these workarounds.
Do you know exactly which software packages are installed on your system? Which system services are started and run ``by default''? Have you checked the configuration files of all these services? Have you restricted external access to those services that are only required by users within your system? Have you provided sensible defaults so that users can work on your system without workarounds?
Once packages are installed, there would appear to be little required (in a perfect world) by way of maintenance. However, some bugs are always to be found. Moreover, there are always additional features that users may require or demand. Additionally some proprietary software products may not run if certain ``license managers'' are not responding.
Does your software depend on network connectivity to run? When bugs are found how soon are you in a position to upgrade? Do you have access to the means (source code) and the capability to patch in the fix yourself if necessary? If software bugs on one type of hardware are found do you have backup devices that are of a different kind which can step in temporarily? Do you routinely compare the running software and configuration with the one originally installed--along with file system permissions?
For maintenance, it is often necessary for many people to have access to various key system resources. Again, the system administrator may be away or leave. Note especially the last point below which is often ignored and can leave the system exposed when a key system manager is not around.
How often do you change administration passwords? How many people have access to these? Can these be accessed when one or other person is not around? Is access granted on a limited basis (group level or access control lists)? Is there sufficient documentation of the system installation for the system to be re-configured and re-installed if necessary--by someone other than the original installer?
One of the most important functions of a system administrator is to monitor the logs created by various system devices and programs.
Do you have logs for every important system device and program (don't forget routers)? Do you keep detailed logs? Do you keep or generate summary logs? Are these scanned on a regular basis? Do you have log filters that generate warning flags? Do you have a definite protocol to handle such warning flags?
To maintain data security is a major task. Note that the binary files of programs on your system which contain proprietary or otherwise restricted code also fall under the general heading of data.
Do you have adequate facilities for backup? Can users to make their own backups if necessary? Do you implement access control systems using user groups, access control lists of more fine-grained permissions structures? Do you have facilities for users to encrypt their own data? Do you keep file versions automatically? How often do you refresh the storage devices (disks, tapes etc.) on your system? 2
Hardware can only work as well as the software lets itThus users should form an important component of system security. At the time of installation of a computer systems the users to have to be initiated into its use.
Software can only work well when the data is good
The data is useful only when trained users are using it.
Have you provided for adequate training for your users? Are there users who know more about the system than you--are they likely to be useful or hostile? Have you a detailed form of do's and dont's that each user has read and signed before being allowed access to the system? Has each user of the system detailed the kind of use that he/she will make of it?
Since users are often added and removed dynamically, many of the above points apply in the maintenance of the user base as well. In addition, you must reflect on the following.
Do you have a routine expiry procedure for users who are not on the system--including removing files from the system? Do you provide a user guide and other documentation by which new users can familiarise themselves with your system--especially with the security features and the possible weak points? Do you have a mechanism by which users can obtain help and file bug reports? When a user is inconvenienced by a certain security mechanism is he/she likely to come to you for help or will they try to bypass the mechanism?
If one classifies those users who gain deeper knowledge of the system (equal to or better than the system administrator) into two classes, then these must be the malicious (``cracker'') and the useful (``hacker'') types. In both cases it is to the benefit of the system administrator to try to ``win'' these people over as through their input the system can be made secure. Also note that absence of malice and/or absence of knowledge does not mean absence of threat--as I found out when a mornings work of installing software on a DOS machine was wiped out by a user ``accidentally'' formatting the disk.
To an extent the above questions do guide one to base one's security on systems with open architecture (for freedom to modify hardware) and open source (for freedom to modify source). On the other hand this does not mean that one should modify either without knowing what one is doing! Proprietary software and hardware also limits the freedom of the system administrator to give detailed documentation of the system.
This is not to say that GNU/Linux is virus- or bug- proof any more or less than Windows NT or Solaris--currently all types of systems are seen in all types of secure and insecure environments. All that this author can say is that he can assess and defuse security problems faster on the GNU/Linux (or more generally GNU) systems than with any other kind of system--the above paragraph is offered as a justification for this seeming asymmetry.