Mr Martin:

-I read the article in Wired magazine to which you referred me, but I had previously also read a similar, relatively recent article archived on Salon.com at http://www.salon.com/tech/view/2000/03/27/vranesevich/index.html. The reason I agreed to write this was simple: there's too much inaccurate hype that's being propagated regarding the capabilities of those of us in this sector. My fear is that with all this hype and confusion, companies who have a real need for security will have a few bad experiences with hype generation and lump legitimate professionals in this field in with those who fear monger. There are some serious talents in this business who would rather say "I just can't do that"; than to string the client along for a while and eventually come to the same result. There is a technical reason why client skepticism about questionable techniques is wise: Wasting time with those who may provide inaccurate information will usually harm the client's security and damage shareholder credibility by allowing pertinent, valuable data residing within the computer system or its infrastructure (not the least of which being its storage media) to be destroyed.

With the reason for my response established, I must say that this article leaves questions in my mind. Notwithstanding the legal concerns regarding a civilian initiating an inter-network, inter-state, and inter-national trace through numerous systems in what appears from the report to be a rather cowboy-ish way; I am left in a quandary as to the technique employed during said trace.

On the legal side, I am unaware of any legal citations wherein a civilian can initiate "traceback" procedures more than one "connection" outside his own network. Actually, that "one connection" isn't set in stone, but there are no citations in US Code that would allow a person to accomplish tracebacks in the manner they were described in this article.

Since the article in Wired is a bit vague on details, I am making a few guesses here on the parameters of the chat session. I will presume that the investigator used his own (or a fully cooperating) IRC network for the purposes of the interview. I base this upon the fact I alluded to above: IRC _clients_ are far too risky to rely upon for accurate connection information. In investigations, it is incumbent upon the investigator to have credible, reliable information; so using a controlled network environment as a starting point is analogous to having a controlled environment for a drug sting. Once "The Analyzer" was connected to the investigator's server; it is quite possible for the IP address from which "The Analyzer" was connecting to the IRC server to have been obtained. IP spoofing, though possible, is relatively improbable in this case.

Once obtaining the IP, how does one unobtrusively but LEGALLY go "through 13 different servers" to verify the connections? For that matter, how do we even get the count on number of servers bounced through from OUTSIDE the stream? First hop, I can see, but subsequent hops? If we want to go with the premise that perhaps "The Analyzer" WAS spoofing; then a recent article posted to Ars Technica at http://arstechnica.com/reviews/2q00/networking/networking-1.html is worth a read. That article discusses a technique to avoid having to use the inefficient manner of tracing back a spoofed IP now in use. I doubt such a technique was used in this case, simply because of the level of preparation and time required to use such a technique. Re-writing and re-compiling your TCP-IP stack at a moment's notice for an interview just doesn't sound feasible.

"The Analyzer" had no requirement to stay legal; but those of us in this industry DO have such an obligation, lest our client be held liable for our actions while carrying out the contracted service. My assumption here is that it took 27 hours (as cited in the Vanity Fair article) due to the telephone calls or other communications convincing the system administrators of each "bounce" to allow the investigator appropriate levels of access to review the logs to see telnet by telnet the path taken. I know of no other legal, reliable, trustworthy method of tracing back the origin of a machine telnetting or "bouncing" through multiple IP's on the open internet. Again, there are quick kludges or even all out hacks to attempt to trace back, but the key words here are "legal", "reliable", and "trustworthy".

From personal experience: even law enforcement and intelligence-related entities have very few exceptions to the rule when conducting IP traces. Perhaps "fresh pursuit" (AKA "hot pursuit" in television lingo) will allow brazen "reverse-hacks"; but in my experience, law enforcement officials get little or no leniency when it comes to actively tracing back through an innocent third party network. The corporate sector, while slightly more relaxed than law enforcement in many 'net legal issues; still frowns upon trespassing, regardless of the reason why. I would be interested in knowing precisely how, therefore, the determination that "The Analyzer" came "through 13 different servers" was discovered and verified.

As a side note that's totally unrelated, the views expressed in the Salon article stating there was "...not really..." any way to stop DDoS attacks is ludicrous and incredibly narrow in vision. Egress packet filtering at the gateway won't stop the trojan'ed programs from executing, I grant that; but it definitely WILL stop or at least severely limit the economic devastation caused by such attacks. If you aren't sure of an answer, then dodge the topic temporarily or say you don't know then go find out. Those who have knowledge but hoard that information; are as guilty as the crackers or are at a minimum complicit with them. Saying there is no way to stop that kind of attack when there is (albeit a tad difficult to implement) may be construed in some circles as unethical.

Disclaimer: Note that the words stated herein are those of the author only and do not necessarily reflect the opinions or views of his employer. No such implication should be implied.

Curt Bryson
Computer Forensics Consultant