Handbook of Local Area Networks, 1998 Edition:LAN Security Click Here! Search the site:   ITLibrary ITKnowledge EXPERT SEARCH Programming Languages Databases Security Web Services Network Services Middleware Components Operating Systems User Interfaces Groupware & Collaboration Content Management Productivity Applications Hardware Fun & Games EarthWeb sites Crossnodes Datamation Developer.com DICE EarthWeb.com EarthWeb Direct ERP Hub Gamelan GoCertify.com HTMLGoodies Intranet Journal IT Knowledge IT Library JavaGoodies JARS JavaScripts.com open source IT RoadCoders Y2K Info Previous Table of Contents Next CASE STUDY The system administrator for the College of Engineering at the University of South Florida (USF) had previously been charged with some responsibility for network security at the Federal Reserve Board of Governors. The Federal Reserve has a completely closed system—no Internet connection and no dial-in modems. Such a closed system tends to spoil the system administrator. The administrator brought experience from his previous job to his new job at USF. The college was based on mostly Sun4s and Sun3s running SunOS 4.1.1 (a flavor of UNIX). SunOS 4.1.x is an extremely popular operating system in the UNIX world. This popularity, particularly at universities, makes it a prime operating system to be hacked. After about a month and a half, the systems administrator began to notice problems. Two users had attempted to log into his personal UNIX system from a system called sunburn.eng.usf.edu. The two user names used were csmith and winston, which was curious. Cay Smith was the office manager for the computer science department. She most likely would not log into the systems administrator’s computer and she especially would not log in from sunburn. The systems administrator did not know the other person. To be safe, he closed both of their accounts and talked to Cay Smith. The next day he received a call from a systems administrator at Oxford University who said that his systems had been compromised by a user from screamer.csee.usf.edu. The systems administrator at USF had only been the administrator of *.csee.usf.edu for a week and was barely familiar with those machines. The next day, he began inspecting the *.eng.usf.edu machines for unauthorized access. It turned out that root account had been active during the late evening. A total of six people legitimately had the root password. Each potential valid root user was questioned and they all said that they were not on. What was more curious was the inconsistency in the logs. In UNIX, there are several log files that can be configured to log root access. The system was set up such that a log message would be generated if a user executed su (i.e., a command to become superuser) or logged in with the username root. There were no log messages indicating either of these events. SunOS 4.1.x also has a primitive accounting facility that tells the administrator information about process information (e.g., when a job is executed, how much CPU time it took, and what terminal the user was attached to when he or she ran it). Some processes (see Exhibit 8-1-9) run in the background and are not typed from a terminal. When the systems administrator retrieved similar information during the time of the attacks, however, he found that root had been active from a terminal. Exhibit 8-1-9.  Sample Root Processes That Run In the Background The systems administrator was now reasonably certain that his system was compromised. This person could corrupt any data, read any E-mail, or erase any file. The systems administrator ran security scanning tools. The accounts that were hackable were closed down and the users were required to show up in person to reactivate them. This was the only method available to ensure that the users were who them claimed to be. Root continued to be active late at night. The hacker was getting bolder and started to erase logging information, however, he or she appeared ignorant of /usr/adm/pacct, the process accounting file that had become the systems administrator’s best tool for tracking. The systems administrator soon received an anonymous phone call saying that the hacker was currently on his system and bragging on an Internet relay chat (IRC) about his or her exploits. The administrator typed the root command to list all the root users’ processes. The administrator’s ps command had been altered such that the hacker’s activities would not show up, so he copied over a correct version. The true ps command showed that the hacker was running the IRC client. The ps command also showed the parent process of the IRC client was in.rlogind, the remote login daemon. The netstat and ofiles commands revealed that the connection was coming from the administrator’s local terminal server. There was only one user coming from the terminal server to that particular host. He could trace the connection all the way back to the telephone number on his terminal server, which had a tap command available. Using that command the administrator could record what the hacker was doing. The telephone company would have to take over. The USF police were called to arrange a tap through GTE (the local telephone company). The call was finally traced back to USF’s local central office (CO), meaning that the hacker was on campus. As the police and systems administrator watched and recorded the tapped session, they witnessed the hacker boasting about his or her expertise, trying to recompile and replace /bin/sync, and read the root’s E-mail. It was important to record this tap because the hacker had committed two Florida felonies—illegally accessing a computer system and illegally altering a computer system. SUMMARY No computer system is completely inviolable, though in our case study the police later arrested the hacker in his dormitory for illegal computer access. . It is up to the system administrator to decide the level of security that is sufficient for the data being protected. This chapter has outlined some typical security problems and suggested methods for efficiently, and legally, protecting computer systems. Previous Table of Contents Next Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.