When the network that is now the Internet was first designed, it was
assumed that all users wanted
to be found. No one had reason to hide, and it seemed sensible that
researchers should be able to
locate each other. Utilities were therefore created to facilitate such
finding.
Since those early days, the rise of multiple protocols has made finding
people even more convenient.
As you will see later in this chapter, the old days demanded a high
level of networking knowledge
from the user. Today, finding or identifying most individuals is trivial.
Throughout this chapter, I
examine those techniques, as well as some concepts about wholesale
tracing (tracing many
individuals at one time).
You may wonder why this is deemed a security issue. In truth, it really
isn't--not yet. As you read
this chapter, however, you will learn that the Internet is a powerful
tool for domestic spying.
Law-enforcement and intelligence agencies already conduct such practices
on the Internet, and for
them, the Network is a bonanza. No search warrant is needed to "study"
the activity of someone on
the Internet. Likewise, no warrant is needed to compile lists of individuals
who law enforcement
perceive to be involved in illegal (or even seditious) activity. This
is not a joke. If you harbor radical
political views, by the end of this chapter, you may elect to forever
keep those views to yourself (or
gain a decent education in cryptography).
Before I begin, I need to make one statement regarding screenshots and
diagnostic network
information contained within this chapter. Certain methods of finding
individuals demand the use of
search engines. Unfortunately, to my knowledge, the law has not been
adequately settled regarding
the reprinting of an individual's e-mail address without his consent.
Because of this, I cannot provide
screenshots of searches because they necessarily contain the e-mail
addresses of users unknown.
Therefore, the searches have to be described rather than illustrated.
I do apologize for this.
However, upon reflection, I would not want my e-mail address published,
and I see no reason why
anyone else would, either. The argument is often made that anyone who
posts to a Usenet
newsgroups has at least given an implied form of consent. I do not
support that view. So, I am afraid
that we shall have to get along as best we can by description as opposed
to screenshot. I have taken
pains to explain each step carefully to provide the utmost clarity.
I hope that will suffice.
So, let us begin at the beginning, at the heart of your server. We will
start at home base and work
our way outward.
What's in a Name?
There are two forms of user identification that apply to all platforms:
your e-mail address and your IP
address. It is often theorized that if one is obscured, the other can
never be found. That is untrue.
Without chaining messages through a series of trusted anonymous remailers
(remailers that are
purportedly secure), anonymity on the Internet is virtually impossible.
Anonymous remailers are
discussed in Chapter 7, "Birth of a Network: The Internet."
It is possible, however, to make yourself relatively invisible, and
that is probably what most
individuals would like to do. Before I get more specific, however,
there are some utilities you need to
know about, as well as methods of tracing individuals. I'll start with
finger.
finger
The finger service is a utility common to the UNIX platform. Its purpose
is to provide information
about users on a given system. In practical operation, finger works
like most other services available
in UNIX. Figure 13.1 demonstrates the use of Finger32, a popular finger
client for the Microsoft
Windows platform.
Figure 13.1.
The finger query process.
Cross Reference: Finger32 is a small application
port of the UNIX utility finger. It is
available here:
ftp://hyper.net.au/Win95nt-apps/Finger/Wsfinger/Wsfngr32.zip
The finger service relies on the client/server model, which is a recurring
theme in Internet
applications. This model works as follows: machines running server
applications distribute
information to clients. Clients are programs designed to accept and
interpret information from server
applications. For example, you use a Web browser (or client) to read
information forwarded by a
Web server (the HTTP server).
In any event, the finger client-server relationship works as follows:
On the targeted machine (almost
always a UNIX system), there is a server running called fingerd. This
is more commonly referred
to as the finger daemon. Its purpose is to answer requests from finger
clients from the void.
The finger daemon can return different information, depending largely
on the configuration of the
server and the user's personalized settings. For example, sometimes
an "open" UNIX server (that is,
one not running a firewall) will disallow finger access. This is done
by disabling the finger daemon,
removing it from the file /etc/inetd.conf. In this case, the finger
service is never started. Any
client-issued finger request forwarded to such a machine will meet
with a blank response (or
perhaps, Connection Refused.).
Many organizations, particularly ISPs, government sites, and private
corporations, disable finger
services. Each has an interest in preserving the privacy of its users,
and that is usually the reason
given for disabling the service. As you will learn later, however,
their motivation may also be system
security.
TIP: Certain vital information about the system
can be culled by fingering system IDs
such as root, bin, FTP, and so on. On that
account, some sites will disable finger
services altogether. It is thought that by
killing the finger and RPC services, one can
restrict the amount of revealing information
available to crackers in the void. To some
extent, this is true.
Cross Reference: An excellent paper written
by Dan Farmer and Wietse Venema
addresses this issue: "Improving the Security
of Your Site by Breaking Into It." The
paper is so widely distributed on the Internet.
Here is a very reliable source:
http://www.alw.nih.gov/Security/Docs/admin-guide-to-cracking.101.html.
(This is a government site, so with all probability,
this link will be good for many years
to come.)
Some sites do not disable finger services altogether, but instead put
restrictions on what type of
information can be accessed. For example, by default, the finger daemon
allows a systemwide finger.
Anyone can be fingered, including special or privileged accounts. When
systemwide fingering is
allowed, one can gather information on all users currently logged to
the machine. This is done by
issuing the following command at a UNIX command prompt:
finger @my_target_host.com
The @ symbol has essentially the same effect as the asterisk does in
regular expression searches.
When it is used, the user is fingering all users currently logged to
the target machine. This is most
useful when targeting small providers that have few customers, or when
conducting such a finger
query late at night. Certainly, fingering a company as large as Netcom
in this manner would be
foolish. (The response forwarded by the server would likely be many
pages in length. The only valid
reason for doing this would be to generate a database of Netcom users.)
At any rate, some
organizations will disallow such a request, instead forcing the requesting
party to specify a particular
user.
Other sites make use of hacked finger daemons, either created in-house
or available as distributions
from other sites across the Internet. These are finger daemons that
have enhanced features, including
advanced configuration options.
Cross Reference: One such hacked finger daemon
is the Configurable Finger
Daemon, or cfingerd. Written by Ken Hollis,
cfingerd provides security functions
not available in garden-variety finger servers.
It is considered to be an excellent
replacement to the standard distribution of
finger. It is available free of charge at
ftp://ftp.bitgate.com/pub/cfingerd/.
Cross Reference: For more generalized understanding
of the finger daemon process,
I suggest viewing the source for any public-domain
finger client. There is a nice online
resource for this at http://araneus.york.ac.uk/owtwaww/finger.htm.
At any rate, taking you through the process of a finger inquiry will
take just a few moments, but in
order for you to exploit the example, you need a finger client. UNIX
users, however, have no need
for a finger client, because this is included in the basic distribution.
The same is true of Windows NT.
So this little section is primarily for Windows, Mac, and OS/2 users.
The finger clients are listed in
Table 13.1.
Table 13.1. Finger clients for non-UNIX, non-NT users.
Platform
Client
Location
Windows
(All)
WSFinger
ftp://papa.indstate.edu/winsock-l/finger/wsfngr14.zip
Macintosh
Macfinger
ftp://ftp.global.net.id/pub/mac/internet/finger-15.hqx
OS/2
FFEU
http://www.musthave.com/OS2/ftp/ffeu101.zip
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.
The Finger32 opening screen--choosing a host.
When you choose this option, a dialog box appears, requesting a host
and username. (See Figure
13.3.)
Figure 13.3.
Specifying your target.
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:
How many sodas were in each slot
What those sodas were--Coke, Diet Coke, Sprite, and so on
Whether the available sodas were cold
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.
TIP: You may have encountered servers or users
that suggest that you Finger for
more info. Usually, this entails issuing a
finger request to an address like
info@targethost.com. Most often, the information
you receive (which could be
pages of plain text) comes from the .plan
file.
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
TIP: This technique will only work on servers
that use non-shadowed password files,
or those that are not employing NIS. In those
instances, you may have to issue a
command more like this:
ypcat passwd || cat /etc/passwd | grep user_name
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:
Use the popular utility chfn to alter the finger information available to outsiders
If chfn is not available, request that the sysad change your information
Cancel your current account and start a new
one
NOTE: If you believe in harsh solutions and
you want to discourage people from
repeatedly fingering your account, write a
.plan file that forwards a few megabytes of
garbage. This is most useful if your sysad
refuses to assist, chfn is unavailable, and
some joker is trying to clock your movements
using finger.
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.
MasterPlan
MasterPlan 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.)
TIP: The r commands consist of a suite of network
utilities that can glean information
about users on remote hosts. I will discuss
one of these, a utility called rusers, in a
moment.
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
ftp://ftp.netspace.org/pub/Software/Unix/masterplan.tar.Z
The Linux compiled version is available at
ftp://ftp.netspace.org/pub/Software/Unix/masterplan-linux.tar.Z
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.
TIP: If you want to see an example of mapping
an IP address to a username
dynamically, trying fingering ppp@wizard.com.
This host has apparently aliased out the
PPP connections so that the entire list of
users connected via PPP can be examined
using the finger command. Thus, if you receive
a message from a user in that domain,
but the user obscured his e-mail address,
it could still be culled using the finger
command. By fingering the entire block of
current PPP addresses, you can map the IP
to a username and from there, finger the username.
By going through this process, you
can easily obtain the e-mail address of a
user in that domain, even if he is trying to hide.
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
TIP: The preceding piece of a started Telnet
session was initiated on a Solaris 2.5
SPARC station 20. Different flavors of UNIX
will provide different strings at the
beginning of the session. However, almost
all reveal the operating system and version
number.
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.
TIP: You will find that many other versions
of sendmail-- which has now been ported
to almost every platform-- will also render
this information.
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 Cookies
You 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.)
TIP: If you have never seen such a dialog box,
you need to set your options to warn
you before cookies are being set. Personally,
I prefer to at least be notified when
anything is being written to my hard disk
drive. You should watch all such activities
closely, monitoring any code or other device
that is arbitrarily forwarded to your
machine.
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:
This simple mechanism provides a powerful new
tool which enables a host of new types of
applications to be written for Web-based environments.
Shopping applications can now store
information about the currently selected items,
for fee services can send back registration
information and free the client from retyping
a user-id on next connection, sites can store
per-user preferences on the client, and have
the client supply those preferences every time
that site is connected to.
Cross Reference: The article from which the
previous quote is excerpted, "Persistent
Client State HTTP Cookies," can be found at
http://home.netscape.com/newsref/std/cookie_spec.html.
To understand the way cookies work, please examine Figure 13.4.
Figure 13.4.
Setting cookies.
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.
Cookie warning!
TIP: Note that this advisory will only be shown
if you choose this option (Warn on
Cookie) in your preferences. In Netscape Navigator,
this option can be toggled in the
Network Preferences menu under the Protocols
tab. In Microsoft Internet Explorer, it
can be set in the Options menu under the Advanced
tab.
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:
An origin server could create a Set-Cookie
header to track the path of a user through the
server. Users may object to this behavior
as an intrusive accumulation of information, even if
their identity is not evident.(Identity might
become evident if a user subsequently fills out a
form that contains identifying information.)
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:
User agents should allow the user to control
cookie destruction. An infrequently used cookie
may function as a "preferences file" for network
applications, and a user may wish to keep it
even if it is the least-recently-used cookie.
One possible implementation would be an interface
that allows the permanent storage of a cookie
through a checkbox (or, conversely, its
immediate destruction).
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.
Cross Reference: The "Book 'em, Dan-O" script
was written by an individual named
Spider. It is currently available for download
at Matt's Script Archive, at
http://worldwidemart.com/scripts/dano.shtml.
Cross Reference: One site that will get many
of your environment variables,
particularly if you use UNIX, is located at
http://hoohoo.ncsa.uiuc.edu/cgi-bin/test-env.
What is interesting is that it
will catch both the PPP-based address (as
in ppp32-vn074.provider.com) as well
as your actual 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.
TIP: It has been reported that this can be
done in MacOS by first deleting and then
re-creating the cookie file and subsequently
placing it into the Preferences folder.
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.
NOTE: Although this is a well-known issue,
new users may not be aware of it, so I
will explain. To retrieve the sites you have
most recently visited, type about:cache in
the Open Location box in Netscape's Navigator.
A new page will appear, showing
Web pages you have recently visited. So, if
you browse the Net at work when you are
supposed to be performing your duties, you
will want to kill that cache every few
minutes or set its value to 0.
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.
NOTE: If you are uncomfortable with denying
cookies from all sites, perhaps you
should check out a program called Cookie Jar.
Cookie Jar allows you to specify what
servers you will accept cookies from. The
program was written by Eric Murray, a
member of the Sams technical editorial team.
Cookie Jar is located at
http://www.lne.com/ericm/cookie_jar/. The
main amenity of Cookie Jar is
convenience. Many sites require that you accept
a cookie to access certain services.
Cookie Jar can perform filtering for you.
Public Postings
We 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.
TIP: Note that these are private archives and
have nothing to do with search engines.
The big search engines generally archive Usenet
messages for a few weeks only. In
contrast, private archives (maintained by
non-commercial, special interest groups),
especially those that have listservers in
addition to newsgroups, may be maintained for
a long, long time.
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.
The top-level page of AltaVista.
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.
The top-level page of DejaNews.
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:
1. The snooping party sees your post to Usenet.
Your e-mail address is in plain view, but
your name is not.
2. The snooping party tries to finger your
address, but as it happens, your provider prohibits
finger requests from the void.
3. The snooping party Telnets to port 25 of
your server. There, he issues the expn command
and obtains your real name.
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 Service
The 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.
The top-level page of WorldPages.
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.
TIP: If this information does not exactly match,
the snooping party can employ other
methods to get the location of the posting
machine. One such technique is to issue a
Traceroute request. When tracing the route
to a machine that exists in another city, the
route must invariably take a path through
certain gateways. These are main switching
points through which all traffic passes when
going in or out of a city. Usually, these are
high-level points, operated by telecommunication
companies like MCI, Sprint, and so
forth. Most have city names within their address.
Bloomington and Los Angeles are
two well-known points. Thus, even if the reconciliation
of the posting machine's name
fails against the host outfile, a Traceroute
will reveal the approximate location of the
machine.
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:
The snooping party can determine your status
as a registered voter and your political
affiliations. He obtains this information
at
http://www.wdia.com/lycos/voter-records.htm.
From federal election records online, he can
determine which candidates you support and
how much you have contributed. He gets this
information from
http://www.tray.com/fecinfo/zip.htm.
He can also get your Social Security number
and date of birth. This information is available at
http://kadima.com/.
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":
From the outset the nature of current network
protocols and applications runs counter to
privacy. The vast majority have one thing
in common: they faithfully communicate end-point
identification information. `End-point' in
this context can denote a user (with a unique ID), a
network address or an organization name. For
example, electronic mail routinely
communicates sender's address in the header.
File transfer (e.g., FTP), remote login (e.g.
Telnet), and hypertext browsers (e.g. WWW)
expose addresses, host names and IDs of their
users.
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.
A little case study: dynamic IP allocation.
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.
TIP: In practice, the process is more complex,
involving more hardware and so forth.
However, here we are just concerned with the
address allocation, so I have greatly
simplified the process.
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.
NOTE: The term illegal here refers to those
BBS systems that distribute unlawful
software. This does not have to be warez (pirated
software) either. Certain types of
cellular cloning software, for example, are
unlawful to possess. Distribution of such
software will bring the authorities to your
door. Likewise, "illegal" BBS activity can be
where the operator and members engage in cracking
while logged on. Lastly, those
BBS systems that distribute child pornography
are, quite obviously, illegal.
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.
TIP: You will recall that in Chapter 9, I discussed
this point. The technique for
identifying the source of fakemail involves
using Traceroute. Generally, the
second-to-last listing in the Traceroute results
will reveal the actual source. In other
words, the second-to-last line will reveal
the provider network, and from that you can
deduce that the user was at least temporarily
connected to that server. A discussion
with the sysad at that location should give
you the username--providing, of course, that
you can convince the sysad that there is a
reason for him to release such information.
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:
A cloned cellular telephone or other means
of initiating a digital connection (seizing a circuit,
perhaps)
A laptop (loaded with either FreeBSD or Linux)
Credit card numbers stolen from a clean source
A PCICMA modem
A reason for all this
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:
These lists contain many different types of credit cards, not just one.
These card numbers belong to accounts that
are underwritten by many institutions, not just
one.
The rightful owners of such credit cards live
at locations sprinkled throughout the United
States; therefore, the activity initially
appears to be unconnected.
Law-enforcement agents will initially be dumbfounded
as to the seed source of the numbers,
for all these 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.
NOTE: I have not suggested here that any reader
undertake the action described here.
If you do so, you do it at your own peril.
These actions amount to crime--or, in fact, a
series of crimes. Here, I have merely explained
one technique, and no more. Neither I
nor Sams Publishing advocate, support, or
condone such activity.
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.
Cross Reference: "Anonymity for Fun and Deception:
The Other Side of
`Community'" by Richard Seltzer can be found
on the Web at
http://www.samizdat.com/anon.html.
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
Persons who wish to criticize a repressive
government or foment a revolution against it may
find remailers invaluable. Indeed, given the
ability to broadcast messages widely using the
Internet, anonymous e-mail may become the
modern replacement of the anonymous handbill.
Other examples include corporate whistle-blowers,
people criticizing a religious cult or other
movement from which they might fear retaliation,
and persons posting requests for information
to a public bulletin board about matters too
personal to discuss if there were any chance that
the message might be traced back to its origin.
Cross Reference: "Anonymity and Its Enmities"
by Professor Froomkin is an
excellent source for links to legal analysis
of Internet anonymity. Especially for
journalists, the paper is an incredible resource.
It can be found on the Web at
http://warthog.cc.wm.edu/law/publications/jol/froomkin.html.
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:
People need safety and order in cyberspace
just as they do in their homes and on the streets.
The current state of the Internet makes it
abundantly clear that general anarchy isn't working.
If recognized governments don't find a way
to bring order to the growing and changing
Internet, chaos may soon dictate that the
party is over.
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:
The famous greencard lawyers. In 1994, they
repeatedly sent out a message offering their
services in helping to enter the U.S. greencard
lottery to almost all Usenet newsgroups. (Note
in passing: they charged $100 for their service,
while participating in the greencard lottery is
free and consists merely of sending a letter
with your personal information at the right time to
the right place.) When the incoming mail bombs
forced their access provider to terminate their
account, they threatened to sue him until
he finally agreed to forward all responses to them.
Cross Reference: The Internet Blacklist can
be found on the Web at
http://www.cco.caltech.edu/~cbrown/BL/.
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.
Cross Reference: Dan Fandrich, a prominent
programmer and computer enthusiast in
British Columbia, has compiled a comprehensive
list of such systems. That list is
located at http://vanbc.wimsey.com/~danf/emoney-anon.html.
Of the
systems Fandrich researched, here are a few:
DigiCash
Café
CyberCash
NetBank/NetCash
First Virtual
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.
Summary
This 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.
Resources
Privacy & 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.
http://www.prz.tu-berlin.de/~derek/internet/sources/privacy.faq.02.html
Anonymous Remailer FAQ. Andre Bacard. A not-too-technical description
of anon remailers,
how they work, and where they can be found.
http://www.well.com/user/abacard/remail.html
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.
http://www.cs.berkeley.edu/~raph/remailer-list.html
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.
http://www.replay.com/remailer/chain.html
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.
http://www.itd.nrl.navy.mil/ITD/5540/projects/onion-routing/inet97/index.htm
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.)
http://www.itd.nrl.navy.mil/ITD/5540/projects/onion-routing/OAKLAND_97.ps
Special Report: Privacy in the Digital Age. Susan Stellin. CNET article
containing resources on
privacy on the Internet.
http://www.cnet.com/Content/Features/Dlife/Privacy/
The Electronic Frontier Foundation. Comprehensive sources on electronic privacy.
http://www.eff.org/
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.
http://epic.org/
Computer Professionals for Social Responsibility--CPSR. A group devoted
to discussion
about ethics in computer use.
http://snyside.sunnyside.com/home/
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.
http://www.anonymizer.com/
Articles and Papers
On Shopping Incognito. R. Hauser and G. Tsudik. Second USENIX Workshop
on Electronic
Commerce, November 1996.
http://www.isi.edu/~gts/paps/hats96.ps.gz
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.
ftp://ftp.cert.dfn.de/pub/pem/docs/CEM.ps.gz
E-Mail Security. Dr. John A. Line. UKERNA Computer Security Workshop,
November 15-16,
1994.
ftp://ftp.cert.dfn.de/pub/pem/docs/UKERNA-email-security.ps.gz
Anonymous Internet Mercantile Protocol. David M. Kristol, Steven H.
Low, and Nicholas F.
Maxemchuk. 1994.
http://julmara.ce.chalmers.se/Security/accinet.ps.gz
Anonymous Credit Cards. Steven Low and Nicholas F. Maxemchuk and Sanjoy Paul. 1994.
http://julmara.ce.chalmers.se/Security/anoncc.ps.gz
NetCash: A Design for Practical Electronic Currency on the Internet.
Gennady Medvinsky
and B. Clifford Neuman. 1993.
http://julmara.ce.chalmers.se/Security/netcash2.ps.gz
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.
E-Mail any questions, comments or deaththreats to:
ameister@vol.com
Copyright © AcidMeister...
Visit him at:
http://www.vol.com/~ameister
Disclaimer:
This is for Educational purposes only it should not be used as a guide to
cause havoc or to hack. He He He, good luck!!! And don't get caught. I
would hate to see you in a cell with your 300 pound Bruno The Gay Ax
murderer. He He Heà