Practical UNIX & Internet Security phần 4 docx

Remember, high-density RAM modules and processor cards are worth substantially more than their weight in gold. If a user complains that a computer is suddenly running more slowly than it did the day before, check its RAM, and then check to see that its case is physically secured. 12.2.6.1 Physically secure your computer A variety of physical tie-down devices are available to bolt computers to tables or cabinets. Although they cannot prevent theft, they can make theft more difficult. 12.2.6.2 Encryption If your computer is stolen, the information it contains will be at the mercy of the equipment's new "owners." They may erase it. Alternatively, they may read it. Sensitive information can be sold, used for blackmail, or used to compromise other computer systems. You can never make something impossible to steal. But you can make stolen information virtually useless - provided that it is encrypted and that the thief does not know the encryption key. For this reason, even with the best computer-security mechanisms and physical deterrents, sensitive information should be encrypted using an encryption system that is difficult to break.[5] We recommend that you acquire and use a strong encryption system so that even if your computer is stolen, the sensitive information it contains will not be compromised. [5] The UNIX crypt encryption program (described in Chapter 6, Cryptography) is trivial to break. Do not use it for information that is the least bit sensitive. 12.2.6.3 Portables Portable computers present a special hazard. They are easily stolen, difficult to tie down (they then cease to be portable!), and often quite easily resold. Personnel with laptops should be trained to be especially vigilant in protecting their computers. In particular, theft of laptops in airports is a major problem. Note that theft of laptops may not be motivated by greed (resale potential) alone. Often, competitive intelligence is more easily obtained by stealing a laptop with critical information than by hacking into a protected network. Thus, good encryption on a portable computer is critical. Unfortunately, this encryption makes the laptop a "munition" and difficult to legally remove from many countries (including the U.S.).[6] [6] See Chapter 6 for more detail on this. Different countries have different laws with respect to encryption, and many of these laws are currently in flux. In the United States, you cannot legally export computers containing cryptographic software: one solution to this problem is to use an encryption product that is manufactured and marketed outside, as well as inside, your country of origin. First encrypt the data before leaving, then remove the encryption software. After you arrive at your destination, obtain a copy of the same encryption software and reinstall it. (For the U.S. at least, you can legally bring the PC back into the country with the software in place.) But U.S. regulations currently have exemptions allowing U.S owned companies to transfer cryptographic software between their domestic and foreign offices. Furthermore, destination countries may have their own restrictions. Frankly, you may prefer to leave the portable at home! [Chapter 12] 12.2 Protecting Computer Hardware file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch12_02.htm (13 of 14) [2002-04-12 10:44:23] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 12.2.6.4 Minimizing downtime We hope your computer will never be stolen or damaged. But if it is, you should have a plan for immediately securing temporary computer equipment and for loading your backups onto the new systems. This plan is known as disaster recovery. We recommend that you do the following: Establish a plan for rapidly acquiring new equipment in the event of theft, fire, or equipment failure. ● Test this plan by renting (or borrowing) a computer system and trying to restore your backups.● If you ask, you may discover that your computer dealer is willing to lend you a system that is faster than the original system, for the purpose of evaluation. There is probably no better way to evaluate a system than to load your backup tapes onto the system and see if they work. Be sure to delete and purge the computer's disk drives before returning them to your vendor. 12.2.7 Related Concerns Beyond the items mentioned earlier, you may also wish to consider the impact on your computer center of the following: Loss of phone service or networks. How will this impact your regular operations?● Vendor going bankrupt. How important is support? Can you move to another hardware or software system? ● Significant absenteeism. Will this impact your ability to operate?● Death or incapacitation of key personnel. Can every member of your computer organization be replaced? What are the contingency plans? ● 12.1 One Forgotten Threat 12.3 Protecting Data [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] [Chapter 12] 12.2 Protecting Computer Hardware file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch12_02.htm (14 of 14) [2002-04-12 10:44:23] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 8 8. Defending Your Accounts Contents: Dangerous Accounts Monitoring File Format Restricting Logins Managing Dormant Accounts Protecting the root Account The UNIX Encrypted Password System One-Time Passwords Administrative Techniques for Conventional Passwords An ounce of prevention . . . The worst time to think about how to protect your computer and its data from intruders is after a break-in. At that point, the damage has already been done, and determining where and to what extent your system has been hurt can be difficult. Did the intruder modify any system programs? Did the intruder create any new accounts, or change the passwords of any of your users? If you haven't prepared in advance, you could have no way of knowing the answers. This chapter describes the ways in which an attacker can gain entry to your system through accounts that are already in place, and the ways in which you can make these accounts more difficult to attack. 8.1 Dangerous Accounts Every account on your computer is a door to the outside, a portal through which both authorized and unauthorized users can enter. Some of the portals are well defended, while others may not be. The system administrator should search for weak points and seal them up. 8.1.1 Accounts Without Passwords Like the lock or guard on the front door of a building, the password on each one of your computer's accounts is your system's first line of defense. An account without a password is a door without a lock. Anybody who finds that door - anybody who knows the name of the account - can enter. Many so-called "computer crackers" succeed only because they are good at finding accounts without [Chapter 8] Defending Your Accounts file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch08_01.htm (1 of 9) [2002-04-12 10:44:24] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com passwords or accounts that have passwords that are easy to guess. On SVR4 versions of UNIX, you can scan for accounts without passwords by using the logins command: # logins -p You can also scan for accounts without passwords by using the command: % cat-passwd | awk -F: 'length($2)<1 {print $1}' george dan % In this example, george and dan don't have passwords. Take a look at their entries in the /etc/passwd file: % egrep 'dan|george' /etc/passwd george::132:10:George Bush:/usr/wash/george:/bin/csh dan::132:10:Dan Quayle:/u/backyard/dan:/bin/csh % These two users have probably long forgotten about their accounts on this system. Their accounts should be disabled. NOTE: The /etc/passwd file may not be the correct file to check for missing passwords on systems that have shadow password files (described later in this chapter) installed. Different shadow password schemes store the actual encrypted passwords in different locations. On some systems, the file to check may be /etc/shadow or /etc/secure/passwd. On some AT&T System V systems, passwords are stored on a user-by-user basis in individual files located underneath the /tcb directory. Check your own system's documentation for details. Also, systems using NIS, NIS+ or DCE may get the passwords from a server; see Chapter 19, RPC, NIS, NIS+, and Kerberos, for details. 8.1.2 Default Accounts Many computer systems are delivered to end users with one or more default accounts. These accounts usually have standard passwords. For example, many UNIX computers come with a root account that has no password. Vendors tell users to assign passwords to these accounts, but, too often, users do not. (UNIX is not alone with this problem; other operating systems come delivered with standard accounts like SYSTEM with the password set to MANAGER.) One way around this problem that has been taken by several UNIX vendors is to have the operating system demand passwords for special accounts such as root when it is first installed. We hope that all vendors will adopt this approach in the future. Make a list of all of the accounts that came with your computer system. (These accounts are normally at the beginning of the /etc/passwd file and have names like bin, lib, uucp, and news.) Either disable these accounts (as described later in this chapter) or change their passwords. Some application programs automatically install accounts in the /etc/passwd file with names like demo (used to demonstrate the software). Be sure to delete or disable these accounts after the software is installed. Likewise, computers that are taken to trade shows sometimes have demo accounts created to make [Chapter 8] Defending Your Accounts file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch08_01.htm (2 of 9) [2002-04-12 10:44:24] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com demonstrations easier to run. Remember to remove these accounts when the computer is returned. (Even better: erase the hard disk and reinstall the operating system. You never know what a computer might bring back from a trade show.) Table 8.1 is a list of accounts that are commonly attacked. If you have any of these accounts, make sure that they are protected with strong passwords or that they are set up so they can do no damage if penetrated (see the sections below entitled "Accounts That Run a Single Command" and "Open Accounts"). Table 8.1: Account Names Commonly Attacked on UNIX Systems open help games guest demo maint mail finger uucp bin toor system who ingres lp nuucp visitor manager telnet 8.1.3 Accounts That Run a Single Command UNIX allows the system administrator to create accounts that simply run a single command or application program (rather than a shell) when a user logs into them. Often these accounts do not have passwords. Examples of such accounts include date, uptime, sync, and finger as shown below: date::60000:100:Run the date program:/tmp:/sbin/date uptime::60001:100:Run the uptime program:/tmp:/usr/ucb/uptime finger::60002:100:Run the finger program:/tmp:/usr/ucb/finger sync::60003:100:Run the sync program:/tmp:/sbin/sync If you have these accounts installed on your computer, someone can use them to find out the time or to determine who's logged into your computer simply by typing the name of the command at the login: prompt. For example: login: uptime Last login: Tue Jul 31 07:43:10 on ttya Whammix V 17.1 ready to go! 9:44am up 7 days, 13:09, 4 users, load average: 0.92, 1.34, 1.51 login: If you decide to set up an account of this type, you should be sure that the command it runs takes no keyboard input and can in no way be coerced into giving the user an interactive process. Specifically, these programs should not have shell escapes. Letting a user run the Berkeley mail program without logging in is dangerous, because the mail program allows the user to run any command by preceding a line of the mail message with a tilde and an exclamation mark. [Chapter 8] Defending Your Accounts file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch08_01.htm (3 of 9) [2002-04-12 10:44:24] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com % mail Sarah Subject: test message ~!date Wed Aug 1 09:56:42 EDT 1990 Allowing programs like who and finger to be run by someone who hasn't logged in is also a security risk, because these commands let people learn the names of accounts on your computer. Such information can be used as the basis for further attacks against your computer system. NOTE: If you must have accounts that run a single command, do not have those accounts run with the UID of 0 (root) or of any other privileged user (such as bin, system, daemon, etc.) 8.1.4 Open Accounts Many computer centers provide accounts on which visitors can play games while they are waiting for an appointment, or allow visitors to use a modem or network connection to contact their own computer systems. Typically these accounts have names like open, guest, or play. They usually do not require passwords. Because the names and passwords of open accounts are often widely known and easily guessed, they are security breaches waiting to happen. An intruder can use an open account to gain initial access to your machine, and then use that access to probe for greater security lapses on the inside. At the very least, an intruder who is breaking into other sites might direct calls through the guest account on your machine, making their calls difficult or even impossible to trace. Providing open accounts in your system is a very bad idea. If you must have them, for whatever reason, generate a new, random password daily for your visitors to use. Don't allow the password to be sent via electronic mail or given to anyone who doesn't need it for that day. 8.1.4.1 Restricted shells under System V UNIX The System V UNIX shell can be invoked to operate in a restricted mode that can be used to minimize the dangers of an open account. This mode occurs when the shell is invoked with a -r command-line option, or with the command named rsh (restricted shell)[1] - usually as a link to the standard shell. When rsh starts up, it executes the commands in the file $HOME/.profile. Once the .profile is processed, the following restrictions go into effect: [1] Not to be confused with rsh, the network remote-shell command. This conflict is unfortunate. The user can't change the current directory. ● The user can't change the value of the PATH environment variable.● The user can't use command names containing slashes.● The user can't redirect output with > or >>.● As an added security measure, if the user tries to interrupt rsh while it is processing the $HOME/.profile file, rsh immediately exits. The net effect of these restrictions is to prevent the user from running any command that is not in a directory contained in the PATH environment variable, to prevent the user from changing his or her PATH, and to prevent the user from changing the .profile of the restricted account that sets the PATH variable in the first [Chapter 8] Defending Your Accounts file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch08_01.htm (4 of 9) [2002-04-12 10:44:24] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com place. You can further modify the .profile file to prevent the restricted account from being used over the network. You do this by having the shell script use the tty command to make sure that the user is attached to a physical terminal and not a network port. Be aware that rsh is not a panacea. If the user is able to run another shell, such as sh or csh, the user will have the same access to your computer that he or she would have if the account was not restricted at all. Likewise, if the user can run a program that supports shell escapes, such as mail, the account is unrestricted (see below). 8.1.4.2 Restricted shells under Berkeley versions Under Berkeley-derived UNIX, you can create a restricted shell by creating a hard link to the sh program and giving it the name rsh. When sh starts up, it looks at the program name under which it was invoked to determine what behavior it should have: % ln /bin/sh /usr/etc/rsh This restricted shell functions in the same manner as the System V rsh described above. Note that a hard link will fail if the destination is on a different partition. If you need to put rsh and sh on different partition, try a symbolic link, which works on most systems. If it does not, or if your system does not support symbolic links, then consider copying the shell to the destination partition, rather than linking it. You should be careful not to place this restricted shell in any of the standard system program directories, so that people don't accidentally execute it when they are trying to run the rsh remote shell program. 8.1.4.3 Restricted Korn shell The Korn shell (ksh) can be configured to operate in a restricted mode as well, and be named rksh or krsh so as not to conflict with the network remote shell rsh. If ksh is invoked with the -r command-line option, or is started as rsh, it also executes in restricted mode. When in restricted mode, the Korn shell behaves as the System V restricted shell, except that additionally the user cannot modify the ENV or SHELL variables, nor can the user change the primary group using the newgrp command. 8.1.4.4 No restricted bash The ( bsh) shell from the Free Software Foundation does not have a restricted mode. 8.1.4.5 How to set up a restricted account with rsh To set up a restricted account that uses rsh, you must: Create a special directory containing only the programs that the restricted shell can run. ● Create a special user account that has the restricted shell as its login shell.● NOTE: The setup we show in the following example is not entirely safe, as we explain later in this chapter. For example, to set up a restricted shell that lets guests play rogue and hack, and use the talk program, first create a user called player that has /bin/rsh as its shell and /usr/rsh/home as its home directory: player::100:100:The Games Guest user:/usr/rshhome:/bin/rsh [Chapter 8] Defending Your Accounts file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch08_01.htm (5 of 9) [2002-04-12 10:44:24] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Next, create a directory for only the programs you want the guest to use, and fill the directory with the appropriate links: # mkdir /usr/rshhome /usr/rshhome/bin # ln /usr/games/hack /usr/rshhome/bin/hack # ln /usr/games/rogue /usr/rshhome/bin/rogue # ln /usr/bin/talk /usr/rshhome/bin/talk # chmod 555 /usr/rshhome/bin # chmod 555 /usr/rshhome Finally, create a .profile for the player user that sets the PATH environment variable and prints some instructions: # cat > /usr/rshhome/.profile /bin/echo This guest account is only for the use of authorized guests. /bin/echo You can run the following programs: /bin/echo rogue A role playing game /bin/echo hack A better role playing game /bin/echo talk A program to talk with other people. /bin/echo /bin/echo Type "logout" to log out. PATH=/usr/rshhome/bin SHELL=/bin/rsh export PATH SHELL ^D # chmod 444 /usr/rshhome/.profile # chown player /usr/rshhome/.profile # chmod 500 /usr/rshhome 8.1.4.6 Potential problems with rsh Be especially careful when you use rsh, because many UNIX commands allow shell escapes, or means of executing arbitrary commands or subshells from within themselves. Many programs that have shell escapes do not document this feature; several popular games fall into this category. If a program that can be run by a "restricted" account has the ability to run subprograms, then the account may not be restricted at all. For example, if the restricted account can use man to read reference pages, then a person using the restricted account can use man to start up an editor, then spawn a shell, and then run programs on the system. For instance, in our above example, all of the commands linked into the restricted bin will spawn a subshell when presented with the appropriate input. Thus, although the account appears to be restricted, it will actually only slow down users who don't know about shell escapes. 8.1.5 Restricted Filesystem Another way to restrict some users on your system is to put them into a restricted filesystem. You can construct an environment where they have limited access to commands and files, but can still have access to a regular shell (or a restricted shell if you prefer). The way to do this is with the chroot () system call. chroot () changes a process's view of the filesystem such that the apparent root directory is not the real filesystem root directory, but one of its descendents. [Chapter 8] Defending Your Accounts file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch08_01.htm (6 of 9) [2002-04-12 10:44:24] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com SVR4 has a feature to do this change automatically. If the shell field (field 7) for a user in the /etc/passwd file is a "*" symbol, then the login program will make a chroot () call on the home directory field (field 6) listed in the entry. It will then reexecute the login program - only this time, it will be the login program in the reduced filesystem, and will be using the new passwd file found there (one that has a real shell listed, we would expect). If you do not have this feature in your version of UNIX, you can easily write a small program to do so (it will need to be SUID root for the chroot() call to function), and place the program's pathname in the shell field instead of one of the shells. The restricted filesystem so named must have all the necessary files and commands for the login program to run and to execute programs (including shared libraries). Thus, the reduced filesystem needs to have an /etc directory, a /lib and /usr/lib directory, and a /bin directory. However, these directories do not need to contain all of the files and programs in the standard directories. Instead, you can copy or link only those files necessary for the user.[2] Remember to avoid symbolic links reaching out of the restricted area, because the associated directories will not be visible. Using loopback mounts of the filesystem in read-only mode is one good way to populate these limited filesystems as it also protects the files from modification. Figure 1.1 shows how the restricted filesystem is part of the regular filesystem. [2] This may take some experimentation on your part to get the correct setup of files. Figure 8.1: Example of restricted filesystem There are at least two good uses for such an environment. 8.1.5.1 Limited users [Chapter 8] Defending Your Accounts file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch08_01.htm (7 of 9) [2002-04-12 10:44:24] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com You may have occasion to give access to some users for a set of limited tasks. For instance, you may have an online company directory and an order-tracking front end to a customer database, and you might like to make these available to your customer service personnel. There is no need to make all of your files and commands accessible to these users. Instead, you can set up a minimal account structure so that they can log in, use standard programs that you provide, and have the necessary access. At the same time, you have put another layer of protection between your general system and the outside: if intruders manage to break the password of one of these users and enter the accounts, they will not have access to the real /etc/passwd (to download and crack), nor will they have access to network commands to copy files in or out, nor will they be able to compile new programs to do the same. 8.1.5.2 Checking new software Another use of a restricted environment is to test new software of perhaps questionable origin. In this case, you configure an environment for testing, and enter it with either the chroot () system command or with a program that executes chroot() on your behalf. Then, when you test the software you have obtained, or unpack an archive, or perform any other possibly risky operation, the only files you will affect are the ones you put in the restricted environment - not everything in the whole filesystem! NOTE: Be very, very careful about creating any SUID programs that make a chroot() call. If any user can write to the directory to which the program chroot's, or if the user can specify the directory to which the chroot() occurs, the user could become a superuser on your system. To do this, he need only change the password file in the restricted environment to give himself the ability to su to root, change to the restricted environment, create a SUID root shell, and then log back in as the regular user to execute the SUID shell. 8.1.6 Group Accounts A group account is an account that is used by more than one person. Group accounts are often created to allow a group of people to work on the same project without requiring that an account be built for each person. Other times, group accounts are created when several different people have to use the same computer for a short period of time. In many introductory computer courses, for example, there is a group account created for the course; different students store their files in different subdirectories or on floppy disks. Group accounts are always a bad idea, because they eliminate accountability. If you discover that an account shared by 50 people has been used to break into computers across the United States, tracking down the individual responsible will be nearly impossible. Furthermore, a person is far more likely to disclose the password for a group account than he is to release the password for an account to which he alone has access. An account that is officially used by 50 people may in fact be used by 150; you have no way of knowing. Instead of creating group accounts, create an account for each person in the group. If the individuals are all working on the same project, create a new UNIX group in the file /etc/group, and make every user who is affiliated with the project part of the group. This method has the added advantage of allowing each user to have his own start-up and dot files. For example, to create a group called spistol with the users sid, john, and nancy in it, you might create the following entry in /etc/group: spistol:*:201:sid,john,nancy Then be sure that Sid, John, and Nancy understand how to set permissions and use necessary commands to work with the group account. In particular, they should set their umask to 002 or 007 while working on the [Chapter 8] Defending Your Accounts file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch08_01.htm (8 of 9) [2002-04-12 10:44:24] Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [...]... inetd [44 11]: telnet [44 13] from 18.85.0.2 Jan 3 11:00:38 vineyard.net inetd [44 11]: finger [44 44] from 18.85.0.2 45 99 Jan 3 11:00 :42 vineyard.net inetd [44 11]: systat [44 46] from 18.85.0.2 46 00 If your version of inetd does not support logging (and even if it does), consider using the tcpwrapper, discussed in Chapter 22, Wrappers and Proxies 10.3.7 Other Logs There are many other possible log files on UNIX. .. [09/Apr/1995:11:55:37 - 040 0] "GET /unix- haterstitle.gif HTTP/1.0" 200 49 152 port15.ts1.msstate.edu - - [09/Apr/1995:11:55:38 - 040 0] "GET /simson/ HTTP/1.0" 200 1 248 mac-22.cs.utexas.edu - - [09/Apr/1995: 14: 32:50 - 040 0] "GET /unixhaters.html HTTP/1.0" 200 2871 2 04. 32.162.175 - - [09/Apr/1995: 14: 33:21 - 040 0] "GET /wedding/slides/020.jpeg HTTP/1.0" 200 9198 mac-22.cs.utexas.edu - - [09/Apr/1995: 14: 33:53 - 040 0] "GET /unixhaters-title.gif... NIS+ or DCE, which is less likely to have such limitations 7 .4 Software for Backups 8.2 Monitoring File Format [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch08_01.htm (9 of 9) [2002- 04- 12 10 :44 : 24] [Chapter 15] 15 .4 Security in Version 2 UUCP Simpo PDF Merge and Split Unregistered... Security 15.5 Security in BNU UUCP [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch15_ 04. htm (7 of 7) [2002- 04- 12 10 :44 :25] [Chapter 18] 18.3 Controlling Access to Files on Your Server Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 18 WWW Security. .. hours: #!/bin/ksh # set the following to indicate the user to notify of a new # security record typeset User=root cd /var/spool/uucp/.Admin if [[ -r security. mark ]] then if [[ security -nt security. mark ]] then comm -3 security security.mark | tee -a security. mark | /bin/mailx -s "New uucp security record" $User fi else touch security. mark fi 10.3.5 access_log Log File If you are running the NCSA HTTPD... missing username and the missing system name and gives access to the directory /usr/spool/uucppublic In other implementations of UNIX, two file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch15_ 04. htm (4 of 7) [2002- 04- 12 10 :44 :25] [Chapter 15] 15 .4 Security in Version 2 UUCP separate lines are required: The first line will suffice for the missing username, and another line, such... system name, it will have no effect 15 .4. 1 .4 Special permissions You may wish to make special directories on your system available to particular users on your system or to particular systems with which you communicate For example: file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch15_ 04. htm (3 of 7) [2002- 04- 12 10 :44 :25] [Chapter 15] 15 .4 Security in Version 2 UUCP Ugarp,garp /usr/spool/uucppublic... program such as Crack 18.2 Running a Secure Server 18 .4 Avoiding the Risks of Eavesdropping file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch18_03.htm (5 of 6) [2002- 04- 12 10 :44 :26] [Chapter 18] 18.3 Controlling Access to Files on Your Server [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] Simpo PDF Merge and Split Unregistered... from a computer running Ultrix V4.2A: BADSU: han /dev/ttyqc Wed Mar 8 16:36:29 1995 BADSU: han /dev/ttyqc Wed Mar 8 16:36 :40 1995 BADSU: rhb /dev/ttyvd Mon Mar 13 11 :48 :58 1995 file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch10_03.htm (1 of 5) [2002- 04- 12 10 :44 :27] [Chapter 10] 10.3 Program-Specific Log Files SU: rhb /dev/ttyvd Mon Mar 13 11 :49 :39 1995 Simpo the user han apparently... server: Sat Mar 11 20 :40 : 14 1995 329 CU-DIALUP-0525.CIT.CORNELL.EDU 42 6098 /pub/simson/scans/91.Globe.Arch.ps.gz b _ o a ckline@tc.cornell.edu ftp 0* Mon Mar 13 01:32:29 1995 9 slip-2-36.ots.utexas.edu 143 55 /pub/simson/clips/95.Globe.IW.txt a _ o a mediaman@mail.utexas.edu ftp 0 * Mon Mar 13 23:30 :42 1995 1 mac 52387 /u/beth/.newsrc a _ o r bethftp 0 * Tue Mar 14 00: 04: 10 1995 1 mac 5 248 8 /u/beth/.newsrc . two tags, <Directory directoryname> and </Directory>. For example: <Directory /nsa/manual> <Limit GET> order deny,allow deny from all allow from .nsa.mil </Limit> </Directory> If. implementations of UNIX, two [Chapter 15] 15 .4 Security in Version 2 UUCP file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch15_ 04. htm (4 of 7) [2002- 04- 12 10 :44 :25] Simpo. users● 15 .4. 1.1 USERFILE entries [Chapter 15] 15 .4 Security in Version 2 UUCP file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch15_ 04. htm (1 of 7) [2002- 04- 12 10 :44 :25] Simpo