Вы находитесь на странице: 1из 2
[Released July 23, 2000] Last week, in our mailing list announcement, I included a 'note'

[Released July 23, 2000]

Last week, in our mailing list announcement, I included a 'note' about the technical design of Carnivore, the FBI's packet-sniffing device for electronic email tracing. I am amazed at the number of replies and reactions I received. The replies ranged from technical corrections and additions (add SMTP to the list of filtered ports, please) to very animated arguments against the US Government and all related agencies (typically, Waco and Ruby Ridge were mentioned).

I am still anxious to hear your thoughts -- please send them to me at carnivore@packet- level.com. Below is an updated version of that Carnivore note.

"Carnivore most likely performs multiple boolean filter operations and the Carnivore system must be placed in the path of the interesting data (i.e., at the appropriate ISP). By filtering on packets to and from the POP port 110 (POP3), IMAP port 143, and SMTP port 25, Carnivore can capture all email on the wire.

Carnivorous Beings

Now, here's where it gets a bit sticky

system is set up with a simple port-level filtering mechanism and it is placed in a location that serves the traffic from multiple email sources, then the answer is yes. I am certain, however, that Carnivore must have a more complex filtering mechanism to automatically wade through the sea of mail and other data that would pass 'through' it and ensure that 'interesting mail' is captured.

can Carnivore look at your email or my email? If the

The second level of filtering would focus in specifically on traffic coming from/going to the suspect or party of interest. Can Carnivore use the source/destination IP address for this purpose? Certainly, as long as that address is static (or at least somewhat predictable). This is where the ISP must become involved to begin the process of setting up a trace-back to focus on the suspect's traffic only by examining the current IP address log.

There are many concerns on how such a process should be implemented. Many ISPs don't want the FBI bringing in Carnivore into their shop due to potential security problems or operational/technical problems. That is certainly understandable, but we've got to give law enforcement a method for wiretapping the bad guys, folks -- don't we?

Herbivore

Last week I was talking with an old buddy of mine from the Novell days

probes and their operation

was an RMON agent-type device that captured packets. You would place the Lantern on the segment that contained the interesting traffic that you wanted to capture (in this case, put it where

the mail servers reside). The Lantern manager (early ManageWise) would query the Lantern device for the traffic information. In the case of Carnivore, however, we wouldn't want to see the

we recalled the Lantern

why couldn't something like that be done here? Basically, Lantern

data cross the wire a second time (encrypted or not) -- we'd want to 'dump' the data into a holding tank that is picked up by the authorities.

We refer to this solution/system as Herbivore <grin>.

Carnivore in Your Shop?

Yes, but I recommend that you check on the legal implications of such a filter -- remember the

sigh.)

Fourth Amendment (in the US)? (Wish I'd paid more attention in that US History class

It is easy to building an in-house Carnivore system. Simply build a boolean filter that matches this pattern where 10.0.52.123 is the address of the suspect station.

where 10.0.52.123 is the address of the suspect station. Now, I really didn't need to make

Now, I really didn't need to make the address filtering portion focused on source OR destination -- I could have simply stated that I am interested in packets FROM 10.0.52.123 to any of the mail ports. It is my habit, however, to build address filters to be bi-directional (you never know if they are bringing up a POP server, eh?).

This paper defines a theoretical product only (Hervbivore).

Laura Chappell Sr. Protocol Analyst Protocol Analysis Institute, LLC www.packet-level.com