Detecting P2P

Problem

How can I detect when users on my network(s) are using peer-to-peer (P2P) applications, possibly putting our company on the RIAA's radar for investigation?

Solution

Much like the IM problem, P2P applications are hard to detect on your network. Users can choose from dozens of networks and just as many clients. One ideal solution would be to have a default policy of deny first on your firewall's outbound traffic. However, in the real world of politics, corporate networking policies, and management exceptions, the ideal solution is rarely possible. So, we'll just try to track the most popular networks: Kazaa, BitTorrent, and Gnutella.

Kazaa

The Kazaa network is actually a mini HTTP protocol for sending files and browsing other user's shared files. It sets up the client to communicate on port 1214/tcp. The following rule detects outbound connections on the Kazaa port:

Alert tcp $HOME_NET any -> $EXTERNAL_NET 1214 (msg:"Kazaa port in 

use"; flow:to_server;established; sid:10503; rev:1;)

The next example narrows the rule to detect when one of your users actually has the Kazaa client installed.

Alert tcp $HOME_NET any -> $EXTERNAL_NET 1214 (msg:"Kazaa client 

activity"; flow:from_client,established; content:"GET"; content:

"KazaaClient"; classtype:policy-violation; sid:10561; rev:1;)

While there are some other ways to detect Kazaa traffic, these should get you started.

BitTorrent

BitTorrent has legitimate uses. Certain Linux distributions use it to help people get new versions of their software. However, the vast majority of these connections are used to share pirated software and movies. According to the official BitTorrent site: "Prior to version 3.2, BitTorrent by default uses ports in the range of 6881-6889. As of 3.2 and later, the range has been extended to 6881-6999. (These are all TCP ports, BitTorrent does not use UDP.)" However, BitTorrent has been known to use HTTP ports for communication as well.

One method of detecting BitTorrent is to track when it's installed on a client machine. The following rule detects when a user downloads the Windows version of the BitTorrent client:

Alert tcp $HOME_NET any -> any $HTTP_PORTS (msg:Bit Torrent Client 

download"; uricontent:"BitTorrent"; uricontent:".exe"; classtype: 

bad-unknown; sid:10559; rev:1;)

Another method is to determine whether the client is already installed on a workstation and when it is being used. This signature detects when an installed client is communicating with another BitTorrent server.

Alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"Bit Torrent client 

usage"; content:"|00 00 40 09 07 00 00 00|"; offset:0; depth:4; 

classtype: policy-violation; reference:url,

www.bleedingsnort.com/bleeding.rules; sid:10560; rev:1;)

 

Gnutella

Gnutella is another popular file-sharing application. This application, like Kazaa, has a default port (6346/tcp) that opens up on the client machine, as well as the port used for communicating with the Gnutella network. The following rule fires when the client is communicating on your network. This rule comes from the official Snort rules, number 557.


alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"p2p Gnutella client 

request"; flow:to_server,established; content:"GNUTELLA OK"; depth:40; 

classtype:policy-violation; sid:557; rev:6;)

The following rule determines when an installed client is actually downloading files.


Alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"p2p Gnutella client 

file connection"; flow:from_client,established; content:"X-Gnutel"; 

classtype:policy-violation; sid:10566; rev:1;)

 

Discussion

These few specific rules should give you some idea of the range and flexibility of P2P clients to surf your network. More clients and more networks are available to your users. Several options can help you detect and defend against these applications.

Policy solutions:

  • Restrict access and block networks that are known to have these clients.
  • Set workstation host profiles that deny user access to install these clients.
  • Scan your network for common ports at odd times to find the clients when active.

Snort solutions:

  • Find more effective rules to detect a broader scope of P2P clients.
  • Use the stream4 preprocessor to enable the keyword keepstats machine. This records session information about your network. Then use a manual process such as:
cat session.log | awk '{ print $12 }' | sort | uniq -c | sort -nr >

Top_ports_uniq_connections.txt
  • This gives us a count of the top ports in use on the network. Then I would look for talkative hosts on the network with the following commands:
cat session.log | awk '{ print $19 }' | sort | uniq -c | sort -nr > 

Top_clients_uniq_connections.txt

Immediately mark out known server, and you are left with your top talking hosts. With a little scripting, you can determine with what ports and to whom your talk workstation has been communicating.

One feature of all P2P users on a network is that they will have lots of connections both in and out of your network. So keeping a count of network usage plays a large part in detection, especially on larger networks.

See Also

http://www.bleedingsnort.com

Snort rules and mailing lists (http://www.snort.org)

Detecting IDS Evasion

Installing Snort from Source on Unix

Logging to a File Quickly

How to Build Rules

Detecting Stateless Attacks and Stream Reassembly

Managing Snort Sensors

Generating Statistical Output from Snort Logs

Monitoring Network Performance

Index

show all menu



Snort Cookbook
Snort Cookbook
ISBN: 0596007914
EAN: 2147483647
Year: 2006
Pages: 167
Similar book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net