Filtering on Stinkin Peer-to- Peer Application Commands

---

Filtering on Stinkin’ Peer-to- Peer Application Commands

This filter is a bit more advanced -- you’ll look for specific signatures used by lousy applications.

You may have read some of the articles I wrote for Novell Connection Magazine on Gnutella, Morpheus, and iMesh. I agree with the folks who label these peer-to-peer file sharing applications as the killer app for the Internet -- I think they’ll kill the Internet (and they may take your network down with it).

Napster gave us our first taste of peer-to-peer file sharing in a large scale across the Internet. People loved it -- of course there’s a little thing called “copyright infringement” that forced the Napster service to self-mutilate down to a shadow of its former self.

Since then, there have been numerous other peer-to-peer file sharing applications launched on the poor unsuspecting public. In the best case, these applications only pose a security risk (allowing employees to bypass corporate authentication and passwording to share network drives with the world). In the worst case scenario, they consume precious network bandwidth and provide another entry point for viruses and worms.

We’ll focus on three of these ugly beasts -- Gnutella, Morpheus and iMesh.

Filtering Out Gnutella Traffic

On March 14, 2000, Nullsoft, the developer of Winamp and now owned by AOL, released an "open source Napster clone" named Gnutella (pronounced nu-tell-a). Gnutella provides peer-to-peer file sharing.

During a recent network security audit, the client's IS team and I noticed a matrix traffic pattern indicated that a single IP host was receiving packets from over 82 IP devices through the PIX firewall. Now that may not be so unusual given the fact that we regularly get connected to third-party websites when we browse (especially when we connect to a site that is loaded down with ads). Interestingly, however, this one IP address was making connections at in a very deliberate and fast pace.

We immediately began capturing all traffic to and from our local host with a simple IP address filter. Upon examination of the packets we noticed that all traffic was to and from port 6346. Neither Sniffer nor EtherPeek could identify the type of traffic above the TCP layer, as shown in Figure 52. The port number list (online at www.iana.org) indicated this was a Gnutella communication.

Figure 52: In the hex decode you can read the term “GNUTELLA CONNECT.”

Gnutella is a peer-to-peer file sharing protocol that has gained a worldwide audience similar to the Napster audience. Simple to load and use, Gnutella offers a quick way to share files (mp3, software, images, audio, video, etc.) with users across the Internet. Gnutella hosts are called servents.

When someone in your office loads on the of the many Gnutella clients (LimeWire, BearShare, eBlvd, etc.), they become a

Gnutella servent. The method servent’s use to learn each other’s address is not defined in the Gnutella specification, but in one trace we noticed that the Gnutella website sent a list of IP addresses of active Gnutella servents.

Next the servents send protocol descriptors to each other. Protocol descriptors describe the purpose of the packet. There are five protocol descriptors defined for Gnutella v0.4:

0x00	Ping - Used to probe for other servents.
0x01	Pong - Response to ping (includes number of files/kb to share)
0x40	Push - Request to send using different port number.
0x80	Query - A request for a file.
0x81	Query Hit - Response indicating sender has file meeting search criteria.

In our captured trace, we saw the servent receive the list of the IP addresses used by other registered Gnutellians from the website that the Gnutella software was launched from www.bearshare.com. The user then attempts to establish a TCP connection with each of the other Gnutellians. This could be hundreds or even thousands of other devices.

After the connections are established, the other Gnutellians immediately begin sending their list of searches through the Gnutella network. This traffic rate runs between 4500 and 5300 bytes per second - unnecessary overhead.

A Gnutella host can share any local files…. ANY local files. That includes mapped or mounted drives and files. This is a huge security risk! Educate your users!

When a ping request comes into a servent, the servent routes the ping to all other connected servents - it does not send the ping back the way it came. When the desired servent receives the ping, it sends a pong back the way it came. All servents act as routers for Gnutella protocol descriptors.

When a Query is sent out, all receiving servents route the packet to all other servents (not back the way it came) and then examine their shared file area to determine if they can fulfill the query. If they can fulfill the query, they send a QueryHit descriptor to the source servent's ID address. Note that the source servent may not be the actual host requesting the file - it may be the IP address of the last servent that forwarded the descriptor.

Figure 53: Gnutella responses follow the original request path through the network.

Figure 53 shows how the traffic flows through a Gnutella network. Notice that the query for "beatles" never flows back the way it came and the QueryHit is returned through the same path the Query used.

For more information on the payload descriptor field, check out the September article online at www.nwconnection.com.

Warning 

If you start to analyze Gnutella traffic be prepared to see some pretty raunchy searches. Currently, it appears that about 25% of the Gnutella searches are pornography-related. I have a Gnutella trace file online at www.packet-level.com.

Files are not actually transferred using the Gnutella protocol - files are transferred using standard HTTP GET commands. The command contains the following parameters:

GET /get/<file index>/<file name>/HTTP/1.0 User-Agent: <Gnutella network>

For example, in my download of the Beatles song, Blue Jay Way, my HTTP packet contains the GET parameters as follows:

GET /get/<69>/Beatles - Blue Jay Way.mp3/HTTP/1.0 User-Agent: LimeWire 1.6b 

Figure 54: We can see a sudden spike in the traffic rate when a Gnutella client boots up.

The Gnutella protocol specification offers a method for getting around firewalls that may be blocking the file download process. If the servent that has the desired file does not permit an incoming file download connection on the Gnutella default port, it can send a Push request that lists an IP address and a port to use.

Alternately, users inside a company can get around a firewall by setting up the Gnutella application to use ports that are allowed through the firewall, such as port 80 (HTTP), 443 (HTTPS), 23 (telnet), 25 (SMTP), or 110 (POP3).

