Назад в раздел
Dozens of such mailing lists now exist on the Internet (for a comprehensive list, see Appendix A, "How to Get More Information"). These lists operate almost completely free of human interaction or maintenance. List members forward their reports via e-mail, and this e-mail is distributed to the entire list, which can sometimes be many thousands of people worldwide. In addition, such lists are usually archived at one or more sites, which feature advanced search capabilities. These search capabilities allow any user, list member, or otherwise to search for inherent vulnerabilities in every operating system known to humankind.
In the beginning, however, there were no such databases. The databases did not exist largely because the knowledge did not exist. The process by which holes get discovered inherently involves the exploitation of such weaknesses. More simply put, crackers crack a machine here and a machine there. By and by, the weaknesses that were exploited in such attacks were documented (and in certain instances, eradicated by later, superior code). This process, as you might expect, took many years. The delay was based in part on lack of knowledge and in part on the unwillingness of many system administrators to admit their sites had been penetrated. (After all, no one wants to publicize that he implements poor security procedures.) So the stage is set. Picture a small, middle-class community with stately homes and nicely trimmed lawns. It is near midnight. The streets are empty; most of the windows in the neighborhood are dark, their shades drawn tight. One window is brightly lit, though, and behind it is a young man of 15 years; before him is a computer (for the sake of atmosphere, let's label it an old portable CoreData). The boy is dialing a list of telephone numbers given to him by a friend. These are known UNIX boxes sprinkled throughout a technology park a few miles away. Most of them accept a connection. The common response is to issue a login prompt. Each time the boy connects to such a machine, he tries a series of login names and passwords. He goes through a hundred or more before finally, he obtains a login shell. What happens then is up to him. It is hard to believe that early cracking techniques involved such laborious tasks. Depending on the operating system and the remote access software, one might have to type dozens of commands to penetrate a target. But, as much as crackers are industrious, they are also lazy. So, early on, the war dialer was developed. A war dialer consists of software that dials a user-specified range of telephone numbers searching for connectables (machines that will allow a remote user to log in). Using these tools, a cracker can scan an entire business exchange in several hours, identifying all hosts within that range. In this way, the task of locating targets was automated. Better yet, war dialers record the response they receive from each connect. This data is then exported to a human-readable file. Thus, in neatly written tables, one can tell not only which numbers connected, but also what type of connection was initiated (such as modem, 2400 baud or fax machine).
In essence, scanners operate much like war dialers with two exceptions:
Early scanners were probably very simplistic. I say probably because such programs were not released to the Internet community the way scanning tools are today (I therefore have no way of knowing what they looked like). Thus, when I write of early scanners, I mean basic programs written by system administrators for the purposes of checking their own networks. These were most likely UNIX shell scripts that attempted to connect on various ports, capturing whatever information was directed to the console or STDOUT. STDOUT refers to the output that one sees on the console or at a command prompt. In other words, it is the output of a given command. The STD refers to standard, and the OUT refers to output. STDOUT, therefore, is the standard output of any given command. The STDOUT result of a directory listing, for example, is a list of filenames and their sizes. The Attributes of a ScannerThe primary attributes of a scanner are
This process is not incredibly complex. At its most basic, it involves capturing the messages generated when one tries to connect to a particular service. To illustrate the process step by step, let's address these attributes one at a time. Locating a Potential TargetThe Internet is vast. There are literally millions of potential targets in the void. The problem facing modern crackers is how to find those targets quickly and effectively. Scanners are well suited for this purpose. To demonstrate how a scanner can find a potential target, determine what services it is running, and probe for weaknesses, let's pick on Silicon Graphics (SGI) for the remainder of this section. Here, you will see how scanners are regularly employed to automate human cracking tasks. A Hole Is DiscoveredIn late 1995, Silicon Graphics (SGI) shipped a large number of WebForce models. These were extremely powerful machines, containing special software to generate media-rich WWW pages. They ran IRIX, a proprietary form of UNIX, specifically designed for use with SGI graphics workstations. Certain versions of IRIX retained a default login for the line printer. That is, if a user initiated a Telnet session to one of these SGI boxes and logged in as lp, no password would be required. Typically, the cracker would be dropped to a shell prompt from which he or she could execute a limited number of commands. Most of these were standard shell commands, available to any user on the system. These did not require special privileges and performed only basic functions, such as listing directories, displaying the contents of files, and so forth. Using these commands, crackers could print the contents of the passwd file to the screen. Once they had obtained this display, they would highlight the screen, clip the contents, and paste them into a text editor on their local machine. They would save this information to a local file and subsequently crack the encrypted passwords from the SGI system.
News of this vulnerability spread quickly. Within days, the word was out: SGI WebForce machines could be attacked (and their security compromised) with little effort. For crackers, the next step was to find these machines. Looking for WebForce ModelsTo exploit this hole, crackers needed to find WebForce models. One way to do so was manually. For a time, search engines such as altavista.digital.com could be used to locate such machines en masse. This is because many of the WebForce models were administrated by those with strong knowledge of graphic arts and weak knowledge of security. These administrators often failed to institute even the most basic security measures. As such, many of these machines retained world-readable FTP directories. These directories were therefore visible to search engines across the Internet. The FTP directories of these SGI models contained standard, factory-default /etc/passwd files. Contained within these were the login names of system users. The majority of these login names were common to almost any distribution of UNIX. However, these passwd files also included unique login names. Specifically, they contained login names for several utilities and demo packages that shipped with the software. One of these was a login called EZSetup. Thus, a cracker needed only to issue the following search string into any well known search engine: EzSetup + root: lp: This would return a list of WebForce models. The cracker would then take that list and attempt to crack each machine. It was a quick and dirty way to collect a handful of potential targets. However, that trend didn't last long (about a month or so). Advisories were posted to the Net, explaining that world-readable directories were responsible for the compromise of SGI security. So crackers turned elsewhere. Some used the InterNIC database to find such machines (the WHOIS service). The WHOIS service, housed at internic.net, is a database of all registered machines currently on the Internet. One can query this database (to find out the network numbers or the owner's address of a given machine) by issuing a WHOIS instruction at a UNIX command prompt. The structure of such a command is whois mci.net. For those who do not use UNIX, one can either Telnet directly to InterNIC (internic.net) or use one of the utilities described later in this chapter. Many hosts included words within their registered names that suggested at least a fleeting probability that they owned an SGI, such as
The terms Indy and Indigo commonly appear on either the Web site or the directory structure of an SGI workstation. That is because the product line is based on the Indigo model, which is often referred to as the Indy product line. Some InterNIC entries also include the operating system type being run on the host. Thus, a search for the string IRIX could reveal a few machines. However, these methods were unreliable. For example, many versions of IRIX did not suffer from the lp bug (neither did every WebForce model). So, instead, many crackers employed scanners. Using Scanners to Uncover WebForce ModelsFinding WebForce models using a scanner was an easy task. A range of addresses (such as 199.171.190.0 to 199.171.200.0) would be picked out, perhaps randomly, perhaps not. The cracker would specify certain options. For example, the scan didn't need to have great depth (an issue we will be discussing momentarily). All it needed to do was check each address for a Telnet connection. For each successful connection, the scanner would capture the resulting text. Thus, a typical entry might look something like this: Trying 199.200.0.0 Connected to 199.200.0.0 Escape Character is "]" IRIX 4.1 Welcome to Graphics Town! Login: The resulting information would be written to a plain text file for later viewing. Talented crackers would write an ancillary program to automate the entire process. Here are the minimum functions that such a program would require:
The scan would run for several hours, after which the cracker would retrieve a list of compromised Indy machines. Later, perhaps at night (relative to the geographical location of the target host), the cracker would log in and being the process of grabbing the password files.
Of course, this is a very primitive example, but it illustrates how potential targets are sometimes found with scanners. Now I want to get more specific. Momentarily, you will examine various scanners currently available on the Internet. Before that, however, you need to distinguish between actual scanners and network utilities that are not scanners. Network UtilitiesSometimes people erroneously refer to network utilities as scanners. It is an easy mistake to make. In fact, there are many network utilities that perform one or more functions that are also performed during a bona fide scan. So, the distinction is significant only for purposes of definition. Because we are focusing on scanners, I would like to take a moment to illustrate the distinction. This will serve two purposes: First, it will more clearly define scanners. Second, it will familiarize you with the rich mixture of network resources available on the Internet. The network utilities discussed next run on a variety of platforms. Most of them are ported from UNIX environments. Each utility is valuable to hackers and crackers. Surprisingly, garden-variety network utilities can tell the user quite a bit, and these utilities tend to arouse less suspicion. In fact, many of them are totally invisible to the target host. This is in sharp contrast to most scanners, which leave a large footprint, or evidence of their existence, behind. In this respect, most of these utilities are suitable for investigating a single target host. (In other words, the majority of these utilities are not automated and require varying levels of human interaction in their operation.) hosthost is a UNIX-specific utility that performs essentially the same operation as a standard nslookup inquiry. The only real difference is that host is more comprehensive. Note, too, that various non-UNIX utilities discussed in the following pages also perform similar or equivalent tasks. host ranks as one of the ten most dangerous and threatening commands in the gamut. To demonstrate why, I pulled a host query on Boston University (BU.EDU). The command line given was host -l -v -t any bu.edu The output you are about to read is astonishing. A copious amount of information is available, including data on operating systems, machines, and the network in general. (Also, if you are deep into security, some preliminary assumptions might be made about trust relationships.) Examine a few lines. First, let's look at the basic information: Found 1 addresses for BU.EDU
Found 1 addresses for RS0.INTERNIC.NET
Found 1 addresses for SOFTWARE.BU.EDU
Found 5 addresses for RS.INTERNIC.NET
Found 1 addresses for NSEGC.BU.EDU
Trying 128.197.27.7
bu.edu 86400 IN SOA BU.EDU HOSTMASTER.BU.EDU(
961112121 ;serial (version)
900 ;refresh period
900 ;retry refresh this often
604800 ;expiration period
86400 ;minimum TTL
)
bu.edu 86400 IN NS SOFTWARE.BU.EDU
bu.edu 86400 IN NS RS.INTERNIC.NET
bu.edu 86400 IN NS NSEGC.BU.EDU
bu.edu 86400 IN A 128.197.27.7
This in itself is not damaging. It identifies a series of machines and their name servers. Most of this information could be collected with a standard WHOIS lookup. But what about the following lines: bu.edu 86400 IN HINFO SUN-SPARCSTATION-10/41 UNIX PPP-77-25.bu.edu 86400 IN A 128.197.7.237 PPP-77-25.bu.edu 86400 IN HINFO PPP-HOST PPP-SW PPP-77-26.bu.edu 86400 IN A 128.197.7.238 PPP-77-26.bu.edu 86400 IN HINFO PPP-HOST PPP-SW ODIE.bu.edu 86400 IN A 128.197.10.52 ODIE.bu.edu 86400 IN MX 10 CS.BU.EDU ODIE.bu.edu 86400 IN HINFO DEC-ALPHA-3000/300LX OSF1 Here, we are immediately aware that a DEC Alpha running OSF/1 is available (ODIE.bu.edu). And then: STRAUSS.bu.edu 86400 IN HINFO PC-PENTIUM DOS/WINDOWS BURULLUS.bu.edu 86400 IN HINFO SUN-3/50 UNIX (Ouch) GEORGETOWN.bu.edu 86400 IN HINFO MACINTOSH MAC-OS CHEEZWIZ.bu.edu 86400 IN HINFO SGI-INDIGO-2 UNIX POLLUX.bu.edu 86400 IN HINFO SUN-4/20-SPARCSTATION-SLC UNIX SFA109-PC201.bu.edu 86400 IN HINFO PC MS-DOS/WINDOWS UH-PC002-CT.bu.edu 86400 IN HINFO PC-CLONE MS-DOS SOFTWARE.bu.edu 86400 IN HINFO SUN-SPARCSTATION-10/30 UNIX CABMAC.bu.edu 86400 IN HINFO MACINTOSH MAC-OS VIDUAL.bu.edu 86400 IN HINFO SGI-INDY IRIX KIOSK-GB.bu.edu 86400 IN HINFO GATORBOX GATORWARE CLARINET.bu.edu 86400 IN HINFO VISUAL-X-19-TURBO X-SERVER DUNCAN.bu.edu 86400 IN HINFO DEC-ALPHA-3000/400 OSF1 MILHOUSE.bu.edu 86400 IN HINFO VAXSTATION-II/GPX UNIX PSY81-PC150.bu.edu 86400 IN HINFO PC WINDOWS-95 BUPHYC.bu.edu 86400 IN HINFO VAX-4000/300 OpenVMS I have omitted the remaining entries for sake of brevity. The inquiry produced a plain text file of some 70KB (over 1500 lines in all). The point here is this: Anyone, with a single command-line, can gather critical information on all machines within a domain. When crackers looks at the preceding information, they are really seeing this:
As you can easily see, even minor information about the operating system can lead to problems. In reality, the staff at BU.EDU has likely plugged all the holes mentioned here. But that doesn't mean that every host has. Most haven't. A host lookup takes less than three seconds, even when the network is under heavy system load. It is quick, legal, and extremely revealing.
TracerouteTraceroute's name is quite descriptive. In short, it traces the route between two machines. As explained in the man (manual) page:
This utility can be used to identify the location of a machine. Suppose, for example, that you are trying to track down an individual who posted from a box connected to his or her ISP via PPP. Suppose that the posting revealed nothing more than an IP address that, when run through a WHOIS search, produces nothing (that is, the address is not the address of a registered domain). You can find that machine by issuing Traceroute requests. The second to last entry is generally the network from which the activity originated. For example, examine this Traceroute trace going from a machine in France (freenix.fr) to mine: 1 193.49.144.224 (193.49.144.224) 3 ms 2 ms 2 ms 2 gw-ft.net.univ-angers.fr (193.49.161.1) 3 ms 3 ms 3 ms 3 angers.or-pl.ft.net (193.55.153.41) 5 ms 5 ms 5 ms 4 nantes1.or-pl.ft.net (193.55.153.9) 13 ms 10 ms 10 ms 5 stamand1.renater.ft.net (192.93.43.129) 25 ms 44 ms 67 ms 6 rbs1.renater.ft.net (192.93.43.186) 45 ms 30 ms 24 ms 7 raspail-ip2.eurogate.net (194.206.207.18) 51 ms 50 ms 58 8 raspail-ip.eurogate.net (194.206.207.58) 288 ms311 ms 287 ms 9 * Reston.eurogate.net (194.206.207.5) 479 ms 469 ms 10 gsl-sl-dc-fddi.gsl.net (204.59.144.199) 486 ms 490 ms 489 ms 11 sl-dc-8-F/T.sprintlink.net (198.67.0.8) 475 ms * 479 ms 12 sl-mae-e-H2/0-T3.sprintlink.net (144.228.10.42)498 ms 478 ms 13 mae-east.agis.net (192.41.177.145) 391 ms 456 ms 444 ms 14 h0-0.losangeles1.agis.net (204.130.243.45)714 ms 556 ms714 ms 15 pbi10.losangeles.agis.net (206.62.12.10) 554 ms 543 ms 505 ms 16 lsan03-agis1.pbi.net (206.13.29.2) 536 ms 560 ms * 17 * * * 18 pm1.pacificnet.net (207.171.0.51) 556 ms 560 ms 561 ms 19 pm1-24.pacificnet.net (207.171.17.25) 687 ms 677 ms 714 ms From this, it is clear that I am located in Los Angeles, California: pbi10.losangeles.agis.net (206.62.12.10) 554 ms 543 ms 505 ms and occupy a place at pacificnet.net: pm1.pacificnet.net (207.171.0.51) 556 ms 560 ms 561 ms Traceroute can be used to determine the relative network location of a machine in the void. Note that you needn't have UNIX (or a UNIX variant) to run Traceroute queries. There are Traceroute gateways all over the Internet. And, although these typically trace the route only between the Traceroute gateway and your target, they can at least be used to pin down the local host of an IP address.
rusers and fingerrusers and finger can be used together to glean information on individual users on a network. For example, a rusers query on the domain wizard.com returns this: gajake snark.wizard.com:ttyp1 Nov 13 15:42 7:30 (remote) root snark.wizard.com:ttyp2 Nov 13 14:57 7:21 (remote) robo snark.wizard.com:ttyp3 Nov 15 01:04 01 (remote) angel111 snark.wizard.com:ttyp4 Nov14 23:09 (remote) pippen snark.wizard.com:ttyp6 Nov 14 15:05 (remote) root snark.wizard.com:ttyp5 Nov 13 16:03 7:52 (remote) gajake snark.wizard.com:ttyp7 Nov 14 20:20 2:59 (remote) dafr snark.wizard.com:ttyp15Nov 3 20:09 4:55 (remote) dafr snark.wizard.com:ttyp1 Nov 14 06:12 19:12 (remote) dafr snark.wizard.com:ttyp19Nov 14 06:12 19:02 (remote) As an interesting exercise, compare this with finger information collected immediately after: user S00 PPP ppp-122-pm1.wiza Thu Nov 14 21:29:30 - still logged in user S15 PPP ppp-119-pm1.wiza Thu Nov 14 22:16:35 - still logged in user S04 PPP ppp-121-pm1.wiza Fri Nov 15 00:03:22 - still logged in user S03 PPP ppp-112-pm1.wiza Thu Nov 14 22:20:23 - still logged in user S26 PPP ppp-124-pm1.wiza Fri Nov 15 01:26:49 - still logged in user S25 PPP ppp-102-pm1.wiza Thu Nov 14 23:18:00 - still logged in user S17 PPP ppp-115-pm1.wiza Thu Nov 14 07:45:00 - still logged in user S-1 0.0.0.0 Sat Aug 10 15:50:03 - still logged in user S23 PPP ppp-103-pm1.wiza Fri Nov 15 00:13:53 - still logged in user S12 PPP ppp-111-pm1.wiza Wed Nov 13 16:58:12 - still logged in Initially, this information might not seem valuable. However, it is often through these techniques that you can positively identify a user. For example, certain portions of the Internet offer varying degrees of anonymity. Internet Relay Chat (IRC) is one such system. A person connecting with a UNIX-based system can effectively obscure his or her identity on IRC but cannot easily obscure the IP address of the machine in use. Through sustained use of both the finger and rusers commands, you can pin down who that user really is.
Nevertheless, this explanation doesn't reveal the value of these utilities in relation to cracking. In the same way that one can finger a user, one can also finger several key processes. Table 9.2 contains some examples. Table 9.2. Processes that can be fingered.
By directing finger inquiries on these accounts, you can glean valuable information about them, such as their base directory as well as the last time they were used or logged in. Thus, rusers, when coupled with finger, can produce interesting and often revealing results. I realize, of course, that you might trivialize this information. For, what value is there in knowing when and where logins take place? In fact, there are many instances in which such information has value. For example, if you are truly engaged in cracking a specific system, this information can help you build a strong database of knowledge about your target. By watching logins, you can effectively identify trust relationships between machines. You can also reliably determine the habits of the local users. All these factors could have significant value. ShowmountShowmount reveals some very interesting information about remote hosts. Most importantly, invoked with the -e command line option, showmount can provide a list of all exported directories on a given target. These directories might or might not be mountable from anywhere on the Internet. On Other PlatformsNone of the mentioned UNIX utilities are scanners. However, they do reveal important information about the target machine. And not surprisingly, the computing community has ported quite a few of these utilities to other platforms (not everyone has a UNIX workstation in their living room). It wouldn't be fair to continue without briefly covering those ported utilities here. On Windows 95Windows 95 now supports many network analysis utilities. Some of these are straight ports from UNIX commands, and others are programs built from the ground up. In both cases, the majority of these tools are shareware or freeware. You can use these tools to learn much about networking. NetScan Tools The NetScan Tools suite contains a series of UNIX utilities ported to Windows 95. Its development team claims that by utilizing ping, network administrators can identity unauthorized machines utilizing IP addresses on their subnets. The program also contains ports of WHOIS, finger, ping, and Traceroute.
Network Toolbox Network Toolbox is very similar to the Netscan Tools suite. It consists of a port of nine separate UNIX utilities. This utility has an interesting feature called IP Address Search, which allows the user to search for machines within a given range of IP addresses. Otherwise, it has the usual fare: finger, DNS, WHOIS, and so on. One special amenity of this suite is that it is exceedingly fast. This utility is discussed in greater detail later in this chapter.
TCP/IP Surveyor This tool is quite impressive; not only does it gather information about networks and reachable machines, it formats it into a graphical representation that maps routers, workstations, and servers.
On MacintoshThere has been a sharp increase in development of network analysis tools on the Macintosh platform. Many of these applications are first rate and, in traditional Mac platform style, are extremely easy to use. MacTCP Watcher This utility provides ping, DNS lookups, and general monitoring of connections initiated by protocols within the TCP/IP suite.
Query It! Query It! is a solid utility that performs basic nslookup inquiries. It generates information that is very similar to that generated using the host command.
WhatRoute WhatRoute is a port of the popular UNIX utility Traceroute.
On AS/400The AS/400 platform, as of AS/400 V3R1 (and Client Access/400), has excellent internal support for most TCP/IP utilities, including ping and netstat.
These utilities will always be available to users, even if scanners are not. Moreover, because the Internet is now traveled by more and more new users, utilities to analyze network connections will be commonplace on all platforms. The ScannersHaving discussed various network analysis utilities, we can now move on to bona fide scanners. Let's take a look at today's most popular scanners. NSS (Network Security Scanner)NSS (Network Security scanner) is a very obscure scanner. If you search for it using a popular search engine, you will probably find fewer than 20 entries. This doesn't mean NSS isn't in wide use. Rather, it means that most of the FTP sites that carry it are shadowed or simply unavailable via archived WWW searches. NSS differs from its counterparts in several ways, the most interesting of which is that it's written in Perl. (SATAN is also partially written in Perl. ISS and Strobe are not.) This is interesting because it means that the user does not require a C compiler. This might seem like a small matter, but it's not. Crackers and hackers generally start out as students. Students may acquire shell accounts on UNIX servers, true, but not every system administrator allows his or her users access to a C compiler. On the other hand, Perl is so widely used for CGI programming that most users are allowed access to Perl. This makes NSS a popular choice. (I should explain that most scanners come in raw, C source. Thus, a C compiler is required to use them.) Also, because Perl is an interpreted (as opposed to compiled) language, it allows the user to make changes with a few keystrokes. It is also generally easier to read and understand. (Why not? It's written in plain English.) To demonstrate the importance of this, consider the fact that many scanners written in C allow the user only minimal control over the scan (if the scanner comes in binary form, that is). Without the C source code, the user is basically limited to whatever the programmer intended. Scanners written in Perl do not generally enforce such limitations and are therefore more easily extensible (and perhaps portable to any operating system running Perl 4 or better). NSS was reportedly written on the DEC platform (DecStation 5000 and Ultrix 4.4). It generally works out the box on SunOS 4.1.3 and IRIX 5.2. On other platforms, it may require basic or extensive porting. The basic value of NSS is its speed. It is extremely fast. Routine checks that it can perform include the following:
As you might guess, some or most of these checks (except the Hosts.equiv query) can be conducted by hand by any user, even without root privileges. Basically, NSS serves the same function as most scanners: It automates processes that might otherwise take a human weeks to complete. NSS comes (most often) as a tarred, g'zipped file. (In other words, it is a zipped archive created with gzip.exe, a popular compression tool similar to pkzip.exe.) With the original distribution, the author discussed the possibility of adding greater functionality, including the following features:
Although this is not an exhaustive treatment of NSS, there are some minor points I can offer here:
StrobeStrobe (The Super Optimized TCP Port Surveyor) is a TCP port scanner that logs all open ports on a given machine. Strobe is fast (its author claims that an entire small country can be scanned within a reasonable period of time). The key feature of Strobe is that it can quickly identify what services are being run on a given target (so quickly, in fact, that it takes less than 30 seconds to pin down a server, even with a 28.8 modem connection to the Internet). The key drawback of Strobe is that such information is limited. At best, a Strobe attack provides the cracker with a rough guideline, a map of what services can be attacked. Typical output from a Strobe scan looks like this: localhost echo 7/tcp Echo [95,JBP] localhost discard 9/tcp Discard [94,JBP] localhost systat 11/tcp Active Users [89,JBP] localhost daytime 13/tcp Daytime [93,JBP] localhost netstat 15/tcp Netstat localhost chargen 19/tcp Character Generator [92,JBP] localhost ftp 21/tcp File Transfer [Control] [96,JBP] localhost telnet 23/tcp Telnet [112,JBP] localhost smtp 25/tcp Simple Mail Transfer [102,JBP] localhost time 37/tcp Time [108,JBP] localhost finger 79/tcp Finger [52,KLH] localhost pop3 0/tcp Post Office Protocol-Version 3 122 localhost sunrpc 111/tcp SUN Remote Procedure Call [DXG] localhost auth 113/tcp Authentication Service [130,MCSJ] localhost nntp 119/tcp Network News Transfer Protocol 65,PL4 As you can see, the information is purely diagnostic in character (for example, there are no probes for particular holes). However, Strobe makes up for this with extensive command-line options. For example, in scanning hosts with large numbers of assigned ports, you can disable all duplicate port descriptions. (Only the first definition is printed.) Other amenities include
Combining all these options produces a very controllable and configurable scan. Strobe generally comes as a tarred and g'zipped file. Contained within that distribution is a full man page and the binary.
PointersIn the unlikely event you acquire Strobe without also acquiring the man page, there is a known problem with Solaris 2.3. To prevent problems (and almost certainly a core dump), you must disable the use of getpeername(). This is done by adding the -g flag on the command line. Also, although Strobe does not perform extensive tests on remote hosts, it leaves just as large a footprint as early distributions of ISS. A host that is scanned with Strobe will know it (this will most likely appear as a run of connect requests in the /var/adm/messages file). SATAN (Security Administrator's Tool for Analyzing Networks)SATAN is a computing curiosity, as are its authors. SATAN was released (or unleashed) on the Internet in April, 1995. Never before had a security utility caused so much controversy. Newspapers and magazines across the country featured articles about it. National news broadcasts warned of its impending release. An enormous amount of hype followed this utility up until the moment it was finally posted to the Net. SATAN is, admittedly, quite a package. Written for UNIX workstations, SATAN was--at the time of its release--the only X Window System-based security program that was truly user friendly. It features an HTML interface, complete with forms to enter targets, tables to display results, and context-sensitive tutorials that appear when a hole has been found. It is--in a word--extraordinary. SATAN's authors are equally extraordinary. Dan Farmer and Weitse Venema have both been deeply involved in security. Readers who are unfamiliar with SATAN might remember Dan Farmer as the co-author of COPS, which has become a standard in the UNIX community for checking one's network for security holes. Venema is the author of TCP_Wrapper. (Some people consider TCP_Wrapper to be the grandfather of firewall technology. It replaces inetd as a daemon, and has strong logging options.) Both men are extremely gifted programmers, hackers (not crackers), and authorities on Internet security. SATAN was designed only for UNIX. It is written primarily in C and Perl (with some HTML thrown in for user friendliness). It operates on a wide variety of UNIX flavors, some with no porting at all and others with moderate to intensive porting.
The package comes tarred and zipped and is available all over the world. As the name of the program (Security Administrator's Tool for Analyzing Networks) suggests, it was written for the purpose of improving network security. As such, not only must one run it in a UNIX environment, one must run it with root privileges.
Once again, these are known holes. That is, SATAN doesn't do anything that a cracker could not ultimately do by hand. However, SATAN does perform these probes automatically and what's more, it provides this information in an extremely easy-to-use package.
The Process: InstallationSATAN unarchives like any other utility. Each platform may differ slightly, but in general, the SATAN directory will extract to /satan-1.1.1. The first step (after reading the documentation) is to run the Perl script reconfig. This script searches for various components (most notably, Perl) and defines directory paths. The script reconfig will fail if it cannot identify/define a browser. Those folks who have installed their browser in a nonstandard directory (and have failed to set that variable in the PATH) will have to set that variable manually. Also, those who do not have DNS available (they are not running DNS on their own machine) must set this in /satan-1.1.1/conf/satan.cf as follows: $dont_use_nslookup = 1; Having resolved all the PATH issues, the user can run a make on the distribution (make IRIX or make SunOS). I suggest watching the compile very closely for errors.
JakalJakal is a stealth scanner. That is, it will scan a domain (behind a firewall) without leaving any trace of the scan. According to its authors, all alpha test sites were unable to log any activity (although it is reported in the documentation from the authors that "Some firewalls did allow SYN|FIN to pass through"). Stealth scanners are a new phenomenon, their incidence rising no doubt with the incidence of firewalls on the Net. It's a relatively new area of expertise. So if you test Jakal and find that a few logs appear, don't be unforgiving. Stealth scanners work by conducting half scans, which start (but never complete) the entire SYN|ACK transaction with the target host. Basically, stealth scans bypass the firewall and evade port scanning detectors, thus identifying what services are running behind that firewall. (This includes rather elaborate scan detectors such as Courtney and Gabriel. Most of these detection systems respond only to fully established connections.)
IdentTCPscanIdentTCPscan is a more specialized scanner. It has the added functionality of picking out the owner of a given TCP port process. That is, it determines the UID of the process. For example, running IdentTCPscan against my own machine produced the following output: Port: 7 Service: (?) Userid: root Port: 9 Service: (?) Userid: root Port: 11 Service: (?) Userid: root Port: 13 Service: (?) Userid: root Port: 15 Service: (?) Userid: root Port: 19 Service: (?) Userid: root Port: 21 Service: (?) Userid: root Port: 23 Service: (?) Userid: root Port: 25 Service: (?) Userid: root Port: 37 Service: (?) Userid: root Port: 79 Service: (?) Userid: root Port: 80 Service: (?) Userid: root Port: 110 Service: (?) Userid: root Port: 111 Service: (?) Userid: root Port: 113 Service: (?) Userid: root Port: 119 Service: (?) Userid: root Port: 139 Service: (?) Userid: root Port: 513 Service: (?) Userid: root Port: 514 Service: (?) Userid: root Port: 515 Service: (?) Userid: root Port: 540 Service: (?) Userid: root Port: 672 Service: (?) Userid: root Port: 2049 Service: (?) Userid: root Port: 6000 Service: (?) Userid: root This utility has a very important function. By finding the UID of the process, misconfigurations can be quickly identified. For example, examine this output. Seasoned security professionals will know that line 12 of the scan shows a serious misconfiguration. Port 80 is running a service as root. It happens that it is running HTTPD. This is a security problem because any attacker who exploits weaknesses in your CGI can run his or her processes as root as well. I have tried many scanners. IdentTCPscan is extremely fast and as such, it is a powerful and incisive tool (a favorite of crackers). The utility works equally well on a variety of platforms, including Linux, BSDI, and SunOS. It generally comes as a compressed file containing the source code. It is written in C and is very compact. It also requires minimal network resources to run. It will build without event using most any C compiler.
CONNECTCONNECT is a bin/sh script. Its purpose is to scan subnets for TFTP servers. (As you might surmise, these are difficult to find. TFTP is almost always disabled these days.) This scanner scans trailing IP addresses recursively. For this reason, you should send the process into the background (or go get yourself a beer, have some lunch, play some golf). This scanner is of relatively little importance because TFTP is a lame protocol. There isn't much to gain. (Although, if the sysad at that location is negligent, you might be able to obtain the /etc/passwd file. Don't count on it, however. These days, the odds of finding both an open TFTP server and a non-shadowed passwd file on the same machine are practically nil.)
FSPScanFSPScan scans for FSP servers. FSP stands for File Service Protocol, an Internet protocol much like FTP. It provides for anonymous file transfers and reportedly has protection against network overloading (for example, FSP never forks). Perhaps the most security-aware feature of FSP is that it logs the incoming user's hostname. This is considered superior to FTP, which requests the user's e-mail address (which, in effect, is no logging at all). FSP was popular enough, now sporting GUI clients for Windows and OS/2. What's extraordinary about FSPScan is that it was written by one of the co-authors of FSP! But then, who better to write such a utility?
XSCANXSCAN scans a subnet (or host) for X server vulnerabilities. At first glance, this doesn't seem particularly important. After all, most other scanners do the same. However, XSCAN includes an additional functionality: If it locates a vulnerable target, it immediately starts logging the keystrokes at that terminal. Other amenities of XSCAN include the capability to scan multiple hosts in the same scan. These can be entered on the command line as arguments. (And you can specify both hosts and subnets in a kind of mix-and-match implementation.) The source for this utility is included on the CD-ROM that accompanies this book.
Our Sample ScanOur sample scan will be generated using a product called SAFEsuite. Many of you might be familiar with this product, which was developed by Internet Security Systems. ISS is extremely well known on the Net for a product called ISS. This product (the Internet Security Scanner) was among the first automated scanners to sell commercially. From ISS to SAFEsuiteThe first release of ISS stirred some controversy. Many people felt that releasing such a tool free to the Internet community would jeopardize the network's already fragile security. (The reaction to Dan Farmer's SATAN was very similar.) After all, why release a product that automatically detects weaknesses in a remote target? In the manual pages for ISS, the author (Christopher Klaus) addressed this issue by writing:
In early distributions of ISS, the source code for the program was included in the package. (This sometimes came as a shar or shell archive file and sometimes not.) For those interested in examining the components that make a successful and effective scanner, the full source for the older ISS is included on the CD-ROM that accompanies this book. ISS has the distinction of being one of the mainstays of Internet security. It can now be found at thousands of sites in various forms and versions. It is a favorite of hackers and crackers alike, being lightweight and easy to compile on almost any UNIX-based platform. Since the original release of ISS, the utility has become incredibly popular. The development team at ISS has carried this tradition of small, portable security products onward, and SAFEsuite is its latest effort. It is a dramatic improvement over earlier versions. SAFEsuite consists of several scanners:
SAFEsuite is similar to SATAN in that the configuration, management, implementation, and general use of the program can be done in a GUI environment. This saves enormous time and effort. It also allows resulting information to be viewed quickly and conveniently. However, SAFEsuite has an additional attribute that will make it quite popular: It runs on a Microsoft platform. SAFEsuite has been developed for use on Microsoft Windows NT. This is of some significance. Only recently has NT been recognized by the UNIX community as an acceptable server platform. This may in part be attributed to NT's new C2 security rating. In any event, ISS has broken through the barrier by providing a tested security tool for a large portion of the Microsoft-based community. I consider this a rather far-sighted undertaking on the part of the development team at ISS. SAFEsuite performs a wide variety of attacks on the specified network. These include diagnostic routines on all of the following services:
Curiously, the ISS development team also managed to add support for analysis of a host's vulnerability to IP spoofing and denial-of-service attacks. (This is impressive, although one wonders what significance there is in knowing that you're vulnerable to a DoS attack. Few platforms are immune to this type of attack.) According to the folks at ISS:
In any case, those of you who have used earlier versions of ISS will find that the SAFEsuite distribution is slightly different. For example, earlier versions (with the exception of one trial distribution) were not for use in a GUI. For that reason, I will quickly cover the scan preparation in this tool. Perhaps the most dramatic change from the old ISS to the new SAFEsuite is that SAFEsuite is a commercial product. Notes on the Server ConfigurationFor the purposes of demonstrating both target and attacker views of a scan, I established a server with the hostname SamsHack. It was configured as follows:
I chose Linux because it provides strong logging capabilities. Default logging in Linux in done via a file called /var/adm/messages. (This might differ slightly, depending on the Linux distribution. Red Hat Linux, for example, has a slightly different directory structure from Slackware. In that distribution, you will probably be focusing on the file /var/logs/messages.) The /var/adm/messages file records status reports and messages from the system. These naturally include the boot routine and any problems found there, as well as dozens of other processes the user might initiate. (In this case, the /var/adm/messages file will log our server's responses to the SAFEsuite scan.)
System RequirementsAt the time this chapter was written, the Windows NT version of SAFEsuite was still in development. Therefore, NT users should contact the development team at ISS for details on how to install on that platform. The system requirements are shown in Table 9.3. Table 9.3. Installation requirements for SAFEsuite.
SAFEsuite runs on many platforms, including but not limited to the following:
Installing the suite is straightforward. It unpacks like any standard UNIX utility. It should be copied to a directory of your choice. Go to that directory and extract the archive, using the following command: tar -xvf iss-xxx.tar After you untar the archive, you will see a file labeled iss.install. This is a Bourne shell script that will perform the installation. (This mainly involves extracting the distribution disks and the help documentation, which is in HTML format.) Run this file to complete the basic installation process by executing the command sh iss.install. The chief executable is the xiss file, which will launch SAFEsuite in the X Window System, OpenWindows, or any compatible windowing system for UNIX. ConfigurationIn this scan, I used the defaults to simplify the interpretation of output (by output, I mean not only the information that the scan gleans from our server, but also the footprint, or trail, that the scanner leaves behind). Nevertheless, the configuration options in SAFEsuite are very incisive. If you decide to use SAFEsuite, you might want to take advantage of those incisive options. If so, you need to call the Scanner Configuration window (see Figure 9.1). Some of the options here are similar to options formerly expressed with the command-line interface (such as the outfile, or log file, which contains all information recorded during the scan; this was formerly assigned with the -o option). Other options are entirely new, such as the option for specifying a Web browser. Figure 9.1.
Special Features The options to specify additional ports is particularly interesting. So is the capability to add modules. SAFEsuite appears to be quite extensible. Thus, if you hack specialized code for probing parts of the system not covered by SAFEsuite, you can include these modules into the scan (as you can with Farmer and Venema's SATAN).
The ScanThe scan took approximately two minutes. For those of you who are interested, the network resources consumed were relatively slim. For example, while the scan occurred, I was also running several other applications. The scan's activity was hardly noticeable. The results of the scan were enlightening. The SamsHack server was found to be vulnerable in several areas. These vulnerabilities ranged from trivial to serious.
The rlogin BugOne of the tests SAFEsuite runs is for a bug in the remote login program called rlogin. Was the SamsHack server vulnerable to rlogin attack? No. # Rlogin Binding to Port # Connected to Rlogin Port # Trying to gain access via Rlogin 127.0.0.1: ---- rlogin begin output ---- 127.0.0.1: ---- rlogin end output ---- # Rlogin check complete, not vulnerable. In other areas, however, the SamsHack server was vulnerable to attack. These vulnerabilities were critical. Take a close look at the following log entry: # Time Stamp(555): Rsh check: (848027962) Thu Nov 14 19:19:22 # Checking Rsh For Vulnerabilities # Rsh Shell Binding to Port # Sending command to Rsh 127.0.0.1: bin/bin logged in to rsh 127.0.0.1: Files grabbed from rsh into `./127.0.0.1.rsh.files' 127.0.0.1: Rsh vulnerable in hosts.equiv # Completed Checking Rsh for Vulnerability You'll see that line 6 suggests that some files were grabbed and saved. Their output was sent to a file called 127.0.0.1.rsh.files. Can you guess what file or files were saved to that file? If you guessed the /etc/passwd file, you are quite correct. Here are the contents of 127.0.0.1.rsh.files: root:bBndEhmQlYwTc:0:0:root:/root:/bin/bash bin:*:1:1:bin:/bin: daemon:*:2:2:daemon:/sbin: adm:*:3:4:adm:/var/adm: lp:*:4:7:lp:/var/spool/lpd: sync:*:5:0:sync:/sbin:/bin/sync shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown halt:*:7:0:halt:/sbin:/sbin/halt mail:*:8:12:mail:/var/spool/mail: news:*:9:13:news:/usr/lib/news: uucp:*:10:14:uucp:/var/spool/uucppublic: operator:*:11:0:operator:/root:/bin/bash games:*:12:100:games:/usr/games: man:*:13:15:man:/usr/man: postmaster:*:14:12:postmaster:/var/spool/mail:/bin/bash nobody:*:-1:100:nobody:/dev/null: ftp:*:404:1::/home/ftp:/bin/bash guest:*:405:100:guest:/dev/null:/dev/null FTP also proved to be vulnerable (although the importance of this is questionable): 127.0.0.1: ---- FTP version begin output ---- SamsHack FTP server (Version wu-2.4(1) Tue Aug 8 15:50:43 CDT 1995) ready. 127.0.0.1: ---- FTP version end output ---- 127.0.0.1: Please login with USER and PASS. 127.0.0.1: Guest login ok, send your complete e-mail address as password. 127.0.0.1: Please login with USER and PASS. 127.0.0.1: ANONYMOUS FTP ALLOWED 127.0.0.1: Guest login ok, access restrictions apply. 127.0.0.1: "/" is current directory. 127.0.0.1: iss.test: Permission denied. 127.0.0.1: iss.test: Permission denied. (Delete) 127.0.0.1: Entering Passive Mode (127,0,0,1,4,217) 127.0.0.1: Opening ASCII mode data connection for /bin/ls. 127.0.0.1: Transfer complete. 127.0.0.1: Entering Passive Mode (127,0,0,1,4,219) 127.0.0.1: Opening ASCII mode data connection for /etc/passwd (532 bytes). 127.0.0.1: Transfer complete. 127.0.0.1: Files grabbed via FTP into ./127.0.0.1.anonftp.files 127.0.0.1: Goodbye. As you might have surmised, the passwd file for FTP was grabbed into a file. Thus, in this chapter, we have identified at least three serious security weaknesses in SamsHack.net:
These weaknesses are common to many operating systems in their out-of-the-box state. In fact, the Linux distribution used to demonstrate this scan was out of the box. I made no modifications to the installation whatsoever. Therefore, you can conclude that out-of-the-box Slackware distributions are not secure. I have included the entire scan log on the CD-ROM that accompanies this book. Printing it here would be unreasonable, as it amounts to over 15 pages of information. You have just seen the basics of scanning a single host. But in reality, a cracker might scan as many as 200 hosts in a single evening. For such widespread activity, more resources are required (greater bandwidth, more RAM, and a more powerful processor). But resources are not the cracker's only concern; such a scan leaves a huge footprint. We've seen this scan from the cracker's perspective. Now, let's look at it from the victim's perspective. The Other Side of the FenceAs I noted earlier, logging capabilities are extremely important. Logs can often determine not only when and how an attack took place, but also from where the attack originated. On November 10, 1996, I conducted a scan identical to the one shown previously, which was performed on November 14, 1996. The only difference between the two scans is that on the November 10th scan, I employed not one but several scanners against the SamsHack server. Those scans and their activities were reported to the system to the file /var/adm/messages. Take a look at the output: Nov 10 21:29:38 SamsHack ps[159]: connect from localhost Nov 10 21:29:38 SamsHack netstat[160]: connect from localhost Nov 10 21:29:38 SamsHack in.fingerd[166]: connect from localhost Nov 10 21:29:38 SamsHack wu.ftpd[162]: connect from localhost Nov 10 21:29:38 SamsHack in.telnetd[163]: connect from localhost Nov 10 21:29:39 SamsHack ftpd[162]: FTP session closed Nov 10 21:29:39 SamsHack in.pop3d[169]: connect from localhost Nov 10 21:29:40 SamsHack in.nntpd[170]: connect from localhost Nov 10 21:29:40 SamsHack uucico[174]: connect from localhost Nov 10 21:29:40 SamsHack in.rlogind[171]: connect from localhost Nov 10 21:29:40 SamsHack in.rshd[172]: connect from localhost Nov 10 21:29:40 SamsHack telnetd[163]: ttloop: read: Broken pipe Nov 10 21:29:41 SamsHack nntpd[170]: localhost connect Nov 10 21:29:41 SamsHack nntpd[170]: localhost refused connection Nov 10 21:29:51 SamsHack ps[179]: connect from localhost Nov 10 21:29:51 SamsHack netstat[180]: connect from localhost Nov 10 21:29:51 SamsHack wu.ftpd[182]: connect from localhost Nov 10 21:29:51 SamsHack in.telnetd[183]: connect from localhost Nov 10 21:29:51 SamsHack in.fingerd[186]: connect from localhost Nov 10 21:29:51 SamsHack in.pop3d[187]: connect from localhost Nov 10 21:29:52 SamsHack ftpd[182]: FTP session closed Nov 10 21:29:52 SamsHack in.nntpd[189]: connect from localhost Nov 10 21:29:52 SamsHack nntpd[189]: localhost connect Nov 10 21:29:52 SamsHack nntpd[189]: localhost refused connection Nov 10 21:29:52 SamsHack uucico[192]: connect from localhost Nov 10 21:29:52 SamsHack in.rshd[194]: connect from localhost Nov 10 21:29:52 SamsHack in.rlogind[193]: connect from localhost Nov 10 21:29:53 SamsHack login: ROOT LOGIN ON tty2 Nov 10 21:34:17 SamsHack ps[265]: connect from pm7-6.pacificnet.net Nov 10 21:34:17 SamsHack netstat[266]: connect from pm7-6.pacificnet.net Nov 10 21:34:17 SamsHack wu.ftpd[268]: connect from pm7-6.pacificnet.net Nov 10 21:34:22 SamsHack ftpd[268]: FTP session closed Nov 10 21:34:22 SamsHack in.telnetd[269]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.fingerd[271]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack uucico[275]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.pop3d[276]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.rlogind[277]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.rshd[278]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.nntpd[279]: connect from pm7-6.pacificnet.net Nov 10 21:34:28 SamsHack telnetd[269]: ttloop: read: Broken pipe Nov 10 21:34:28 SamsHack nntpd[279]: pm7-6.pacificnet.net connect Nov 10 21:34:28 SamsHack nntpd[279]: pm7-6.pacificnet.net refused connection Nov 10 21:34:33 SamsHack rlogind[277]: Connection from 207.171.17.199 on illegal port The first thing I want you to notice is the time. The first line of this log excerpt reports the time as 21:29:38. The last line of the scan reports 21:34:33. Thus, the entire range of activity occurred within a five-minute period. Next, I want you to take a good look at what's happening here. You will see that nearly every open, available port has been attacked (some of them more than once). And, on at least one occasion, the IP address from which the attack originated appears clearly within the log (specifically, on the last line of the small snippet of log I have provided). The line appears as Nov 10 21:34:33 SamsHack rlogind[277]: Connection from 207.171.17.199 on illegal port It is quite obvious that any system administrator looking for attacks like this one needn't look far. Keep in mind that in this example, I was not running any special logging utilities or wrappers. Just plain, old logging, which is on by default in a factory install. So the average system administrator needn't do more than search the /var/adm/message file (or its equivalent) for runs of connection requests. However, you will be surprised to know that an overwhelming number of system administrators do not do this on a regular basis. Other PlatformsScanners have traditionally been designed for UNIX. But what about other operating systems? There are two aspects to consider about scanners with regard to operating system. The first is what operating system the target machine runs. The second is what operating system the attacking machine runs. I want to discuss these in relation to platforms other than UNIX. The Target Machine As Another PlatformScanning platforms other than UNIX might or might not be of significant value. At least, this is true with respect to deployment of TCP port scanners. This is because the majority of non-UNIX platforms that support TCP/IP support only portions of TCP/IP. In fact, some of those TCP/IP implementations are quite stripped down. Frankly, several TCP/IP implementations have support for a Web server only. (Equally, even those that have support for more might not evidence additional ports or services because these have been disabled.) This is the main reason that certain platforms, like the Macintosh platform, have thus far seen fewer intrusions than UNIX-based operating systems. The fewer services you actually run, the less likely it is that a hole will be found. That is common sense. Equally, many platforms other than UNIX do support extensive TCP/IP. AS/400 is one such platform. Microsoft Windows NT (with Internet Information Server) is another. Certainly, any system that runs any form of TCP/IP could potentially support a wide range of protocols. Novell NetWare, for example, has long had support for TCP/IP. It boils down to this: The information you will reap from scanning a wide variety of operating systems depends largely on the construct of the /etc/services file or the targeted operating system's equivalent. This file defines what ports and services are available. This subject will discussed later, as it is relevant to (and implemented differently on) varied operating systems. In Chapter 18, "Novell," for example, I examine this file and its uses on the Novell NetWare platform. The Scanning Machine on Another PlatformUsing a platform other than UNIX to perform a scan is another matter. Port scanning utilities for other platforms are available and, as you might surmise, we're going to use one momentarily. The product I will be using to demonstrate this process runs in Windows 95. It is called Network Toolbox. Network ToolboxNetwork Toolbox is a TCP/IP utility for Windows 95. (This program was discussed earlier in this chapter in the section on network analysis utilities.) It was developed by J. River Co. of Minneapolis, Minnesota (it can be reached at info@jriver.com). The utility includes a port scanner. I will not conduct an exhaustive analysis of other utilities available within the application (though there are many, including ping). Instead, I would like to give you a quick start. Figure 9.2 shows opening screen of the application.
port: 9 discard Service available port: 13 daytime Service available port: 21 ftp Service available port: 23 telnet Service available port: 25 smtp Service available port: 37 time Service available port: 79 finger Service available port: 80 http Service available port:110 pop3 Service available port:111 portmap Service available port:512 exec Service available port:513 login Service available port:514 shell Service available port:540 uucp Service available
Figure 9.2. Figure 9.3.
Figure 9.4.
Figure 9.5. The port scanner in Network Toolbox is fast and accurate. The average scan takes less than a minute. I would characterize this as a good product. Moreover, it provides ports of several other UNIX utilities of interest. The information gleaned using this utility is quite similar to that obtained using Strobe. It will not tell you the owner of a process, nor does the Network Toolbox port scanner try doors or windows. (In other words, it makes no attempt to penetrate the target network.) However, it is valuable because it can quickly determine what processes are now running on the target. SummaryIn this chapter, you have learned a little bit about scanners, why they were developed, and how they work. But education about scanners doesn't stop there. You might be surprised to know that new scanners crop up every few months or so, and these are usually more functional than their predecessors. Internet security is a constantly changing field. As new holes are discovered, they are posted to various mailing lists, alert rosters, and newsgroups. Most commonly, such alerts end up at CERT or CIAC. Crackers and hackers alike belong to such mailing lists and often read CERT advisories. Thus, these new holes become common knowledge often minutes or hours after they are posted. As each new hole is uncovered, capabilities to check for the new hole are added to existing scanners. The process is not particularly complex. In most cases, the cracker need only write a small amount of additional code, which is then pasted into the existing source code of his or her scanner. The scanner is then recompiled and voilà! The cracker is ready to exploit a new hole on a wide scale. This is a never-ending process. System administrators must learn about and implement scanners. It is a fact of life. Those who fail to do so will suffer the consequences, which can be very grave. I believe scanners can educate new system administrators as to potential security risks. If for no other reason than this, scanners are an important element of Internet security. I recommend trying out as many as possible.
   
© Copyright, Macmillan Computer Publishing. All rights reserved. |
 |
|
