Project: Indy/Indy attack/defense (IRIX 5.3 vs. IRIX 6.5)
The aim of this practical session, which lasts two hours, is to give some experience of how an admin typically uses a UNIX system to investigate a problem, locate information, construct and finally implement a solution. The example problem used will likely require:
the use of online information (man pages, online books, release notes, etc.),
writing scripts and exploiting shell script methods as desired,
the use of a wide variety of UNIX commands,
identifying and exploiting important files/directories,
and so on. A time limit on the task is included to provide some pressure, which often happens in real-world situations.
The problem situation is a simulated hacker attack/defense. Two SGI Indys are directly
connected together with an Ethernet cable; one Indy, referred to here as Indy X, is using an older version of IRIX called IRIX 5.3 (1995), while the other (Indy Y) is using a much newer version, namely IRIX 6.5 (1998).
Students will be split into two groups (A and B) of 3 or 4 persons each. For the first hour, group A is placed with Indy X, while group B is with Indy Y. For the second hour, the situation is reversed. Essentially, each group must try to hack the other group's system, locate and steal some key information (described below), and finally cripple the enemy machine. However, since both groups are doing this, each group must also defend against attack. Whether a group focuses on attack or defense, or a mixture of both, is for the group's members to decide during the
preparatory stage.
The first hour is is dealt with as follows:
For the first 35 minutes, each group uses the online information and any available notes to form a plan of action. During this time, the Ethernet cable between the Indys X and Y is not connected, and separate 'Research' Indys are used for this investigative stage in order to prevent any kind of preparatory measures. Printers will be available if printouts are desired.
After a short break of 5 minutes to prepare/test the connection between the two Indys and move the groups to Indys X and Y, the action begins. Each group must try to hack into the other group's Indy, exploiting any suspected weaknesses, whilst also defending against the other group's attack. In addition, the hidden data must be found, retrieved, and the enemy copy erased. The end goal is to shutdown the enemy system after retrieving the hidden data. How the shutdown is effected is entirely up to the group members.
At the end of the hour, the groups are reversed so that group B will now use an Indy running IRIX 5.3, while group A will use an Indy running IRIX 6.5. The purpose of this second attempt is to demonstrate how an OS evolves and changes over time with respect to security and OS features, especially in terms of default settings, online help, etc.
Indy Specifications.
Both systems will have default installations of the respective OS version, with only minor changes to files so that they are aware of each other's existence (/etc/hosts, and so on).
All systems will have identical hardware (133MHz R4600PC CPU, 64MB RAM, etc.) except for disk space: Indys with IRIX 6.5 will use 2GB disks, while Indys with IRIX 5.3 will use 549MB disks. Neither system will have any patches installed from any vendor CD updates.
The hidden data which must be located and stolen from the enemy machine by each group is the Blender V1.57 animation and rendering archive file for IRIX 6.2:
blender1.57_SGI_6.2_iris.tar.gz Size: 1228770 bytes.
For a particular Indy, the file will be placed in an appropriate directory in the file system, the precise location of which will only be made known to the group using that Indy - how an attacking group locates the file is up to the attackers to decide.
It is expected that groups will complete the task ahead of schedule; any spare time will be used for a discussion of relevant issues:
Reliability of relying on default settings for security, etc.
How to detect hacking in progress, especially if an unauthorised person is carrying out actions as root.
Whose responsibility is it to ensure security? The admin or the user?
If a hacker is 'caught', what kind of evidence would be required to secure a conviction?
How reliable is the evidence?
END OF COURSE.
Figure Index for Detailed Notes.
Day 1:
Figure 1. A typical root directory shown by 'ls'.
Figure 2. The root directory shown by 'ls -F /'.
Figure 3. Important directories visible in the root directory.
Figure 4. Key files for the novice administrator.
Figure 5. Output from 'man -f file'.
Figure 6. Hidden files shown with 'ls -a /'.
Figure 7. Manipulating an NFS-mounted file system with 'mount'.
Figure 8. The various available shells.
Figure 9. The commands used most often by any user.
Figure 10. Editor commands.
Figure 11. The next most commonly used commands.
Figure 12. File system manipulation commands.
Figure 13. System Information and Process Management Commands.
Figure 14. Software Management Commands.
Figure 15. Application Development Commands.
Figure 16. Online Information Commands (all available from the 'Toolchest')
Figure 17. Remote Access Commands.
Figure 18. Using chown to change both user ID and group ID.
Figure 19. Handing over file ownership using chown.
Day 2:
Figure 20. IP Address Classes: bit field and width allocations.
Figure 21. IP Address Classes: supported network types and sizes.
Figure 22. The contents of the /etc/hosts file used on the SGI network.
Figure 23. Yoda's /etc/named.boot file.
Figure 24. The example named.boot file in /var/named/Examples.
Figure 25. A typical find command.
Figure 26. Using cat to quickly create a simple shell script.
Figure 27. Using echo to create a simple one-line shell script.
Figure 28. An echo sequence without quote marks.
Figure 29. The command fails due to * being treated as a Figure 30. Using a backslash to avoid confusing the shell.
Figure 31. Using find with the -exec option to execute rm.
Figure 32. Using find with the -exec option to execute ls.
Figure 33. Redirecting the output from find to a file.
Figure 34. A simple script with two lines.
Figure 35. The simple rebootlab script.
Figure 36. The simple remountmapleson script.
Figure 37. The daily tasks of an admin.
Figure 38. Using df without options.
Figure 39. The -k option with df to show data in K.
Figure 40. Using df to report usage for the file
Figure 41. Using du to report usage for several directories/files.
Figure 42. Restricting du to a single directory.
Figure 43. Forcing du to ignore symbolic links.
Figure 44. Typical output from the ps command.
Figure 45. Filtering ps output with grep.
Figure 46. top shows a continuously updated output.
Figure 47. The IRIX 6.5 version of top, giving extra information.
Figure 48. System information from osview.
Figure 49. CPU information from osview.
Figure 50. Memory information from osview.
Figure 51. Network information from osview.
Figure 51. Miscellaneous information from osview.
Figure 52. Results from ttcp between two hosts on a 10Mbit network.
Figure 53. The output from netstat.
Figure 54. Example use of the ping command.
Figure 55. The output from rup.
Figure 56. The output from uptime.
Figure 57. The output from w showing current user activity.
Figure 58. Obtaining full domain addresses from w with the -W option.
Figure 59. The output from rusers, showing who is logged on where.
Day 3:
Figure 60. Standard UNIX security features.
Figure 61. Aspects of a system relevant to security.
Figure 62. Files relevant to network behaviour.
Figure 63. hosts.equiv files used by Ve24 Indys.
Figure 64. hosts.equiv file for yoda.
Figure 65. hosts.equiv file for milamber.
Figure 66. Additional line in /etc/passwd enabling NIS.
Figure 67. Typical output from fuser.
Figure 68. Blocking the use of finger in the /etc/inetd.conf file.
Figure 69. Instructing inetd to restart itself (using killall).