Blocking P2P

ITKnowledge Exchange member "rmrsystems" had a question about how to block P2P activity and fellow techies helped out. Here is a portion of the conversation.

ITKnowledge Exchange member "rmrsystems" had a question about how to block P2P activity and fellow techies helped out. Here is a portion of the conversation. Read the rest of the thread.

Want to join in on a similar conversation? Register for ITKnowledge Exchange and fill out your profile so you can

ask specific sets of people your IT questions and also help out your fellow geeks.


ITKnowledge Exchange member "rmrsystems" asked:
I manage a small SBS2003 network, which doesn't have ISA server (i.e., the SBS box and all the clients are wired via a switch to the ADSL router -- Netgear DG834G). One of the users has been downloading MP3s from a P2P network, and I want to block this sort of activity.

Can I just block particular outgoing ports on the router? If so, which ports do I need to block, and are there any legitimate services that may be affected?

"BRIAVAEL" WRITES:
You're going to be caught up in Whack-a-Mole trying to block access by ports. These programs have gotten pretty good at port hopping and using well-known open ports like 80 or 21.

That said, the various programs use different ports. The two popular ones:

  1. Fast-Track (i.e., Kazaa and Morpheus): 1214
  2. Gnutella (i.e., Limewire and Bearshare): 6346 and 6347
What I would do is build a Linux firewall (like IPCop) and then use FTwall, which will effectively block transmission based on IP tables. The result is to block network access of a user who launches a P2P client. They will only get access back once the program is closed completely.

Of course, adding a new platform to your network may not be what you wish to do. You would best be served by establishing an Acceptable Use policy. Personally I like having both a technical solution as well as policy to back it up.

itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke

"MENNOT" WRITES:
Any decent router has the possibility to block unwanted traffic. The best solution is not to look at evil things that you want to block, but to see what you want to allow -- for instance, HTTP (TCP/80), HTTPS (TCP/443), SMTP (TCP/25) and possibly a few other things. Just block the rest! To be more secure, you should preferably allow these protocols only via a proxy -- or, for e-mail, a secure SMTP relay server with virus scanning -- so you can also limit the IP addresses that can go out.

Looking for information about your router on the Netgear Web site, I found clear instructions how to define authorization rules; see How is port forwarding configured? to create an inbound or outbound rule. Using that procedure, define outbound rules for the services you want to allow and block the remainder. Possibly with the exception of e-mail, you probably don't run services that should be accessible from the Internet, so block all inbound traffic except that service (if you need it). You can further tighten inbound access by restricting it to a specific host.

Blocking everything and waiting for your people start to complain is an approach, if you can afford it. A slight modification to this is to begin with an inquiry as to what is happening now and define rules for that -- at least as far as you can identify it (otherwise Kazaa and others would get in the rule set as well!). Maybe the router allows you to collect such data. Otherwise, you could start with a list of applications that are officially in use and find the TCP/UDP port numbers of it. If you don't know the port numbers, start the application on a machine and give a netstat command in parallel.

Be careful: Some applications use random high ports (1024 and higher) next to a fixed port, forcing you to open a port range. This is something you must recognize. Also, some applications set up sessions in the reverse direction, making it necessary to open ports in the opposite direction as well. (An example of this is FTP, but most firewalls will allow the secondary session automatically.)

Blocking all incoming traffic might lead to problems, even though the initiative is only from the inside! Some trial and error may sometimes be unavoidable to get things working in spite of all the blocking. Things like instant messaging (if you allow that) could prove difficult.

itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke

"CISCOCAT6K" WRITES:
If you want a hardware/software solution look at BlueCoat. It is very effective at blocking this type of traffic, the problem with which is that it can tunnel out on port 80, thereby making it difficult to use port blocking. BlueCoat also gives you granular control over the use of IM, Webmail and various other firewall-opening services.

Additionally you could install a Checkpoint firewall on a Nokia platform for deep packet inspection. The Checkpoint NG-AI systems can block a great deal of IM and P2P services.

If cheap and cheerful is what you wish, try installing Squid with Squidguard on a Linux platform for a nice Web-caching and URL filter solution. Squidguard will allow you to also stop the P2P issues while giving you the advantage of a Web cache engine to help with your outside world link. The software is free; you just need to find some old hardware to install it on. Will run very comfortably on an old P2/P3 box for up to around 500 users (in my experience).

Hope this helps.



This was first published in March 2005

Dig deeper on Network Hardware

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close