From owner-freebsd-ipfw@FreeBSD.ORG Fri Jun 17 20:16:41 2005 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1533B16A41C for ; Fri, 17 Jun 2005 20:16:41 +0000 (GMT) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 4828D43D49 for ; Fri, 17 Jun 2005 20:16:39 +0000 (GMT) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 59330 invoked by uid 0); 17 Jun 2005 17:16:50 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (uvscan: v4.3.20/v4516. spamassassin: 2.64. Clear:RC:1(201.17.165.147):. Processed in 0.409964 secs); 17 Jun 2005 20:16:50 -0000 Received: from unknown (HELO ?10.69.69.69?) (201.17.165.147) by capeta.freebsdbrasil.com.br with SMTP; 17 Jun 2005 17:16:50 -0300 Message-ID: <42B32FA5.5000804@freebsdbrasil.com.br> Date: Fri, 17 Jun 2005 17:16:37 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050420 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Swiger References: <42B32B60.5060208@mac.com> In-Reply-To: <42B32B60.5060208@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, "Alexandre D." , Gilberto Villani Brito Subject: Re: Pipes. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2005 20:16:41 -0000 Chuck Swiger wrote: > Alexandre D. wrote: > >> The answer is not so easy. >> P2P is not only based on port numbers. >> The P2P detection is quite difficult, and maybe impossible. > > > Not at all. Start with "deny all", and only allow stuff through which > you really need to allow. Blocking all outbound client traffic and > requiring them to go through a proxy on the LAN is adequate. > >> My own position is that ipfw is not able to block P2P > > > Besides, the word was "control". You can shunt all high-priority stuff > (NTP, DNS, ICMP) into one queue, and put HTTP, FTP, 6667, etc on a > low-priority queue via dummynet, and/or adjust the permitted bandwidth. > I personally like this approach a lot. I think it should be the first way to try to do what you need with packets which you might need to "open" and "look inside" to check what kind of traffic it is. At a very least you will have a very organized gateway/fw/segment of network, with closed policy and services policy. It might avoid a number of future problems. My understanding is that a IP packet filter, as it states, should only do packet filtering. I dislike "general purpose" tools. Content analisys "picking the packet, looking at it to figure what kind of data/flow it is" should be managed by other kind of tools. Back to the question point, there is a program somehwere in the net which allows you to "ipfw divert" the traffic to it, which can later filter traffic based on contents/layer7. You can also use an IDS, say, snort, and make IPFW filter/pipe/queue traffic for you based on snort rules/matching. There is "SnortSam" which might fit your needs if you can have snort. I dont remeber the "divert based" program name or URL, Ill check on my bookmarks and post it later. -- Patrick Tracanelli FreeBSD Brasil LTDA. The FreeBSD pt_BR Documentation Project http://www.freebsdbrasil.com.br patrick @ freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!"