Practical UNIX & Internet Security phần 9 pptx

login REPEATED LOGIN FAILURES ON <tty> [FROM <hostname>] <user> Somebody tried to log in as <user> and supplied a bad password more than five times. reboot rebooted by <user> <user> rebooted the system with the /etc/reboot command. su BAD SU <user> on <tty> Somebody tried to su to the superuser and did not supply the correct password. shutdown reboot, halt, or shutdown by <user> on <tty> <user> used the /etc/shutdown command to reboot, halt, or shut down the system. Other critical conditions that might be present might include messages about full filesystems, device failures, or network problems. Table 10.5: Typical Info Messages Program Message Meaning date date set by <user> <user> changed the system date. login ROOT LOGIN <tty> [FROM <hostname>] root logged in. su <user> on <tty> <user> used the su command to become the superuser. getty <tty> /bin/getty was unable to open <tty>. NOTE: For security reasons, some information should never be logged. For example, although you should log failed password attempts, you should not log the password that was used in the failed attempt. Users frequently mistype their own passwords, and logging these mistyped passwords would help a computer cracker break into a user's account. Some system administrators believe that the account name should also not be logged on failed login attempts - especially when the account typed by the user is nonexistent. The reason is that users occasionally type their passwords when they are prompted for their usernames. If invalid accounts are logged, then it might be possible for an attacker to use those logs to infer people's passwords. You may want to insert syslog calls into your own programs to record information of importance. Third-party software also often has a capability to send log messages into the syslog if configured correctly. For example, Xyplex terminal servers and Cisco routers both can log information to a network syslog daemon; Usenet news and POP mail servers also log information. If you are writing shell scripts, you can also log to syslog. Usually, systems with syslog come with the logger command. To log a warning message about a user trying to execute a shell file with invalid parameters, you might include: logger -t ThisProg -p user.notice "Called without required # of parameters" NOTE: Prior to 1995, many versions of the syslog library call did not properly check their inputs to be certain that the data would fit into the function's internal buffers. Thus, many programs could be coerced to accept input to write arbitrary data over their stacks, leading to potential compromise. Be certain that you are running software using a version of syslog that does not have this vulnerability. 10.5.3.1 Beware false log entries The UNIX syslog facility allows any user to create log entries. This capability opens up the possibility for false data to be entered into your logs. An interesting story of such logging was given to us by Alec Muffet: A friend of mine - a UNIX sysadmin - enrolled as a mature student at a local polytechnic in order to secure the degree which had been eluding him for the past four years. [Chapter 10] 10.5 The UNIX System Log (syslog) Facility file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch10_05.htm (6 of 7) [2002-04-12 10:45:30] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com One of the other students on his Computer Science course was an obnoxious geek user who was shoulder surfing people and generally making a nuisance of himself, and so my friend determined to take revenge. The site was running an early version of Ultrix on an 11/750, but the local operations staff were somewhat paranoid about security, had removed world execute from "su" and left it group-execute to those in the wheel group, or similar; in short, only the sysadmin staff should have execute access for su. Hence, the operations staff were somewhat worried to see messages with the following scrolling up the console: BAD SU: geekuser ON ttyp4 AT 11:05:20 BAD SU: geekuser ON ttyp4 AT 11:05:24 BAD SU: geekuser ON ttyp4 AT 11:05:29 BAD SU: geekuser ON ttyp4 AT 11:05:36 When the console eventually displayed: SU: geekuser ON ttyp4 AT 11:06:10 all hell broke loose: the operations staff panicked at the thought of an undergrad running around the system as root and pulled the plug (!) on the machine. The system administrator came into the terminal room, grabbed the geekuser, took him away and shouted at him for half an hour, asking (a) why was he hacking, (b) how was he managing to execute su and (c) how he had guessed the root password? Nobody had noticed my friend in the corner of the room, quietly running a script which periodically issued the following command, redirected into /dev/console, which was world-writable: echo BAD SU: geekuser ON ttyp4 AT `date` The moral of course is that you shouldn't panic, and that you should treat your audit trail with suspicion. 10.4 Per-User Trails in the Filesystem 10.6 Swatch: A Log File Tool [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] [Chapter 10] 10.5 The UNIX System Log (syslog) Facility file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch10_05.htm (7 of 7) [2002-04-12 10:45:30] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 6 6. Cryptography Contents: A Brief History of Cryptography What Is Encryption? The Enigma Encryption System Common Cryptographic Algorithms Message Digests and Digital Signatures Encryption Programs Available for UNIX Encryption and U.S. Law Cryptography is the science and art of secret writing - keeping information secret.[1] When applied in a computing environment, cryptography can protect data against unauthorized disclosure; it can authenticate the identity of a user or program requesting service; and it can disclose unauthorized tampering. In this chapter, we'll survey some of those uses, and present a brief summary of encryption methods that are often available in UNIX systems. [1] Cryptanalysis is the related study of breaking ciphers. Cryptology is the combined study of cryptography and cryptanalysis. Cryptography is an indispensable part of modern computer security. 6.1 A Brief History of Cryptography Knowledge of cryptography can be traced back to ancient times. It's not difficult to understand why: as soon as three people had mastered the art of reading and writing, there was the possibility that two of them would want to send letters to each other that the third could not read. In ancient Greece, the Spartan generals used a form of cryptography so that the generals could exchange secret messages: the messages were written on narrow ribbons of parchment that were wound spirally around a cylindrical staff called a scytale. After the ribbon was unwound, the writing on it could only be read by a person who had a matching cylinder of exactly the same size. This primitive system did a reasonably good job of protecting messages from interception and from the prying eyes of the message courier as well. In modern times, cryptography's main role has been in securing electronic communications. Soon after [Chapter 6] Cryptography file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch06_01.htm (1 of 4) [2002-04-12 10:45:31] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Samuel F. B. Morse publicly demonstrated the telegraph in 1845, users of the telegraph began worrying about the confidentiality of the messages that were being transmitted. What would happen if somebody tapped the telegraph line? What would prevent unscrupulous telegraph operators from keeping a copy of the messages that they relayed and then divulging them to others? The answer was to encode the messages with a secret code, so that nobody but the intended recipient could decrypt them. Cryptography became even more important with the invention of radio, and its use in war. Without cryptography, messages transmitted to or from the front lines could easily be intercepted by the enemy. 6.1.1 Code Making and Code Breaking As long as there have been code makers, there have been code breakers. Indeed, the two have been locked in a competition for centuries, with each advance on one side being matched by counter-advances on the other. For people who use codes, the code-breaking efforts of cryptanalysts pose a danger that is potentially larger than the danger of not using cryptography in the first place. Without cryptography, you might be reluctant to send sensitive information through the mail, across a telex, or by radio. But if you think that you have a secure channel of communication, then you might use it to transmit secrets that should not be widely revealed. For this reason, cryptographers and organizations that use cryptography routinely conduct their own code-breaking efforts to make sure that their codes are resistant to attack. The findings of these self-inflicted intrusions are not always pleasant. The following brief story from a 1943 book on cryptography demonstrates this point quite nicely: [T]he importance of the part played by cryptographers in military operations was demonstrated to us realistically in the First World War. One instructive incident occurred in September 1918, on the eve of the great offensive against Saint-Mihiel. A student cryptographer, fresh from Washington, arrived at United States Headquarters at the front. Promptly he threw the General Staff into a state of alarm by decrypting with comparative ease a secret radio message intercepted in the American sector. The smashing of the German salient at Saint-Mihiel was one of the most gigantic tasks undertaken by the American forces during the war. For years that salient had stabbed into the Allied lines, cutting important railways and communication lines. Its lines of defense were thought to be virtually impregnable. But for several months the Americans had been making secret preparations for attacking it and wiping it out. The state was set, the minutest details of strategy had been determined - when the young officer of the United States Military Intelligence spread consternation through our General Staff. The dismay at Headquarters was not caused by any new information about the strength of the enemy forces, but by the realization that the Germans must know as much about our secret plans as we did ourselves - even the exact hour set for the attack. The `intercepted' message had been from our own base. German cryptographers were as expert as any in the world, and what had been done by an American student cryptographer could surely have been done by German specialists. [Chapter 6] Cryptography file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch06_01.htm (2 of 4) [2002-04-12 10:45:31] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com The revelation was even more bitter because the cipher the young officer had broken, without any knowledge of the system, was considered absolutely safe and had long been used for most important and secret communications.[2] [2] Smith, Laurence Dwight. Cryptography: The Science of Secret Writing. Dover Publications, New York, 1941. 6.1.2 Cryptography and Digital Computers Modern digital computers are, in some senses, the creations of cryptography. Some of the first digital computers were built by the Allies to break messages that had been encrypted by the Germans with electromechanical encrypting machines. Code breaking is usually a much harder problem than code making; after the Germans switched codes, the Allies often took several months to discover the new coding systems. Nevertheless, the codes were broken, and many historians say that World War II was shortened by at least a year as a result. Things really picked up when computers were turned to the task of code making. Before computers, all of cryptography was limited to two basic techniques: transposition, or rearranging the order of letters in a message (such as the Spartan's scytale), and substitution, or replacing one letter with another one. The most sophisticated pre-computer cipher used five or six transposition or substitution operations, but rarely more. With the coming of computers, ciphers could be built from dozens, hundreds, or thousands of complex operations, and yet could still encrypt and decrypt messages in a short amount of time. Computers have also opened up the possibility of using complex algebraic operations to encrypt messages. All of these advantages have had a profound impact on cryptography. 6.1.3 Modern Controversy In recent years, encryption has gone from being an arcane science and the stuff of James Bond movies, to being the subject of debate in several nations (but we'll focus on the case in the U.S. in the next few paragraphs). In the U.S. that debate is playing itself out on the front pages of newspapers such as The New York Times and the San Jose Mercury News. On one side of the debate are a large number of computer professionals, civil libertarians, and perhaps a majority of the American public, who are rightly concerned about their privacy and the secrecy of their communications. These people want the right and the ability to protect their data with the most powerful encryption systems possible. On the other side of the debate are the United States Government, members of the nation's law enforcement and intelligence communities, and (apparently) a small number of computer professionals, who argue that the use of cryptography should be limited because it can be used to hide illegal activities from authorized wiretaps and electronic searches. MIT Professor Ronald Rivest has observed that the controversy over cryptography fundamentally boils down to one question: Should the citizens of a country have the right to create and store documents which their [Chapter 6] Cryptography file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch06_01.htm (3 of 4) [2002-04-12 10:45:31] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com government cannot read?[3] [3] Rivest, Ronald, speaking before the MIT Telecommunications Forum, Spring 1994. This chapter does not address this question. Nor do we attempt to explore the U.S. Government's[4] claimed need to eavesdrop on communications, the fear that civil rights activists have of governmental abuse, or other encryption policy issues. Although those are interesting and important questions - questions you should also be concerned with as a computer user - they are beyond the scope of this book. Instead, we focus on discussion of the types of encryption that are available to most UNIX users today and those that are likely to be available in the near future. If you are interested in the broader questions of who should have access to encryption, we suggest that you pursue some of the references listed in Appendix D, Paper Sources, starting with Building in Big Brother, edited by Professor Lance Hoffman. [4] Or any other government! A Note About Key Escrow There has been considerable debate recently centering on the notion of key escrow. The usual context is during debate over the ability of private citizens to have access to strong cryptography. Many government officials and prominent scientists advocate a form of escrowed encryption as a good compromise between law enforcement needs and privacy concerns. In such schemes, a copy of the decryption key for each user is escrowed by one or more trusted parties, and is available if a warrant is issued for it. Whatever your feelings are on the matter of law enforcement access to your decryption keys, consider escrowing your keys! By this, we do not mean making your keys available to the government. Rather, we mean placing a copy of your keys in a secure location where they can be retrieved if you or someone else needs them. You may pick a key so strong that you forget it a year from now. Or, you might develop amnesia, get food poisoning from a bad Twinkie, or get kidnapped by aliens to keep Elvis company. If any of these calamities befall you, how are your coworkers or family going to decrypt the vital records that you have encrypted? We recommend that you deposit copies of your encryption keys and passwords in safe locations, such as a safe or safety deposit box. If you are uncomfortable about leaving the keys all in one place, there are algorithms with which you can split a key into several parts and deposit a part with each of several trusted parties. With key-splitting schemes, one or two parts by themselves are not enough to recreate the key, but a majority of them is enough to recover the key. Consult a good book on cryptography for details. But do escrow your own keys! 5.10 Summary 6.2 What Is Encryption? [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] [Chapter 6] Cryptography file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch06_01.htm (4 of 4) [2002-04-12 10:45:31] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 10 Auditing and Logging 10.4 Per-User Trails in the Filesystem Although not obvious, there are some files that are kept on a per-user basis that can be helpful in analyzing when something untoward has happened on your system. While not real log files, as such, they can be treated as a possible source of information on user behavior. 10.4.1 Shell History Many of the standard user command shells, including csh, tcsh, and ksh, can keep a history file. When the user issues commands, the text of each command and its arguments are stored into the history file for later re-execution. If you are trying to recreate activity performed on an account, possibly by some intruder, the contents of this file can be quite helpful when coupled with system log information. You must check the modification time on the file to be sure that it was in use during the time the suspicious activity occurred. If it was created and modified during the intruder's activities, you should be able to determine the commands run, the programs compiled, and sometimes even the names of remote accounts or machines that might also be involved in the incident. Be sure of your target, however, because this is potentially a violation of privacy for the real user of this account. Obviously, an aware intruder will delete the file before logging out. Thus, this mechanism may be of limited utility. However, there are two ways to increase your opportunity to get a useful file. The first way is to force the logout of the suspected intruder, perhaps by using a signal or shutting down the system. If a history file is being kept, this will leave the file on disk where it can be read. The second way to increase your chances of getting a usable file is to make a hard link to the existing history file, and to locate the link in a directory on the same disk that is normally inaccessible to the user (e.g., in a root-owned directory). Even if the intruder unlinks the file from the user's directory, it can still be accessed through the extra link. Also note that this technique can come in handy if you suspect that an account is being used inappropriately. You can alter the system profile to create and keep a history file, if none was kept before. On some systems, you can even designate a named pipe (FIFO) as the history file, thus transmitting the material to a logging process in a manner that cannot be truncated or deleted. Even if you were unable to preserve a copy of the history file, but one was created and then unlinked by the intruder, you can still gain some useful information if you act quickly enough. The first thing you must do is to either take the system to single-user mode, or umount the disk with the suspect account (we recommend going to single-user mode). Then, you can use disk-examination tools to look at the records on the free list. When a file is deleted, the contents are not immediately overwritten. Instead, the data [Chapter 10] 10.4 Per-User Trails in the Filesystem file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch10_04.htm (1 of 2) [2002-04-12 10:45:31] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com records are added back into the freelist on disk. If they are not reused yet (which is why you umount the disk or shut the system down), you can still read the contents. 10.4.2 Mail Some user accounts are configured to make a copy of all outgoing mail in a file. If an intruder sends mail from a user account where this feature is set (or where you set it), this feature can provide you with potentially useful information. In at least one case we know of, a person stealing confidential information by using a coworker's pirated password was exposed because of recorded email to his colleagues that he signed with his own name! Some systems also record a log file of mail sent and received. This file can be kept per-user, or it may be part of the system-wide syslog audit trail. The contents of this log can be used to track what mail has come in and left the system. If nothing else, we have found this information to be useful when a disk error (or human error) wipes out a whole set of mailboxes - the people listed in the mail log file can be contacted to resend their mail. 10.4.3 Network Setup Each user account can have several network configuration files that can be edited to provide shortcuts for commands, or to assert access rights. Sometimes, the information in these files will provide a clue as to the activities of a malefactor. Examples include the .rhosts file for remote logins, and the .netrc file for FTP. Examine these files carefully for clues, but remember: the presence of information in one of these files may have been there prior to the incident, or it may have been planted to throw you off. 10.3 Program-Specific Log Files 10.5 The UNIX System Log (syslog) Facility [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] [Chapter 10] 10.4 Per-User Trails in the Filesystem file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch10_04.htm (2 of 2) [2002-04-12 10:45:31] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 11 Protecting Against Programmed Threats 11.2 Damage The damage that programmed threats do ranges from the merely annoying to the catastrophic - for example, the complete destruction of all data on a system by a low-level disk format. The damage may be caused by selective erasures of particular files, or minute data changes that swap random digits or zero out selected values. Many threats may seek specific targets - their authors may wish to damage a particular user's files, destroy a particular application, or completely initialize a certain database to hide evidence of some other activity. Disclosure of information is another type of damage that may result from programmed threats. Rather than simply altering information on disk or in memory, a threat can make some information readable, send it out as mail, post it on a bulletin board, or print it on a printer. This information could include sensitive material, such as system passwords or employee data records, or something as damaging as trade secret software. Programmed threats may also allow unauthorized access to the system, and may result in installing unauthorized accounts, changing passwords, or circumventing normal controls. The type of damage done varies with the motives of the people who write the malicious code. Malicious code can cause indirect damage, too. If your firm ships software that inadvertently contains a virus or logic bomb, there are several forms of potential damage to consider. Certainly, your corporate reputation will suffer. Your company could also be held accountable for customer losses as well; licenses and warranty disclaimers used with software might not protect against damage suits in such a situation. You cannot know with certainty that any losses (of either kind - direct or indirect) will be covered by business insurance. If your company does not have a well-defined security policy and your employees fail to exercise precautions in the preparation and distribution of software, your insurance may not cover subsequent losses. Ask your insurance company about any restrictions on their coverage of such incidents. 11.1 Programmed Threats: Definitions 11.3 Authors [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] [Chapter 11] 11.2 Damage file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch11_02.htm [2002-04-12 10:45:31] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 1 Introduction 1.2 What Is an Operating System? For most people, a computer is a tool for solving problems. When running a word processor, a computer becomes a machine for arranging words and ideas. With a spreadsheet, the computer is a financial planning machine, one that is vastly more powerful than a pocket calculator. Connected to an electronic network, a computer becomes part of a powerful communications system. At the heart of every computer is a master set of programs called the operating system. This is the software that controls the computer's input/output systems such as keyboards and disk drives, and that loads and runs other programs. The operating system is also a set of mechanisms and policies that help define controlled sharing of system resources. Along with the operating system is a large set of standard utility programs for performing common functions such as copying files and listing the contents of directories. Although these programs are not technically part of the operating system, they can have a dramatic impact on a computer system's security. All of UNIX can be divided into three parts: The kernel, or the heart of the UNIX system, is the operating system. The kernel is a special program that is loaded into the computer when it is first turned on. The kernel controls all of the computer's input and output systems; it allows multiple programs to run at the same time, and it allocates the system's time and memory among them. The kernel includes the filesystem, which controls how files and directories are stored on the computer's hard disk. The filesystem is the main mechanism by which computer security is enforced. Some modern versions of UNIX allow user programs to load additional modules, such as device drivers, into the kernel after the system starts running. ● Standard utility programs are run by users and by the system. Some programs are small and serve a single function - for example, /bin/lslists files and /bin/cp copies them. Other programs are large and perform many functions - for example, /bin/sh and /bin/csh, UNIX shells that process user commands, are themselves programming languages. ● System database files, most of which are relatively small, are used by a variety of programs on the system. One file, /etc/passwd, contains the master list of every user on the system. Another file, /etc/group, describes groups of users with similar access rights. ● From the point of view of UNIX security, these three parts interact with a fourth entity: [Chapter 1] 1.2 What Is an Operating System? file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch01_02.htm (1 of 2) [2002-04-12 10:45:31] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [...]... file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch 19_ 07.htm (1 of 2) [2002-04-12 10:45:32] [Chapter 19] 19. 7 Other Network Authentication Systems Simpo 19. 6 KerberosPDF Merge and Split Unregistered Version - http://www.simpopdf.com 20 NFS [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] file:///C|/Oreilly Unix etc/O'Reilly... sophisticated and security- conscious software For this reason, establishing and codifying policy plays a very important role in the overall process of operating a secure system This is discussed further in Chapter 2 1.1 What Is Computer Security? 1.3 History of UNIX [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] file:///C|/Oreilly Unix etc/O'Reilly... stated concerns, maybe the vendors will finally catch on 1.4 Security and UNIX 2 Policies and Guidelines [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch01_05.htm (2 of 2) [2002-04-12 10:45:32] [Chapter 23] 23.7 UNIX Pseudo-Random Functions Simpo PDF Merge and Split Unregistered... Protecting Data 13 Personnel Security [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch12_04.htm (3 of 3) [2002-04-12 10:45:34] [Chapter 13] 13.3 Outsiders Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 13 Personnel Security 13.3 Outsiders Visitors,... from the outside should be allowed unrestricted physical access to your computer and network equipment 13.2 On the Job IV Network and Internet Security [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch13_03.htm [2002-04-12 10:45:34] [Chapter 6] 6.3 The Enigma Encryption System... restrict connectivity 17.3 Primary UNIX Network Services 17.5 Monitoring Your Network with netstat file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch17_04.htm (2 of 3) [2002-04-12 10:45:36] [Chapter 17] 17.4 Security Implications of Network Services [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] Simpo PDF Merge and Split... examples of past security holes in the UNIX operating system, we have intentionally not provided the reader with an exhaustive list of the means by which a machine can be penetrated Not only would such information not necessarily help to improve the security of your system, but it might place a number of systems running older versions of UNIX at additional risk Even properly configured UNIX systems are... every one of your users about good security and convince them to practice what they learn Computer security is a lonely, frustrating occupation if it is practiced as a case of "us" (information security personnel) versus "them" (the rest of the users) If you can practice security as "all of us" (everyone in the organization) versus "them" (people who would breach our security) , the process will be much... [2002-04-12 10:45:31] [Chapter 19] 19. 7 Other Network Authentication Systems Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 19 RPC, NIS, NIS+, and Kerberos 19. 7 Other Network Authentication Systems Besides Sun's Secure RPC and Kerberos, there are a variety of other systems for providing authentication and encryption services over an unprotected network 19. 7.1 DCE DCE is the Distributed... Security [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch11_06.htm (3 of 3) [2002-04-12 10:45:33] [Chapter 12] 12.4 Story: A Failed Site Inspection Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 12 Physical Security 12.4 Story: A Failed Site . Meaning date date set by <user> <user> changed the system date. login ROOT LOGIN <tty> [FROM <hostname>] root logged in. su <user> on <tty> <user> used the su. FAILURES ON <tty> [FROM <hostname>] <user> Somebody tried to log in as <user> and supplied a bad password more than five times. reboot rebooted by <user> <user> rebooted. BAD SU <user> on <tty> Somebody tried to su to the superuser and did not supply the correct password. shutdown reboot, halt, or shutdown by <user> on <tty> <user>