Just when you thought it was bad enough… here comes a little salt for that network wound. In February 2001, a worm named Mandragore (also referred to as W32/Gnuman) infected the Gnutella network posing as a regular media file. Once down- loaded and run, however, this executable file infects the Gnutella victim and spreads to other computers, constantly changing its name to match all media search requests.

Note 

For more information on the Mandragore virus, refer to www.mcafee.com. -- Laura

I believe we are just seeing the tip of the iceberg. Gnutella will offer a special set of challenges for networks large and small. The goal should be complete and absolute eradication of Gnutella on the corporate network.

I can think of three possible ways to deal with Gnutella traffic on the network:

Step 1: Set up port filtering. For example, set up BorderManager to filter on incoming and outgoing ports 6346 (Gnutella) and 6347 (Gnutella router).

Step 2: Define corporate policy regarding shared network access. Ensure all users understand the security and performance issues associated with peer-to-peer networks such as Gnutella. Educate users on the various forms of Gnutella networks, such as LimeWire, eBlvd and BearShare.

Step 3: Analyze all traffic looking for Gnutella signatures. The first signature to look for is the Gnutella port number 6346. Secondly, look for the "Gnutella-Connect" text string - this will catch any Gnutella traffic using a non-default port number. Also build and use a filter that looks for the "GET /get/" string used to start a Gnutella file transfer. Figures 55 and 56 show the filters used to capture these signatures.

Figure 55: The first pattern should catch the connection sequence.

Figure 56: The second pattern will catch the start of the actual file transfer process.

Don't wait until your network suffers from Gnutella overhead, security leaks or worms. Start shutting down those Gnutella ports and begin educating your users.

For more information on Gnutella, visit:

• http://www.limewire.com

• http://www.bearshare.com

• http://www.gnutellanews.com

• http://www.gnutelliums.com

• http://www.gnutella.co.uk

• http://www.gnutella.wego.com

• http://www.zeropaid.com

Morpheus and iMesh are also peer-to-peer file sharing programs that offer threats to security and bandwidth.

Again, these filters are created on Sniffer Pro. If you are using another analyzer, such as EtherPeek, just keep in mind that you may need to change the offsets into decimal format.

Morpheus is not as bandwidth-intensive as Gnutella, but it poses a security risk nonetheless.

There are two standard ways to catch Morpheus traffic - either look for traffic to and from the Morpheus default port 1214 or filter on two known traffic signatures:

• DNS query for supernode3.streamcastnetworks.com

• DNS query for supernode.kazaa.com

Figures 57 through 58 shows the filters used to catch Morpheus traffic based on the default Morpheus port number, 1214 (decimal) or 0x04BE (hexadecimal).

Figure 57: This first filter looks for all traffic that uses the source port 1214 (0x04BE in hexadecimal).

Figure 58: This pattern looks for packets going to the Morpheus default port 1214.

We can use the OR operand to combine the patterns shown in Figures 57 and 58 and catch the Morpheus traffic that uses the default port.^[15]

We can filter on the two DNS queries that the Morpheus client makes at the time it starts up. By building a filter for either of these DNS queries, you can detect when a Morpheus application has started up regardless of the port number it is using.

Figures 59 through 60 show the filters used to catch the DNS queries listed earlier in this section. Remember to use the OR operand, not the AND operand.

Figure 59: Always start DNS filters with a leading period. In this case, the entire site name doesn’t fit in one pattern, but we’re pretty sure we’ll catch the relevant packets.

Figure 60: The second pattern should be used in your filter as well.

That's not too difficult, eh?

Note 

You might consider setting up a firewall to block access to each of the web sites listed in the DNS queries. You won't catch the Morpheus clients if the DNS sites change someday, however. -- Laura

For more information on Morpheus, check out www.musiccity.com, www.kazaa.com (no hyphen).

Now let's turn our attention to iMesh.

Interestingly, iMesh doesn't seem to use a specific set of port numbers - it starts port roaming from the moment it tries to connect to the iMesh server. Figures 64 through 65 show the filters used to catch iMesh traffic on the network. We must look for the two application-level signatures of iMesh.

The first filter is designed to catch the iMesh DNS query for www.imesh.com. Although you might consider building a web site filter to stop folks from going to iMesh.com… that won't work. The DNS response indicates that the site the users connect to can change - they don't actually connect to www.imesh.com.

Again, we'll use an OR operand in this filter. We want to catch packets that match the DNS query or the application command starting with "MIME TYPE," as shown in Figure 61.

Figure 61: Build a filter that looks for the iMesh DNS query.

Figure 62 shows the second pattern that looks for the pattern

"MIME TYPE = HTML." ^[16]

Figure 62: The only command that could be identified in the iMesh traffic is a reference to the 'mime type'.

For more information on iMesh, check out www.imesh.com.

Every application has some type of signature in it - something that distinguishes it from other traffic on the network. Building a strong set of filters enables you to get the most out of your analyzer.

Check out www.sniffer.com and www.wildpackets.com to see if they have any filters listed online. If you create an awesome filter, please let me know ([e-mail]).

From here, I recommend that you go through the Chapter Four Test and then check out Appendix C and D to import filters into your Sniffer and EtherPeek systems.

^[15]At some point, however, we must consider that Morpheus will start to port roam as their connections are blocked by firewalls. In this case, we need to use more advanced filters - filters based on the application-layer packets that are unique to Morpheus.

^[16]It is important to note that on the Sniffer you need to press the space bar to insert the spaces between words and the equal sign. If you skip the blank spaces all together, the Sniffer will clip off the remainder of the filter line. Aargh!

---