From owner-freebsd-pf@FreeBSD.ORG Wed Jul 23 19:21:57 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E497C106567B for ; Wed, 23 Jul 2008 19:21:56 +0000 (UTC) (envelope-from ivanatora@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id A2B198FC19 for ; Wed, 23 Jul 2008 19:21:56 +0000 (UTC) (envelope-from ivanatora@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so984714ywe.13 for ; Wed, 23 Jul 2008 12:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=/+wZONWqGoipPPpn35s+5LRnpqCF35e+CVDAWW4BHMk=; b=Dgmu+NtG+tFABw1jQ8el6B8YbC9jb2ZqKZMuUkuVrmxzjmZs+A8cptfJulsBv4y4ll ZeJ1tN9PmdaBKmgQYFTEygRIyqqotCmjZdgSPNxIs4hNEmxEpQtCPJL8o7wiTXWmFGLi Sh3pe+rwBckEF4vp1EJ/YNfIgYu7zGsDA4noM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MUkKWgDFXFmfq4UHAPcrEW08736OmGfFOZs2CtvyTohoxsjME7uNLyHd6pZ3xuRHdC qzOhBXpdMnwBW4GQGumoSZstp7m4f5pDq96VYOIw65uYPaiyVzfF8anBoUeMn25QtMQa 3gB8nYnBV3siPtlQbb9ld5+5uposjTg7J/P9k= Received: by 10.151.84.12 with SMTP id m12mr2110ybl.221.1216840915770; Wed, 23 Jul 2008 12:21:55 -0700 (PDT) Received: by 10.151.50.12 with HTTP; Wed, 23 Jul 2008 12:21:55 -0700 (PDT) Message-ID: Date: Wed, 23 Jul 2008 22:21:55 +0300 From: "Ivan Petrushev" To: "Jon Radel" In-Reply-To: <488780A6.4010807@radel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48876DAD.9080100@optiksecurite.com> <488780A6.4010807@radel.com> Cc: freebsd-pf@freebsd.org Subject: Re: Why this rule doesn't score a match? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 19:21:57 -0000 Hi Jon, Aaahhh, I see now - these FROM rules must be TO rules :D Thank you both for your replies. I'm going to monitor the outbond connections as well, but I think I will be OK then. This was the little stone in the shoe. I've already managed to let ICMP trough that 'block all' ;) Btw, I like the way pflog is working - deploying tcpdump on pflog0 and track down the logged packets. Is there a way to create another pflog device and use it for some different rules? I've seen there is an option to the 'log' keyword - (to pflogX), but I didn't managed to find out how to create more pflog devices. Regards, Ivan. On Wed, Jul 23, 2008 at 10:04 PM, Jon Radel wrote: > Ivan Petrushev wrote: >> >> Hmmm, yes I'm on FreeBSD 7 >> I tried these pass rules before - nothing gets logged. >> I thought traffic is going both TO these ports and FROM these ports. >> Let's take for example a simple HTTP connection. The browser >> communicates to the remote server trough remote port 80 and says 'GET >> /index.html', then closes the connection. The HTTP server on the >> remote side opens a connection to the local machine (on some of our >> local port range)... but what is the port number on his side? I think >> that it is again 80. >> About pass in/pass out - I think that in/out keyword can be dropped? >> PF can do without that, right? >> >> These are my current filter rules, still nothing gets logged: >> ############################## >> pass log on $if proto tcp from any port $tcp_services >> pass log on $if proto udp from any port $udp_services >> pass log on $if proto tcp from any to $ext_ip port $tcp_services >> pass log on $if proto udp from any to $ext_ip port $udp_services >> ############################# > > HTTP doesn't work like that. The client opens a connection from an > arbitrary port (generally high and pseudo-random) to port 80 (or 8080, or > whatever the published port the server listens on is). The server does NOT > open a connection to you. > > Your initial packet to the web server > > from YOU port NNNN > to SERVER port 80 > > never gets through your rule set so there's never a response from the server > to get logged. > > You'd do much better, if this is a workstation on which you run a webbrowser > and other clients, rather than a router/firewall, to do something like: > > pass out on $if proto tcp to any port $tcp_services flags S/SA keep state > > This allows the initial packet from your machine out and uses the PF state > mechanism (which you really, really, really should be using for reasons of > efficiency and security) to allow all further packets for that TCP > connection both in and out on that interface. > > Unless you're offering services on this computer to which you want other > machines to establish connections, you're much better off having no, or > minimal, "pass in" rules. That way people can't send you random, possibly > nasty, packets which you accept simply because they used a source port of > 80. > > --Jon Radel >