Назад в раздел
For demonstration purposes, I will use Finger32, a popular finger application for Windows 95. The application is simple to use; it presents the user with a self-explanatory screen from which you choose your host. (See Figure 13.2.) Figure 13.2. When you choose this option, a dialog box appears, requesting a host and username. (See Figure 13.3.) Figure 13.3. Providing the target is running a finger server, the return output should read something like this: Login name: root In real life: 0000-Admin(0000) Directory: / Shell: /sbin/sh Last login Tue Feb 18 19:53 on pts/22 New mail received Wed Feb 19 04:05:58 1997; unread since Wed Feb 19 03:20:43 1997 No Plan. This tells you several things, including the directory where root@samshack resides (/), the shell he or she is using (/sbin/sh), and some details on last login and mail. (Hard-core hackers will know that it also tells you that root@samshack.com is using Solaris as an operating system. Note the 0000-Admin[0000] string.) This information does not appear to be particularly revealing; however, in 70% of all cases, the field In real life is filled with a name. Worse still, at some universities, you can get the name, telephone number, dorm room number, and major of students enrolled there (not that the major matters particularly, but it provides some interesting background). The information available on a finger query is controlled primarily by the system administrator of a given site, as well as what information you provide on your initial signup. Most new users are not aware of this and provide all the information they can. Most people have no reason to hide, and many provide their office telephone number or even their home address. It is human nature to be mostly honest, especially when the entity they are providing information to seems benign. So the process of identification usually either starts or ends with a finger query. As noted previously, the finger query uses your e-mail address as an index. This leads us immediately into an area of some controversy. Some individuals believe that by changing their e-mail address in the Netscape Navigator or Microsoft Internet Explorer Options panels, they obscure their identity. This is not true. It simply makes your e-mail address more difficult to obtain. I will get to this subject momentarily. For now, I want to continue with finger, offering a little folklore. The following is a classic Internet story. (If you've ever fingered coke@cs.cmu.edu, skip these next few paragraphs.) Years ago, the computer science department staff at Carnegie-Mellon University had a gripe about their Coke machine. Often, staffers would venture down to the basement, only to find an empty machine. To remedy this problem, they rigged the machine, connecting it to the Internet (apparently, they did this by wiring the machine to a DEC 3100). They could then issue a finger request and determine the following things:
Today, you can still issue a finger request to the Coke machine at CMU. If you were to do so, you would receive output very similar to the following: [ Forwarding coke as "coke@l.gp.cs.cmu.edu" ]
[L.GP.CS.CMU.EDU]
Login: coke Name: Drink Coke
Directory: /usr/coke Shell: /usr/local/bin/tcsh
Last login Sun Feb 16 18:17 (EST) on ttyp1 from GS84.SP.CS.CMU.EDU
Mail came on Tue Feb 18 14:25, last read on Tue Feb 18 14:25
Plan:
M & M Coke Buttons
/---- C: CCCCCCCCCCC.............
|?????| C: CCCCCCCC.... D: CCCCCCCCCC..
|?????| C: CCCCCCCCCCCC D: CCCCCCCC....
|?????| C: CCCCCCCC.... D: CCCCCCCCC...
|?????| C: C...........
----/ S: C...........
| Key:
| 0 = warm; 9 = 90% cold; C = cold; . = empty
| Beverages: C = Coke, D = Diet Coke, S = Sprite
| Leftmost soda/pop will be dispensed next
--^-- M&M status guessed.
Coke status heuristics fit data.
Status last updated Wed Feb 19 00:20:17 1997
As you can see, there is no end to the information available with a finger query. The story of this Coke machine was told by Terence Parr, President and Lead Mage of MageLang Institute (http://www.magelang.com/), at the 1996 Netscape Developer's Conference at Moscone Center in San Francisco. Reportedly, Parr was demonstrating a Java application that could emulate this Coke machine hack when suddenly, a former CMU student, Michael Adler, rose to the occasion. Adler explained the hack in detail, having firsthand knowledge of the Coke machine in question. In fact, Adler was largely responsible for adding the temperature index function. At any rate, many administrators insist on supporting finger, and some have legitimate reasons. For example, a finger server allows easy distribution of information. In order for the finger server to support this functionality, the targeted user (or alias) must have a plan file. (The Coke machine at CMU certainly does!) This file is discussed in the next section. The Plan File (.plan)On most UNIX servers, user directories are kept beneath the /home/ or /usr directory hierarchies. For example, a user with a username of cracker will have his home directory in /home/cracker. (This is not set in stone. System administrators are responsible for where such directories are kept. They could specify this location as anywhere on the drive, but the typical placement is /usr or /home.) Typically, in that home directory are a series of special files that are created when the user accesses his account for the first time. For example, the first time he utilizes the mail program Pine, a series of files are established, including .pinerc, which is the configuration file for this mail client. These files are referred to as dot files, because they are preceded by a period. Most dot files are created automatically. The .plan file, however, is not. The user must create this file himself, using any text editor (for example, vi or pico). This file can be closely correlated with the plan.txt file on a VAX system. Its purpose is to print user-specified information whenever that user becomes the target of a finger query. So, if the user saves into the .plan file a text recounting his life history, that text will be printed to the STDOUT of the party requesting finger information. The .plan file is one way that information can be distributed via the finger server. (Note that you, the user, must create that .plan file. This is not automatically generated by anyone else.) If you examine Figure 13.1 again, this will seem a bit clearer.
There are other reasons that some administrators keep the finger service operational. Entire programs can be launched by specifying a particular address to be fingered. In other words, one could (although it is not recommended) distribute text files this way. For example, you could write an event handler to trap finger queries aimed at a particular user; if user A were fingered, the server would send a specified text file to the requesting party. I have seen more than one server configured this way, although it is more common to see mail lists designed in this manner. For whatever reason, then, finger services may be running on the server at which you have an account. If you have never bothered to check what information is available there, you can check now by issuing a finger request to your own account. You can also examine this information (the majority of it, anyway) by issuing the following command at a shell prompt: grep your_username /etc/passwd
This command will print the information the server holds on you in the /etc/passwd file. Note that this information will be visible even if the server makes use of shadowed password entries. So now you know: The names of the majority of Net citizens are there for the taking. If your system administrator insists on using finger, there are several things you can do to minimize your exposure:
Of course, perhaps you are not concerned with being fingered as much as you are concerned with who is doing the fingering. If so, you need MasterPlan. MasterPlanMasterPlan is an excellent utility. Written by Laurion Burchall and released in August 1994, this product takes an aggressive approach to protecting your privacy. First and foremost, MasterPlan identifies who is trying to finger you. Each time a finger query is detected, MasterPlan attempts to get the hostname and user ID of the fingering party. These variables are piped to an outfile called finger_log. MasterPlan will also determine how often you are fingered, so you can easily detect if someone is trying to clock you. (Clocking refers to the practice where user A attempts to discern the habits of user B using various network utilities, including finger and the r commands.)
Typically, a cracker writes a shell or Perl script to finger (or otherwise query) the target every specified number of minutes or hours. Reasons for such probing can be diverse. One is to build a profile of the target; for example, when does the user log in? How often does the user check mail? From where does the user usually log in? From these queries, a cracker (or other nosy party) can determine other possible points on the network where the user can be found. Consider this example: A cracker I know was attempting to intercept e-mail trafficked by a nationally renowned female journalist who covers hacking stories. This journalist had more than one account and frequently logged into one from another. (In other words, rather than directly logging in, she would chain her connections.) This is a common practice by individuals in the public eye. They may want to hide from overly enthusiastic fans (or perhaps even legitimate foes). Thus, they preserve at least one account to receive public mail and another to receive private mail. By running a probing script on the journalist, the cracker was able to identify her private e-mail address. He was also able to compromise that network and ultimately capture all the journalist's mail. The mail was primarily discussions between the journalist and a software engineer in England. The subject matter concerned a high-profile cracking case in the news. (That mail was later distributed to crackers' groups across the Internet.) In any event, MasterPlan can help to identify these patterns, at least with respect to finger queries. The utility is small, and easily unpacked and configured. The C source is included, and the distribution is known to compile cleanly on most UNIX systems. (The exceptions are reportedly Ultrix and the NeXT platform.) One nice amenity for Linux users is that a pre-compiled binary comes with the distribution. The standard distribution of MasterPlan is available at The Linux compiled version is available at As you've now seen, the finger utility is dangerous and revealing. More and more sites are now disabling finger services, at least with respect to external queries. For various reasons, however, many providers simply do not bother to shut it down.
Note that MasterPlan will not prevent someone from fingering you; it will simply identify that party and how many times the finger request has been issued. But all this assumes that your provider allows finger requests from the void. Suppose for a moment that it doesn't. Does this mean that you are safe and that you shouldn't worry about your name being revealed? Hardly. It simply means that a standard finger query will fail to render any information about you. Suppose that someone is attempting to finger you and discovers that finger requests from the void are prohibited. Suppose further that this person is determined to find your real name and is willing to risk an angry message from your provider to his own. In such a case, the nosy party will initiate a Telnet session to your provider's mail server. (This is done by initiating a Telnet request to port 25.) In most cases (except those where the provider is paranoid or running a firewall), a server will accept a Telnet connection to port 25 (the port that sendmail runs on). Such a connection looks like this: 220 shell. Sendmail SMI-8.6/SMI-SVR4 ready at Wed, 19 Feb 1997 07:17:18 -0800
If the nosy party can get to such a prompt, there is better than an 80 percent chance that he will have your name momentarily. The information is collected by issuing the following command: expn username This command requests that the mail package expand a username into an e-mail address and real name. This is a feature (not a bug) of the sendmail package. The response will typically expand into something similar to username <username@target_of_probe.com> Real Name The first field will report back the username or user ID that you request to be expanded. This will be followed by the person's e-mail address and finally, his "real" name. Note that the expn function can be disabled by the system administrator, although few actually do it. There are reasons for this, and the most probable is that administrators simply fear fiddling with the sendmail configuration. Sendmail is a notoriously complex and powerful program that has evolved into a huge package. There are so many options for it that an entire book could be written just on its configuration. It is for this reason, no doubt, that sendmail has consistently been the source of holes in Internet security. So you might wonder why the program is even used at all. That is easy to explain. Sendmail is the most successful program for transport of electronic mail ever created. Millions of users all over the world send mail each day using this program. In any event, if the expn function is operable, the nosy individual will still get your real name, if it is available. Unfortunately, even if the expn function has been disabled, the snooping party can still verify the existence of your account using the vrfy function. This is academic, however; if your provider's sendmail system honors Telnet sessions, there is a greater than 70 percent chance that one or both of these functions is available.
Currently, other than rewriting your account so that your real name does not appear in the /etc/passwd database, there is no way for you to exercise control over these remote functions. sendmail issues must be resolved by root. Moreover, it is highly unlikely that a system administrator will fiddle with his or her sendmail configuration just to satisfy the needs of a paranoid user. Thus, the rule of thumb is this: If you intend to remain untouchable on the Net, you must never, ever allow your real name to fill that field within the /etc/passwd file. A Few Words About CookiesYou have seen the message many times. You land on a WWW site and a dialog box appears. The server at the other end says it wants to set a cookie. Most users have no idea what this means, so they simply click the OK button and continue. Other users actually read the dialog box's contents and get a little worried. (This is especially true when the cookie is going to be set for sometime into the year 2000. The user may not be sure what a cookie is, but almost all users balk when that cookie is going to hang around for 3 or 4 years.)
What are cookies? The cookie concept is very much like getting your hand stamped at a dance club. You can roam the club, have some drinks, dance, and even go outside to your car for a few minutes. As long as the stamp is on your hand, you will not have to pay again, nor will your access be restricted. But cookies go much further than this. They record specific information about the user, so when that user returns to the page, the information (known as state information) can be retrieved. The issue concerning cookies, though, isn't that the information is retrieved. The controversy is about where the information is retrieved from: your hard disk drive. Cookies (which Netscape calls persistent client state HTTP cookies) are now primarily used to store options about each user as he browses a page. The folks at Netscape explain it this way:
To understand the way cookies work, please examine Figure 13.4. Figure 13.4. As you can see, when the remote server is contacted, it requests permission to set a cookie. (One wonders why some sites set a cookie on their opening page. Just what state information are they recording? You haven't specified any preferences yet, so there is essentially nothing to record.) Prior to the setting of the cookie, however, the user is generally confronted with the advisory shown in Figure 13.5. Figure 13.5.
Advocates of cookies insist that they are harmless, cannot assist in identifying the user, and are therefore benign. That is not true, as explained by D. Kristol and L. Montulli in RFC 2109:
I know many programmers who are exploring techniques for using cookies for user authentication. This is disturbing. There has not been enough scrutiny of the privacy issues surrounding cookies, and there needs to be some method developed to manage them. That is, perhaps some cookies are desirable to a particular user and some are not. The user may visit certain sites regularly. If those sites use cookie conventions, the user will unnecessarily be confronted with a cookie warning each time he visits, unless that cookie remains on the drive. However, other cookies (from sites that the user may never visit again) should be easily removed. This is also discussed in RFC 2109:
Briefly, to find the cookies on your hard disk drive, search for the file cookies.txt. This file will contain a list of cookies and their values. It looks like this: www.webspan.net FALSE /~frys FALSE 859881600 worldohackf 2.netscape.com TRUE / FALSE 946684799 NETSCAPE_ID 1000e010,107ea15f.adobe.com TRUE / FALSE 946684799 INTERSE 207.171.18.182 6852855142083822www.ictnet.com FALSE / FALSE 946684799 Apache pm3a-4326561855491810745.microsoft.com TRUE / FALSE 937422000 MC1 GUID=260218f482a111d0889e08002bb74f65.msn.com TRUE / FALSE 937396800 MC1 ID=260218f482a111d0889e08002bb74f65comsecltd.com FALSE / FALSE 1293753600 EGSOFT_ID 207.171.18.176-3577227984.29104071 .amazon.com TRUE / FALSE 858672000 session-id-time 855894626.amazon.com TRUE / FALSE 858672000 session-id 0738-6510633-772498 This cookie file is a real one, pulled from an associate's hard disk drive. You will see that under the GUID, the leading numbers are an IP address. (I have added a space between the IP address and the remaining portion of the string so that you can easily identify the IP. In practice, however, the string is unbroken.) From this, you can see clearly that setting a cookie may involve recording IP addresses from the target. Now, this does not mean that cookies are a major threat to your privacy. Many JavaScript scripts (and Perl scripts) are designed to "get" your IP. This type of code also can get your browser type, your operating system, and so forth. Following is an example in JavaScript: <script language=javascript>
function Get_Browser() {
var appName = navigator.appName;
var appVersion = navigator.appVersion;
document.write(appName + " " + appVersion.substring (0,appVersion.indexOf(" ")));
}
</script>
This JavaScript code will get the browser and its version. Scripts like this are used at thousands of sites across the Internet. A very popular one is the "Book 'em, Dan-O" script. This script (written in the Perl programming language) will get the time, the browser, the browser's version, and the user's IP.
Also, nearly all Web server packages log access anyway. For example, NCSA HTTPD provides an access log. In it, the IP address of the requesting party is logged. The format of the file looks like this: - - [12/Feb/1997:17:20:59 -0800] "GET /~user/index.html i HTTP/1.0" 200 449 The major difference between these devices and the cookie implementation, however, is that cookies are written to a file on your hard disk drive. Many users may not be bothered by this, and in reality, there is nothing threatening about this practice. For example, a cookie can only be read by the server that set it. However, I do not accept cookies as a rule, no matter how persistent the server may be at attempting to set one. (Some programmers provide for this process on every page, hoping that eventually the user will tire of dealing with dialog boxes and simply allow the cookie to be set.) It is interesting to note that some clients have not been preconfigured to deny cookies. In these instances, a cookie may be written to the drive without the user's consent, which is really the default configuration, even for those browsers that support screening of cookies. Early versions of both Netscape Navigator and Microsoft Internet Explorer shipped with the Deny Cookies checkbox unchecked. Absentmindedness on the part of the vendors? Perhaps. If you have a problem denying cookies, for whatever reason, there is an action you can undertake to prevent these items from being written to your drive. One is to make the file cookies.txt read-only. Thus, when a foreign Web server attempts to write to the file, it will fail.
I recommend denying cookies, not so much because they are an invasion, but because they leave a trail on your own hard disk drive. That is, if you visit a page that you have been forbidden to access and it sets a cookie, the evidence will be in cookies.txt. This breaks down to cache issues as well: even if your cookies file is clean, your cache will betray you.
Currently, denying a cookie does not dramatically influence your ability to access a page, although that may change in the future. At best, the cookie issue has assisted in heightening public awareness that a remote Web server can cull your IP address and, in certain instances, your location, your operating system, your browser, and so forth.
Public PostingsWe will now assume that no one knows who you are. They are about to find out, however, because you are about to post a message to a Usenet newsgroup. From the moment you post a message to Usenet, your name and e-mail address are fair game. The Usenet news network is somewhat different from other forms of communication on the Internet. For a start, it is almost entirely public, with a very few exceptions. Moreover, many Usenet news newsgroups are archived--that is, the articles posted to such groups are bundled and stored for later use. I have seen archived messages ranging back to 1992, some of which are reachable by WAIS, FTP, Telnet, and other, antiquated interfaces.
Because these messages are kept, your e-mail address (and identity, because your identity can be traced with it) has a shelf life. Hucksters like list brokers routinely tap such archives, searching for leads--collections of e-mail addresses of persons who share a particular interest, such as all females over 40 years of age who smoke a pipe, have an eye patch, and voted Republican in the last election. If you think that this level of refinement is ludicrous, think again. Applying various search spiders (and a number of personal robots), one can narrow the search to something that specific. The first step in developing such a list is to capture e-mail addresses. To do this, any garden-variety search engine will do, although AltaVista (altavista.digital.com) and DejaNews (www.dejanews.com) have the most malleable designs. Even though these engines are well known to most users, I am providing screen captures of their top-level pages, primarily for reference purposes as I explain Usenet snooping. Figure 13.6. AltaVista is one of the most powerful search engines available on the Internet and is provided as a public service by Digital Equipment Corporation (DEC). It accepts various types of queries that can be directed toward WWW pages (HTML) or Usenet postings. (The Usenet postings are archived, actually. However, DEC reports that these are kept only for a period of "a few weeks.") One key point about the AltaVista engine is that it was coded nicely. By enclosing strings in quotation marks, you can force a case-sensitive, exact regex (regular expression) match. As a result, you can isolate one page out of millions that contains the exact string you're seeking. Similarly, you can isolate all Usenet postings made by a particular author. By taking each of those postings and analyzing them, you can identify that person's chief interests. (Perhaps the person is a militia member, for example.) The DejaNews search engine is a very specialized tool. It is solely a Usenet robot/spider. The DejaNews archive reportedly goes back to March 1995, and the management indicates that it is constantly trying to fill gaps and get older articles into the database. It claims that it is working on providing all articles posted since 1979. Figure 13.7 shows the top page of DejaNews. Figure 13.7. DejaNews has some more advanced functions for indexing, as well. For example, you can automatically build a profile on the author of a Usenet article. (That is, the engine will produce a list of newsgroups that the target has posted to recently.) Defeating the archiving of your Usenet messages on both AltaVista and DejaNews is relatively simple--for direct posting, at least. Either in the X headers of your Usenet article or as the first line of your article, issue the following string: x-no-archive: yes This will ensure that your direct postings made to Usenet will not be archived. This does not, however, protect you from third-party postings that contain your e-mail address. For example, if you belong to a mailing list and that list is archived somewhere on the WWW (or even at FTP sites), your e-mail address is already compromised. If your e-mail address appears in a thread of significant interest (and your reply was sufficiently enlightening), it is guaranteed that the entire thread (which contains your address) will be posted somewhere. And it will be somewhere other than Usenet; perhaps a WWW page or a Gopher server. Let us continue to suppose that you have no knowledge of how Usenet indexing works. Let us further assume that although your real name does not appear on Usenet postings, it does appear in the /etc/passwd file on the UNIX server that you use as a gateway to the Internet. Now you are a viable target. Here are some steps that will lead the snooping party not simply to your real name, but to the front door of your home. The steps are as follows:
Having gotten that information, the snooping party next needs to find the state in which you currently reside. For this, he turns to the WHOIS service. The WHOIS ServiceThe WHOIS service (centrally located at rs.internic.net) contains the domain registration records of all Internet sites. This registration database contains detailed information on each Internet site, including domain name server addresses, technical contacts, the telephone number, and the address. Here is a WHOIS request result on the provider Netcom, a popular Northern California Internet service provider: NETCOM On-Line Communication Services, Inc (NETCOM-DOM)
3031 Tisch Way, Lobby Level
San Jose, California 95128
US
Domain Name: NETCOM.COM
Administrative Contact:
NETCOM Network Management (NETCOM-NM) dns-mgr@NETCOM.COM
(408) 983-5970
Technical Contact, Zone Contact:
NETCOM DNS Administration (NETCOM-DNS) dns-tech@NETCOM.COM
(408) 983-5970
Record last updated on 03-Jan-97.
Record created on 01-Feb-91.
Domain servers in listed order:
NETCOMSV.NETCOM.COM 192.100.81.101
NS.NETCOM.COM 192.100.81.105
AS3.NETCOM.COM 199.183.9.4
Here, the snooping party has discovered that the provider is in the state of California. (Note the location at the top of the WHOIS return listing, as well as the telephone points of contact for the technical personnel.) This information will help tremendously; the snooping party now proceeds to http://www.worldpages.com/. WorldPages is a massive database with a design very similar to the average White Pages. It holds the names, e-mail addresses, and telephone numbers of several million Internet users. (See Figure 13.8 for a screenshot of the top-level page of WorldPages.) Figure 13.8. At WorldPages, the snooping party funnels your real name through a search engine, specifying the state as California. Momentarily, he is confronted with a list of matches that provide name, address, and telephone number. Here, he may run into some trouble, depending on how common your name is. If your name is John Smith, the snooping party will have to do further research. However, let us assume that your name is not John Smith. Let's assume that your name is common, but not that common. So the snooping party uncovers three addresses, each in a different California city: One is in Sacramento, one is in Los Angeles, and one is in San Diego. How does he determine which one is really you? He proceeds to the host utility. The host utility (discussed briefly in Chapter 9, "Scanners") will list all the machines on a given network and their relative locations. With large networks, it is common for a provider to have machines sprinkled at various locations throughout a state. The host command can identify which workstations are located where. In other words, it is generally trivial to obtain a listing of workstations by city. These workstations are sometimes even named for the cities in which they are deposited. Therefore, you may see an entry such as chatsworth1.target_provider.com Chatsworth is a city in southern California. From this entry, we can assume that chatsworth1.target_provider.com is located within the city of Chatsworth. What remains for the snooper is to reexamine your Usenet post. By examining the source code of your Usenet post, he can view the path the message took. That path will look something like this: news2.cais.com!in1.nntp.cais.net!feed1.news.erols.com!howland.erols.net! Âix.netcom.com!news By examining this path, the snooping party can determine which server was used to post the article. This information is then coupled with the value for the NNTP posting host: grc-ny4-20.ix.netcom.com The snooping party extracts the name of the posting server (the first entry along the path). This is almost always expressed in its name state and not by its IP address. For the snooping party to complete the process, however, the IP address is needed. Therefore, he next Telnets to the posting host. When the Telnet session is initiated, the hard, numeric IP is retrieved from DNS and printed to STDOUT. The snooping party now has the IP address of the machine that accepted the original posting. This IP address is then run against the outfile obtained by the host query. This operation reveals the city in which the machine resides.
Having obtained this information (and having now differentiated you from the other names), he returns to WorldPages and chooses your name. Within seconds, a graphical map of your neighborhood appears. The exact location of your home is marked on the map by a circle. The snooping party now knows exactly where you live and how to get there. From this point, he can begin to gather more interesting information about you. For example:
Many users are not bothered by this. Among those people, the prevailing attitude is that all such information is available through sources other than the Internet. The problem is that the Internet brings these sources of information together. Integration of such information allows this activity to be conducted on a wholesale basis, and that's where the trouble begins. It is now possible (using the techniques described here) to build models of human networks--that is, it is now possible to identify all members of a particular class. It is also possible to analyze the relationships between them. This changes the perspective for intelligence agencies. Years ago, gathering domestic intelligence was a laborious process. It required some element, however slim, of human intelligence. (Human intelligence here refers to the use of human beings to gather information as opposed to machines or other, automated processes.) Thus, to get the low-down on the Students for a Democratic Society, for example, intelligence agencies had to send agents on foot. These agents had to mix with the crowd, record license plate numbers, or gather names at a rally. Today, those methods are no longer necessary. Today, the Internet provides a superb tool to monitor the public sentiment (and perhaps to identify those who conspire to take up arms). In some respects, one might concede that this is good. Certainly, if individuals are discussing violence or crime, and they contemplate these issues online, it seems suitable that law-enforcement agencies can take advantage of this emerging technology. However, it should be recognized here that the practice of building models of human networks via the Internet violates no law. It amounts to free spying, without a warrant. Put more bluntly, we Americans do often have big mouths. Some of us would do better to keep quiet. Before I continue, I want to make one point clear: Complete anonymity on the Internet is possible, but not legally. Given enough time, for example, authorities could trace a message posted via anonymous remailer (although, if that message were chained through several remailers, the task would be far more complex). The problem is in the design of the Internet itself. As Ralf Hauser and Gene Tsudik note in their article "On Shopping Incognito":
Indeed, the process starts at the very moment of connection. For example, workstations connected to a network that is directly wired to the Net all have permanent addressing schemes. Certainly, an Ethernet spoof will not carry when crossing the bridge to IP; therefore, fixed stations permanently strung to the Internet will always have the same IP. And, short of the operator of such a workstation getting root access (and altering the routing tables), there is little that can be done in this regard. Similarly, the average user's IP is dependent solely upon his server. Consider the exchange that occurs in a dial-up account. (See Figure 13.9.) Figure 13.9. Most servers are now running some form of dynamic IP allocation. This is a very simple but innovative system. Examine the Ethernet arrangement to the right of Figure 13.9 (a garden-variety rack of headless workstations). Each machine on that network can allocate a certain number of IP addresses. Let's make it simple and say that each workstation can allocate 254 of them. Think of each address as a spoke in a bicycle wheel. Let's also assume that the IP address for one of these boxes is 199.171.180.2 (this is an imaginary address). If no one is logged on, we say that the available addresses (on that box) range from 199.171.180.3 to 199.171.180.255. As long as only a portion of these address are occupied, additional addresses will be allocated. However, what if they are all allocated? In that case, the first one to be disengaged will be the next available IP. That is, suppose they are all allocated and you currently occupy 199.171.180.210. As soon as you disconnect (and if no one else does before the next call), the very next customer will be allocated the address 199.171.180.210. It is a free slot (left free because you have disconnected), and the next caller grabs it. The spokes of the wheel are again fully occupied.
This demonstrates that in dynamic IP allocation, you will likely have a different address each time you connect. Many individuals who run illegal BBS systems on the Internet take advantage of this phenomenon.
The dynamic allocation allows users to perform a little parlor trick of sorts. Because the IP is different each time, an illegal BBS can be a moving target. That is, even if law-enforcement officials suspect the activity being undertaken, they are not sure where it is happening without further research. Typically, this type of setup involves the perpetrators using a networked operating system (almost always Linux or FreeBSD) that allows remote logins. (These logins may include FTP, Telnet, Gopher, and so on. It is also fairly common to see at least sparse HTTP activity, although it is almost always protected using htpasswd.) It is also common for the operator of such a board to request that users use SSH, S/Key, or some other, secure remote-login software so that third parties cannot snoop the activity there. Typically, the operator connects using the networked operating system and, after having determined the IP for the night, he mails out the network address to the members of the group. (This is usually an automated process, run through a Perl script or some other shell language.) The mailed message need be no more than a blank one, because all that is important is the source address. For the brief period that this BBS is connected, it effectively serves as a shadowed server in the void. No one would know of its existence unless they scanned for it. Most often, the operator will kill both finger and the r services, therefore blocking the prying eyes of third parties from determining who is logged to the server. Moreover, the operator has usually gained some privileged access to his provider's network and, having done so, can obscure his presence in system logs. For the individuals in these groups, relative anonymity is realized because, even if an outside party later questions the sysad of the provider, the logs may be very sparse. Most system administrators are reluctant to kill an account without adequate proof. True, the logs at any outside network would show some activity and the IP it originated from, but that is not enough. If the system administrator cannot say with certainty who perpetrated the activity, he has no case. Meanwhile, during the period when users are logged in to this hidden server, they, at least, are shielded in terms of identity. They can then Telnet back out of that machine (or connect to IRC) and from there, they have some level of shielding. But what about the average Joe? The average user does not implement such schemes. He connects using mostly client software, on the IBM or Mac platform, and is not looking to provide services. The difference is considerable. Certainly, anyone using the configuration described here has more options with regard to sending, say, fakemail. Because that person controls the server (and the sendmail application is local), even a simple message sent from the console will appear differently from one sent from a Windows client. Such a message cannot be trusted, and only by reviewing the full headers can you reliably determine where it came from.
My point is this: During the period when a shadowed server is up, those who log in from the void are safe and hidden, but only as long as the operator of the box refuses to provide their identities. For example, say a kid establishes such a box in California. His friends from Philadelphia connect to the box and use it as a launching pad. From there, the folks from Philadelphia Telnet back out and begin cracking some server in the void. Our boy in California may later have to answer for this activity. However, if he has erased his logs (and keeps his mouth shut), the people from Philadelphia will never be found. Which leads to this advice: If you run such a server, never, ever allow individuals you do not know to use it. When you destroy the logs, you are sealing your own fate. These individuals are using an IP address that can be traced to you (unless you have root access on your provider's box). Thus, if you meet someone on IRC and he begs you for a shell account, it is best that you refuse until you know him. Otherwise, it is you and not he who will suffer. At any rate, because of the inherent design of the Internet, the IP address is a universal identification index. It has to be, because without it, how could information be routed across the network? Therefore, be advised that although you may change your mail address in Netscape Navigator or other programs containing mail packages, this does not obscure your identity. True, inexperienced users will be dumbfounded as to the origin of the message, but anyone familiar with UNIX can trace the message right to its source. I imagine that the majority of my readers are not criminals and simply want to keep their name out of Usenet screens or mailing lists. However, for those inclined to break the law (who are scouring this chapter for that one, single answer), I say this: To totally shield yourself from the law (and other, interested parties), you will need these items:
Certain individuals are available for hire to perform various crimes over the Internet. When they conduct their activity, this is how they do it. The credit card numbers are usually bought outright from an underground, or a "clean," source; one that law enforcement can neither readily identify or reach. Most of these are on microfiche, taken from a financial institution or other source that has a quantity of numbers. (Note that only those individuals who are doing high-volume work will buy microfiche. This is because using microfiche-based numbers is in itself a risk. Later analysis by law enforcement will reveal that sets of numbers used may have or appear to have originated from the same source.) Those involved in this activity generally explain that banks are poor sources for the numbers, as are Internet service providers, car rental agencies, and retail chains. It is argued that the best source is from mail-order lists or department store databases. These are the reasons:
Having obtained the numbers, the next step is to choose a provider. Most individuals who do this on a regular basis have lists of providers that allow "instant access," where you provide your vitals, your credit card, your desired login, your password, and so forth. Within minutes, you are surfing the Net. Using this technique, you can reliably obtain total anonymity for short periods of time, periods long enough to perform the desired task. The only hope that authorities have of catching you is to elicit corroborative testimony of a coconspirator, or if you establish a pattern of activity--for example, if spend your nights breaking into machines owned or operated by security specialists who are also talented hackers.
For my more law-abiding readers (the majority, I hope), there are varying degrees of anonymity that can be obtained. It depends upon why you want to hide and the sensitivity of the data you are trafficking. It has been recognized that there are plenty of legitimate reasons for allowing anonymity on the Internet. The following is excerpted from "Anonymity for Fun and Deception: The Other Side of `Community'" by Richard Seltzer: Some communities require anonymity for them to be effective, because without it members would not participate. This the case with Alcoholics Anonymous, AIDS support groups, drug addiction support and other mutual help organizations, particularly when there is some risk of social ostracism or even legal consequences should the identity of the members be revealed.
This is a recurring theme in the now-heated battle over Internet anonymity. Even many members of the "establishment" recognize that anonymity is an important element that may preserve free speech on the Internet--not just here, but abroad. This issue has received increased attention in legal circles. An excellent paper on the subject was written by A. Michael Froomkin, a lawyer and prominent professor. In "Anonymity and Its Enmities," Froomkin writes
However, not everyone feels that anonymity is a good thing. Some people believe that if anonymity is available on the Internet, it amounts to nothing but anarchy. Here is a rather ironic quote, considering the source is Computer Anarchy: A Plea for Internet Laws to Protect the Innocent by Martha Seigel:
You may or may not know why this quote is so incredibly ironic. The author, Martha Seigel, is no stranger to "computer anarchy." In her time, she has been placed on the Internet Blacklist of Advertisers for violating network policies against spamming the Usenet news network. The following is quoted from the docket listing on that blacklist in regards to Cantor & Seigel, Ms. Seigel's law firm:
I should mention here that Cantor and Seigel are the authors of How To Make A Fortune On The Information Superhighway (HarperCollins, 1994). For Internet marketers, this book is purportedly a must-read. I also understand that a new book by Seigel, How to Make a Fortune on the Internet (HarperCollins), is forthcoming. However, all this may be academic. As we move toward a cashless society, anonymity may be built into the process. In this respect, at least, list brokers (and other unsavory information collectors) had better do all their collecting now. Analysis of consumer buying habits will likely become a thing of the past, at least with relation to the Internet. The majority of electronic payment services being developed (or already available) on the Internet include anonymity as an inherent part of their design.
Fandrich's research demonstrates a few significant points. Some systems claim to offer "total" anonymity, but they really don't. He observes, for example, that many systems keep logs of the activity. This represents one important issue. While individuals are concerned with their privacy, and banks would like to ensure that privacy, some medium must be reached. Because if there is total anonymity, how can crimes be adequately investigated? Certainly, new fraud schemes will arise as a result of these new technologies. For example, a technique is already known for defeating the security of smartcards. (I will not be printing that here, I'm afraid.) In short, complete anonymity on the Internet is becoming less and less easy to lawfully obtain. However, advanced research in the area of anonymous payment schemes will probably turn that around dramatically in the next five years. For, while government agencies are circumspect about Internet anonymity, the coming age of Internet commerce almost demands it. That is where the research is going at the moment, and there is no indication of that trend changing in the near future. SummaryThis chapter discusses a variety of ways you can conceal your identity, including using utilities such as finger, the r commands, and Master Plan. The issue of cookies is addressed. Finally, the issue of anonymity is discussed as it relates to Usenet postings and the WHOIS service. ResourcesPrivacy & Anonymity on the Internet FAQ. L. Detweiler. Many sources on privacy and anonymity on the Internet. A must for users new to identity issues on the Net. Anonymous Remailer FAQ. Andre Bacard. A not-too-technical description of anon remailers, how they work, and where they can be found. Note: Bacard is also the author of Computer Privacy Handbook ("The Scariest Computer Book of the Year"). The Anonymous Remailer List. Raph Levien. Locations of anonymous remailers on the Internet. How-To Chain Remailers. Alex de Joode. A no-nonsense tutorial on how to chain remailers and, in doing so, send a totally anonymous message. Privacy on the Internet. David M. Goldschlag, Michael G. Reed, and Paul F. Syverson: Naval Research Laboratory Center For High Assurance Computer Systems. A good primer that covers all the aspects discussed in this chapter. Anonymous Connections and Onion Routing. David M. Goldschlag, Michael G. Reed and Paul F. Syverson: Naval Research Laboratory Center For High Assurance Computer Systems. PostScript. Presented in the Proceedings of the Symposium on Security and Privacy in Oakland, Calif., May 1997. A quite detailed analysis of anonymous connections and their resistance to tracing and traffic analysis. (Also discusses vulnerabilities of such systems. A must read.) Special Report: Privacy in the Digital Age. Susan Stellin. CNET article containing resources on privacy on the Internet. The Electronic Frontier Foundation. Comprehensive sources on electronic privacy. The Electronic Privacy Information Center (EPIC). Civil liberties issues. This site is indispensable in getting legal information on privacy and anonymity on the Internet and elsewhere. Computer Professionals for Social Responsibility--CPSR. A group devoted to discussion about ethics in computer use. The Anonymizer. A site that offers free anonymous surfing. The application acts as a middleman between you and the sites you surf. Basically, it is a more complex proxying service. It allows chaining as well, and your IP is stripped from their logs. Articles and PapersOn Shopping Incognito. R. Hauser and G. Tsudik. Second USENIX Workshop on Electronic Commerce, November 1996. The Anonymous E-mail Conversation. Ceki Gulcu. Technical Report, Eurecom Institute. June 1995. Control of Information Distribution and Access. Ralf C. Hauser. Technical Report, Department of Computer Science, University of Zurich. September 1995. Internet Privacy Enhanced Mail. Stephen T. Kent. Communications of the ACM, vol.36 no.8, August 1993. Certified Electronic Mail. Alireza Bahreman, J. D. Tygar. 1994. E-Mail Security. Dr. John A. Line. UKERNA Computer Security Workshop, November 15-16, 1994. Anonymous Internet Mercantile Protocol. David M. Kristol, Steven H. Low, and Nicholas F. Maxemchuk. 1994. Anonymous Credit Cards. Steven Low and Nicholas F. Maxemchuk and Sanjoy Paul. 1994. NetCash: A Design for Practical Electronic Currency on the Internet. Gennady Medvinsky and B. Clifford Neuman. 1993. Electronic Fingerprints: Computer Evidence Comes of Age. Anderson, M.R., Government Technology Magazine, November 1996. Achieving Electronic Privacy. David Chaum. Scientific American, pp. 96-101, August 1992. Erased Files Often Aren't. Anderson, M.R., Government Technology Magazine, January 1997. FBI Seeks Right to Tap All Net Services. Betts, M. ComputerWorld, Vol. XXVI, No. 23, June 8, 1992.
   
© Copyright, Macmillan Computer Publishing. All rights reserved. |
 |
|
