![[Comments]](/g/comments.gif){kind=small}
![[Search]](/g/search.gif){kind=small}
![[Home]](/g/home.gif){kind=small}
Thursday, December 4, 1997, 10:00
a.m. How to Catch Bad People Doing Bad
Things: Network and Computer Security in Mobile, Distributed Environments Kathleen Kimball, Computer Network
and Information Security Officer, and Andrew Walls, Commonwealth College Technology
Coordinator, Pennsylvania State University An integrated security approach provides
comprehensive, overlapping user authentication, and tracking throughout a highly
distributed twenty-campus system. Two overlapping security systems offer secure
Internet access for users with dedicated desktop systems and/or mobile, laptop
systems. Both systems work with a centralized Kerberos server, and can be applied
in any size higher education institution or corporate environment. --------------------------------- I. The Problem and the Goal A. The Rise in Security Incidents
In the last five years there has been an enormous surge in security incidents on the Internet. These incidents include email harassment, physical threats in email, email forgery, denial of service attacks, and outright intrusion into secure systems. We currently see an average of three such incidents every day within the Pennsylvania State University (PSU) system.
The majority of these incidents involves unsophisticated uses of the network and can be resolved quickly if we can identify the perpetrator. In order to resolve security incidents we need to know the identity of the person who initiated the incident, regardless of the physical location or computer platform employed by the user. Identification of the user at the root of an incident is best achieved through a rigorous system of user authentication.
There is another class of security incidents that do not involve the network. These incidents involve attacks on a local machine such as a desktop machine in a student lab. Malicious reconfiguration of screen savers, application software, etc. do not have an adverse impact on the network, but do consume university resources that could be more profitably employed elsewhere.
It should be noted that user authentication is not a panacea. It is possible to successfully forge another user's identity or to steal an ID and password. A comprehensive system of user authentication will, however, greatly diminish the total number of incidents and provide tracking data on many incidents.
B. User authentication
Although basic user authentication does not ensure that the userid involved was owned by the person who caused the incident, it gives us a place to start. With un-authenticated network access, we have no idea of who might have been involved in an incident. A successful user authentication system depends on the existence of unique IDs for every user and a method for generating, maintaining, and transmitting passwords in a secure fashion.
C. Security Incident logging
An essential component in network security is the network server logs. By keeping log files of user authentication, network traffic, dial-up sessions, etc. we can build an audit trail for investigating incidents. In order to be useful, these logs should be maintained for a substantial period of time (e.g., for as long as two or more years) and be readily available to the Network Security Organization.
Our networks house a multitude of servers and routers, all of which generate some form of log file. Although some of these logs are maintained in a central location, many are kept by disparate departments spread across the state of Pennsylvania. Assembling all of the logs involved in an incident can take a lot of time and effort.
This organizational stumbling block is exacerbated by the lag time inherent in wide ranging security incidents. It is not uncommon for another institution to contact us concerning an incident many months in the past. As noted above, in order to be useful, the logs may well need to be maintained for 2 years or more. Exact duration and format of log storage is a decision that each institution needs to define when crafting its security strategy. Busy servers can generate monthly log files in the tens of megabytes. Multiplied by, for example, 24 months and a few hundred servers, storage nightmares can result without effective planning.
II. The Environment
A. Mobile users and desktop systems
PSU's users are located throughout the world and use a wide variety of computer platforms. The users work from desktop systems, laptops, and handheld devices. These users connect to the PSU infrastructure through modems (we operate ~1000 modems), in-house networks, and external networks (the Internet). The University also hosts innumerable departmental Web, FTP, and Gopher servers in addition to DNS, POP, and other system-wide servers.
B. Multi-campus Intranet (shared T1's, no redundancy)
PSU manages information technology in over 24 separate locations across the state of Pennsylvania. These sites are tied into a WAN through T1 lines and SMDS circuits. Although this WAN is in the process of being redesigned , the current infrastructure relies on multiple 'star' configurations and there is no backup or redundant network capacity in many locations. (Redundant links to all locations are planned and will, hopefully, be in place by the end of the current academic year) However, prior to completion of the upgrades, when we experience network outages, (which is relatively rare), a campus may be cut off from the network for a considerable length of time, depending on the specific cause of the failure and the vendor responsible for remedying the fault.
C. Distributed server architecture (NT, Novell, Banyan, AIX)
Within this WAN environment, we operate a large number of LANs utilizing Novell, Banyan-Vines, Token Ring, NT, Appletalk, DECNet, and various types of UNIX. The hosts in these LANs provide a wide variety of services including departmental file servers, application servers, HTTP. FTP. NOTES, Gopher, POP, etc. Various protocols are broadcast over the infrastructure, but TCP/IP is by far the most heavily used. Only TCP/IP and Appletalk are actually natively routed. The remainder that are proprietary/NOS specific operate within the local LAN environment, though some may be tunneled over TCP/IP.
D. Overlapping jurisdictions (CAC, CC, departments)
The University is organized into various administrative groups and academic Colleges. The central Computer & Information Systems (C&IS) group manages the overall infrastructure, administrative and academic computing systems, central email servers, etc. The various colleges and other administrative groups are at liberty to design, implement, and manage their own LANs, servers, and end user equipment. This creates a dynamic computing environment with occasional incompatibilities and overlaps
E. Changing user population
Our user population is becoming increasingly computer literate. Surveys conducted within the Commonwealth College (a 12 campus college) show that the number of entering Freshmen with significant computer experience has more than doubled (22% to 48%) from Fall 1995 to Fall 1997. With this rise in familiarity we have seen a concomitant rise in computer and network use in the student population. Unfortunately, the rate of security incidents has risen at the same time. As more of our students come to the University with greater facility with information technology, there will be a steady increase in the reliance on sophisticated network services and a commensurable need for strong network security.
F. Centralized authentication service (Kerberos) not replicated or distributed
PSU has adopted Kerberos as its primary user authentication architecture. The Kerberos server provides a one-way encrypted password and userid repository. This Kerberos server(s) are maintained centrally, and are not replicated at other campuses. The student computer labs and various other systems at PSU's central campus (to include some College-supported labs) use the Kerberos system to authenticate users prior to enabling regular operation of the computer. In order to implement this system, the central campus labs have been standardized on NT Workstation and the Mac OS. Windows 95 and other environments are not supported without modification, though the code will be made available to Colleges or campuses desiring to implement the necessary changes for their environments. Those campuses for which redundancy and/or operating system environment issues are resolved can adopt the central campus lab authentication solution, and, as noted, some are in the process of migrating to this methodology.
Although the Kerberos system provides excellent user authentication, the PSU WAN makes use of a centralized Kerberos system problematic in a number of locations until network redundancy is fully implemented. If a computer is tied to Kerberos in such a way that the computer will not operate without a successful Kerberos authentication, then a network outage will render the computer inoperable. Although we experience exemplary uptimes on the PSU WAN, we do experience times when the network to a particular campus or group of campuses is down. If we tied these campuses to the centralized Kerberos system for user authentication at the present time, computing resources would be unavailable until the WAN was re-established. Our objective then is to build a user authentication system in the near-term that will work in a distributed environment without reliance on a WAN. The solution must be cost-effective and supportable. It must also facilitate transition to a centrally supported architecture when that becomes practical. Thus, a design goal is compatibility with the central authentication and authorization vision/architecture while still supplying authentication to ALL campuses expeditiously.
III. The Systems
A. The Overview
Three Different systems have been developed to provide user authentication and readily available network logs within the Commonwealth College.
a) A network of NT servers at each campus location with authentication databases for the local student population.
b) An IP-filtering firewall system for authenticating mobile users and user on platforms which cannot be controlled through NT.
c) A periodic collection of server logs from all campuses is written to CD and stored centrally.
B. The NT environment
We did not want to form a single NT domain spread across the entire state for a variety of reasons. Instead, we constructed a central NT server housing encrypted files with campus user authentication data.
The PSU Accounts office generates a single file that includes a list of all registered PSU students, their userid, and a novel, generated password. This password is semi-random and is not intended to be retained. The file is generated on a mainframe system.
This file is encrypted using PGP and FTP'd to the central NT server. The file is subsequently decrypted and read into an Access database system. Once in Access, the data is split into multiple files, one for each campus. These database files are then encrypted with the PGP Key of the appropriate campus technologist and placed in an area of the server reserved for access by the campus technologists.
The local campus technologist connects to the central NT server via direct login, trust relationship, or FTP and copies the file for his or her campus to their local NT server. The campus file is then decrypted and output as a text file in the appropriate format for use with the NT Resource Kit utility ADUSERS.EXE.
Running ADDUSERS.EXE against the text file of user authentication data integrates the data into the Security Administration Management (SAM) database of the local NT domain. It is also possible to automatically join these new student IDs to all appropriate Global and Local groups in the NT domain.
In the student labs all of the Windows desktop systems are configured to force a domain login under NT. If the user does not successfully log into the domain they receive a blank desktop with no functions or are returned to the domain login screen. This effect has been achieved on both NT Workstation systems and Windows 95 machines. We do not currently support legacy systems running earlier versions of Windows.
Weekly updates of the user authentication data with students dropped or added are produced, encrypted, and distributed in a similar fashion. These updates are provided for the first month of each semester.
C. Mobile users and non-windows systems
We cannot control the software configuration on laptop computers owned by students, faculty, or staff. The NT Domain login used in the previous system depends on total control of the OS configuration on the client machine. In order to force user authentication on "un-controlled" machines prior to enabling network access, we integrate an IP Filtering firewall into the LAN design.
The firewall system relies on four components: a KarlBridge IP filtering bridge, a DHCP server, a specially programmed Web server, and the centralized Kerberos authentication system. When a user activates a laptop, Macintosh, or other, uncontrolled system, their system polls the network for a DHCP server. The DHCP server connects with the computer and assigns an IP to the local system. The IP's assigned by the DHCP server are from a restricted pool.
[The KarlBridge is a product of KarlNet of Ohio. They are available on the web at http://www.karlnet.com]
The IP assigned to the computer is restricted from general network access by the KarlBridge. The one IP destination allowed by the firewall is the authentication Web server. As a result, when a mobile user attaches to the network, the only network function they can access is a Web session with the authentication server.
The authentication web server presents a single page to the user. This page requests a userid and password. When this data is submitted by the user, the web server transmits the data to the Kerberos system. In order to safeguard the transmission of this data across the network, the web server operates under Secure Sockets Layer (SSL).
If the Kerberos system verifies the user authentication data, the Web server reprograms the KarlBridge firewall to allow the user to have full access to the network. If the user authentication is unsuccessful, the firewall restriction remains in place.
[The authentication web server is a secure Netscape server running on NT. The software handling the interaction with Kerberos and the multiple KarlBridge's was developed by Chris Sacksteder at PSU's Center for Academic Computing.]
D. Managing the Log files
With the above systems in place we next need to implement a system for managing the plethora of log files we generate. The KarlBridge system generates logs for each firewall and for the web server. These logs are maintained by PSU's Center for Academic Computing within their centralized facilities. The logs for the various NT servers at the campuses are another matter.
In order to provide a central library of server logs and to minimize the storage burden on the individual campuses, we constructed a file transfer and storage system which mirrors the authentication data distribution system.
Every month, participating campuses transfer copies of their log files to the central NT server. These files are then collected into a directory hierarchy and written out to CD. The CD's are kept secure and only made available to the appropriate network security staff. Although CD's are less than ideal, they provide a cheap, high volume storage medium.
IV. System Status
The three systems discussed were inaugurated during this Fall semester. Three campuses currently have Karlbridge firewalls installed and several more are awaiting installation.
The NT authentication environment has been implemented on 6 campuses with 4 planning implementation at the beginning of the Spring semester. A few campuses are waiting until next summer to implement the NT system due to local equipment budgets.
The centralized log storage system is now running and three campuses are participating in the initial testing of the procedure.
V. How the System Works
An Incident Occurs
When an incident is reported, the specific nature of the incident mandates the first step in the tracking process. In the case of email, the detailed headers of the offending message can be examined to show the email ID and originating email server.
Other types of incidents are not as up front about their origins and more work is required checking system logs to find a point of origin or access point for the incident.
Either way, the incident is tracked back to a server which processed the communication. At this point we have an IP for the server, a time stamp indicating when the message was processed, and, possibly, an email ID assigned by the email server. Using this data we examine the server logs to find the transactions involving the incident. The transaction detail from the server logs indicates the next step in the chain: the IP address of the upstream machine that contacted the server. In simple cases, this machine will be the originating machine. In more complex incidents, this could be the first in a string of servers that have been enlisted in committing the incident.
Once the originating machine IP has been identified, we then pull the NT server logs or KarlBridge firewall logs for the appropriate location and time. These logs will then identify the user ID of the person who was logged onto the machine when that machine generated the security incident.
Depending on the nature of the incident, police services may be called in along with student Judicial Affairs. The owner of the implicated user ID is then called in for an interview and presented with the evidence indicating their culpability. In many cases, the person immediately confesses to causing the incident. At times, however, the person implicated denies causing an incident. This may be the truth and their user ID may have been compromised.
When there is a suspicion of a compromised account, the investigation gets very complex. Multiple server logs are reviewed for user logins using the suspect account in an attempt to find logins that could not have been made by the owner of the account. In order to obviate this process, many of our labs have begun videotaping all student labs. These video recordings often pinpoint the person or persons involved in an incident.
V. The Challenges
A. The NT Environment
The NT authentication system produces some interesting challenges. The success of the system is dependent on the local technologist configuring the student lab machines to force a domain login and to prevent machine and network access in the absence of a successful login. Creating and maintaining these configurations requires significant ability with NT.
In order to develop the required skills we are providing regular training in NT administration and are developing job aids and specialized training in lab system configuration.
An unfortunate side effect of the NT environment is that the students must maintain two passwords for a single userid. The local NT password on their campus is maintained separately from the Kerberos passwords used for email access. Although many students change their passwords to be identical on both systems, the existence of multiple passwords is confusing and prone to failure.
Distribution and integration of the user authentication data is labor intensive. It would be preferable to reduce the amount of labor involved in implementing the authentication data.
B. The Log Storage System
As with the NT system, the labor involved in collecting the log files is considerable. Otherwise, the system works very well.
VI. The Future
A. Authentication
In the long run, we need to have a single, system-wide, user authentication environment. PSU is in the process of implementing the Distributed Computing Environment (DCE) as an approach to providing such a system. With the appropriate clients in place in campus computers, DCE would provide a platform independent, system-wide authentication system. In order to support the current environment of application and file servers, the DCE implementation may need to incorporate an NT login once DCE has authenticated the user. At this point we have not developed a method to achieve this. Merging the NT and DCE environments to support University-wide authentication and authorization is the ultimate goal. As noted, the implementation described in this presentation is intended to facilitate this transition when it becomes practical.
While we continue exploring DCE, we are also keeping a close eye on the authentication services provided in NT version 5. Preliminary reviews indicate that the new NT environment provides for multiple, distributed authentication servers with inter-domain communication capabilities. This would enable the creation of individual campus authentication servers in separate domains which 'talked' with each other to allow a visiting student to login at a campus. Implementation of such a system would still require a distribution of authentication data to the campuses. It is unclear at this point whether we could automate that process in a secure fashion.
The current user authentication environment focuses on the student labs. Next year we plan to expand the authentication requirement to all Commonwealth College campus systems, including systems used by faculty and staff. We anticipate some negative reactions to this move, but expect the benefits in better security to outweigh the obstacles we may encounter.
The success of a system-wide authentication system depends on an extremely persistent network connection. As mentioned earlier, PSU's current infrastructure does not yet provide redundancy and experiences occasional outages. In order to provide a more robust network, PSU's Office of Telecommunications is rebuilding the current shared T1 WAN to provide a minimum of two dedicated T1's to each campus and a backup set of ISDN circuits.
This new WAN will provide greater bandwidth and more uptime. The system will also utilize ATM, which enables us to route more services over the shared backbone and provide quality of service control.
VII. Conclusion
The steady increase worldwide in security incidents of all descriptions indicates a great need for comprehensive user authentication systems. User authentication systems can be built using open standards (e.g., Kerberos/DCE) integrated with standard products such as Microsoft NT and KarlNet's firewalls.