From owner-freebsd-pf@FreeBSD.ORG Mon Jul 26 11:07:08 2010 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 4077D1065673 for ; Mon, 26 Jul 2010 11:07:08 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 352B28FC14 for ; Mon, 26 Jul 2010 11:07:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6QB78cG080765 for ; Mon, 26 Jul 2010 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6QB77Oc080762 for freebsd-pf@FreeBSD.org; Mon, 26 Jul 2010 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Jul 2010 11:07:07 GMT Message-Id: <201007261107.o6QB77Oc080762@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org 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: Mon, 26 Jul 2010 11:07:08 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/148290 pf [pf] "sticky-address" option of Packet Filter (PF) blo o kern/148260 pf [pf] [patch] pf rdr incompatible with dummynet o kern/147789 pf [pf] Firewall PF no longer drops connections by sendin o kern/146832 pf [pf] "(self)" not always matching all local IPv6 addre o kern/144311 pf [pf] [icmp] massive ICMP storm on lo0 occurs when usin o kern/143543 pf [pf] [panic] PF route-to causes kernel panic o bin/143504 pf [patch] outgoing states are not killed by authpf(8) o conf/142961 pf [pf] No way to adjust pidfile in pflogd o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty o kern/140697 pf [pf] pf behaviour changes - must be documented o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 47 problems total. From owner-freebsd-pf@FreeBSD.ORG Mon Jul 26 12:46:45 2010 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 A019A106564A for ; Mon, 26 Jul 2010 12:46:45 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [69.42.208.18]) by mx1.freebsd.org (Postfix) with ESMTP id 93EB68FC25 for ; Mon, 26 Jul 2010 12:46:45 +0000 (UTC) Received: from [192.168.1.64] (99-118-214-35.lightspeed.irvnca.sbcglobal.net [99.118.214.35]) by sed.awknet.com (Postfix) with ESMTP id 3ECA4107C9D5 for ; Mon, 26 Jul 2010 12:26:21 +0000 (UTC) Message-ID: <4C4D7EED.4060704@sk1llz.net> Date: Mon, 26 Jul 2010 05:26:21 -0700 From: Justin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: pf synproxy 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: Mon, 26 Jul 2010 12:46:45 -0000 Hello all - I've tried searching the list but it seems something is broken and I'm getting 500 errors. Alas, Is there something unique about using synproxy in a gateway style firewall that isn't outlined in the PF manuals? Here's the scenario: Internet -> em0 | pf rules | em1 -> target host. 1.2.3.1/29 on em0, 1.2.4.1/29 on em1, 1.2.5.1/29 on target host. PF rules: set skip on lo0 pass out on em1 pass in on em1 pass out on em0 proto tcp all modulate state pass in on em0 proto tcp from any to any port 80 synproxy state When using synproxy state - the connection never completes. If we change synproxy to keep, everything works fine. Alternately, if the service in question is running locally on the actual firewall itself, I'll see state entries show up in pfctl -s doing a proxy and then passing the connection on to its self - so why doesn't it work in the same manner when passing on to a host behind the machine? I've tried all sorts of variations and skipping processing on internal interface, but I just can't seem to get it to work. All my searching has turned up nothing. I've also tried state-policy if-bound and there appears to be no change. Is this a bug? Have I missed something totally obvious? -Justin From owner-freebsd-pf@FreeBSD.ORG Mon Jul 26 14:21:29 2010 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 A61BA1065677 for ; Mon, 26 Jul 2010 14:21:29 +0000 (UTC) (envelope-from dennylin93@hs.ntnu.edu.tw) Received: from mail.hs.ntnu.edu.tw (mail.hs.ntnu.edu.tw [140.131.149.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7B7208FC08 for ; Mon, 26 Jul 2010 14:21:29 +0000 (UTC) Received: by mail.hs.ntnu.edu.tw (Postfix, from userid 1001) id C85004B7825; Mon, 26 Jul 2010 22:05:45 +0800 (CST) Date: Mon, 26 Jul 2010 22:05:45 +0800 From: Denny Lin To: Justin Message-ID: <20100726140545.GB72163@mail.hs.ntnu.edu.tw> References: <4C4D7EED.4060704@sk1llz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4C4D7EED.4060704@sk1llz.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-pf@freebsd.org Subject: Re: pf synproxy 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: Mon, 26 Jul 2010 14:21:29 -0000 On Mon, Jul 26, 2010 at 05:26:21AM -0700, Justin wrote: > Hello all - I've tried searching the list but it seems something is > broken and I'm getting 500 errors. Alas, > > Is there something unique about using synproxy in a gateway style > firewall that isn't outlined in the PF manuals? Here's the scenario: > > Internet -> em0 | pf rules | em1 -> target host. Synproxy does not work when on bridges. >From pf.conf(5): Rules with synproxy will not work if pf(4) operates on a if_bridge(4). -- Denny Lin From owner-freebsd-pf@FreeBSD.ORG Mon Jul 26 15:02:27 2010 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 639A6106566B for ; Mon, 26 Jul 2010 15:02:27 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [69.42.208.18]) by mx1.freebsd.org (Postfix) with ESMTP id 538B88FC14 for ; Mon, 26 Jul 2010 15:02:27 +0000 (UTC) Received: from [192.168.1.64] (99-118-214-35.lightspeed.irvnca.sbcglobal.net [99.118.214.35]) by sed.awknet.com (Postfix) with ESMTP id 14E6F1082464 for ; Mon, 26 Jul 2010 15:02:27 +0000 (UTC) Message-ID: <4C4DA384.8030504@sk1llz.net> Date: Mon, 26 Jul 2010 08:02:28 -0700 From: Justin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <4C4D7EED.4060704@sk1llz.net> <20100726140545.GB72163@mail.hs.ntnu.edu.tw> In-Reply-To: <20100726140545.GB72163@mail.hs.ntnu.edu.tw> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: pf synproxy 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: Mon, 26 Jul 2010 15:02:27 -0000 ... it's not an if_bridge, thanks. On 7/26/2010 7:05 AM, Denny Lin wrote: > On Mon, Jul 26, 2010 at 05:26:21AM -0700, Justin wrote: > >> Hello all - I've tried searching the list but it seems something is >> broken and I'm getting 500 errors. Alas, >> >> Is there something unique about using synproxy in a gateway style >> firewall that isn't outlined in the PF manuals? Here's the scenario: >> >> Internet -> em0 | pf rules | em1 -> target host. >> > Synproxy does not work when on bridges. > > From pf.conf(5): > Rules with synproxy will not work if pf(4) operates on a if_bridge(4). > > From owner-freebsd-pf@FreeBSD.ORG Mon Jul 26 15:48:52 2010 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 ECA901065674 for ; Mon, 26 Jul 2010 15:48:52 +0000 (UTC) (envelope-from andrei.manescu@ivorde.ro) Received: from mail.ivorde.ro (mail.ivorde.ro [82.76.71.249]) by mx1.freebsd.org (Postfix) with ESMTP id 3AC548FC1D for ; Mon, 26 Jul 2010 15:48:51 +0000 (UTC) Comment: DomainKeys? See http://domainkeys.sourceforge.net/ DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=ivorde.ro; b=XfcpfYZHedlB+z7On3FMUIcGZmc6GdUizwahrPsiFiCR5psBQgfOAcg3xXvcq/M64K7eJCjsfbIUiXMyBDxv+nyBMgfc2c6Fupa95NIYwk047g+y+OAGKG3ae5Ni3Jlr; h=Received:Received:Received:Message-ID:In-Reply-To:References:Date:Subject:From:To:Cc:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ivorde.ro; h=message-id :in-reply-to:references:date:subject:from:to:cc:mime-version :content-type:content-transfer-encoding; s=default; bh=bnuytU4ef +eJm13ubVHY16cWx30=; b=i9jHFWxsb80Nn1bEAIedKRML+FFMunNXXUsAIjVq+ OBDzXR/DbMOtaQkZY8DD/zUEvIta1UuKN2SojIgrcHVrTe4lbly8qIfky7OMvkqv sIWvCc2o1hyR3PHVIJQER5u Received: (qmail 46384 invoked by uid 1001); 26 Jul 2010 18:22:09 +0300 Received: from mail.ivorde.ro (192.168.1.11) by mail.ivorde.ro with SMTP; 26 Jul 2010 18:22:09 +0300 Received: from 193.110.48.4 (SquirrelMail authenticated user andrei.manescu@ivorde.ro) by mail.ivorde.ro with HTTP; Mon, 26 Jul 2010 18:22:09 +0300 Message-ID: In-Reply-To: <4C4DA384.8030504@sk1llz.net> References: <4C4D7EED.4060704@sk1llz.net> <20100726140545.GB72163@mail.hs.ntnu.edu.tw> <4C4DA384.8030504@sk1llz.net> Date: Mon, 26 Jul 2010 18:22:09 +0300 From: "Andrei Manescu - Ivorde" To: "Justin" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-pf@freebsd.org Subject: Re: pf synproxy 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: Mon, 26 Jul 2010 15:48:53 -0000 On Mon, July 26, 2010 6:02 pm, Justin wrote: > ... it's not an if_bridge, thanks. > > > On 7/26/2010 7:05 AM, Denny Lin wrote: > >> On Mon, Jul 26, 2010 at 05:26:21AM -0700, Justin wrote: >> >> >>> Hello all - I've tried searching the list but it seems something is >>> broken and I'm getting 500 errors. Alas, >>> >>> Is there something unique about using synproxy in a gateway style >>> firewall that isn't outlined in the PF manuals? Here's the scenario: >>> >>> Internet -> em0 | pf rules | em1 -> target host. >>> >>> >> Synproxy does not work when on bridges. >> >> >> From pf.conf(5): >> Rules with synproxy will not work if pf(4) operates on a if_bridge(4). >> >> >> > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > > If it helps, you're not the only one with issues. Synproxy is not for general fw use IMHO. I.e.: a friend is running a high traffic website and synproxy slows down the packet flow. Another example, if I remember correctly, is that it doesn't work with packet tagging, another one just mentioned, doesn't work with if_bridge... I gave up on it long time ago (on FreeBSD 6). (of course, everything is subject to different factors, like hw). You could, instead, try ftp-proxy which works great with pf and passive ftp (I really can't say how effective is it against a syn flood, but you can test it). Synproxy is a great addition to pf but, unfortunately, it doesn't lack of bugs. From owner-freebsd-pf@FreeBSD.ORG Tue Jul 27 07:48:58 2010 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 297731065673 for ; Tue, 27 Jul 2010 07:48:58 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 846A88FC14 for ; Tue, 27 Jul 2010 07:48:55 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id o6R7mrA4028443 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 27 Jul 2010 09:48:53 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id o6R7mooC025843; Tue, 27 Jul 2010 09:48:50 +0200 (MEST) Date: Tue, 27 Jul 2010 09:48:50 +0200 From: Daniel Hartmeier To: Justin Message-ID: <20100727074850.GB1114@insomnia.benzedrine.cx> References: <4C4D7EED.4060704@sk1llz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C4D7EED.4060704@sk1llz.net> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-pf@freebsd.org Subject: Re: pf synproxy 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: Tue, 27 Jul 2010 07:48:58 -0000 On Mon, Jul 26, 2010 at 05:26:21AM -0700, Justin wrote: > When using synproxy state - the connection never completes. If we change > synproxy to keep, everything works fine. Alternately, if the service in > question is running locally on the actual firewall itself, I'll see > state entries show up in pfctl -s doing a proxy and then passing the > connection on to its self - so why doesn't it work in the same manner > when passing on to a host behind the machine? I've tried all sorts of > variations and skipping processing on internal interface, but I just > can't seem to get it to work. All my searching has turned up nothing. > I've also tried state-policy if-bound and there appears to be no change. > Is this a bug? Have I missed something totally obvious? Concurrently run # tcpdump -nvSi em0 tcp port 80 and # tcpdump -nvSi em1 tcp port 80 and reproduce one connection failure. What do you see? Does the TCP handshake (SYN, SYN+ACK, ACK) complete between client and pf? And the one between pf and the server? Right after the failure, does pfctl -vvss show a state entry for the failed connection? What does it look like? Run pfctl -vvsi before and after the failure. Which counters are increasing? Enable verbose logging (pfctl -x misc), does /var/log/messages show any message possibly related to the failure? Kind regards, Daniel From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 01:24:03 2010 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 CC6F81065670 for ; Wed, 28 Jul 2010 01:24:03 +0000 (UTC) (envelope-from freebsd@com.jkkn.dk) Received: from blackbird.jkkn.net (cl-7.cph-01.dk.sixxs.net [IPv6:2001:16d8:dd00:6::2]) by mx1.freebsd.org (Postfix) with ESMTP id 566428FC18 for ; Wed, 28 Jul 2010 01:24:03 +0000 (UTC) Received: from [192.168.3.4] (hp.home.jkkn.net [192.168.3.4]) (authenticated bits=0) by blackbird.jkkn.net (envelope-from freebsd@com.jkkn.dk) (8.14.4/8.14.4) with ESMTP id o6S1NxC0011695 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 28 Jul 2010 03:24:00 +0200 (CEST) (envelope-from freebsd@com.jkkn.dk) Message-ID: <4C4F86AD.9040703@com.jkkn.dk> Date: Wed, 28 Jul 2010 03:23:57 +0200 From: =?ISO-8859-1?Q?Kristian_Kr=E6mmer_Nielsen?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.1 at blackbird.jkkn.net X-Virus-Status: Clean Subject: Time to upgrade the pf port in FreeBSD ? 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, 28 Jul 2010 01:24:03 -0000 Hey, As of time being, we still include pf as of OpenBSD 4.1 (released May 2007). Recently syntax has changed a lot in the releases of pf in OpenBSD 4.7, just notice that "nat-to" and "rtr-to" are now part of the pass-commands. This means also means that refereeing to the OpenBSD FAQ from the FreeBSD manual is close to useless. I have not be able to find a online copy of the FAQ for PF from OpenBSD 4.1, so simply changing the documentation link is not an easy option. The later version of pf is easier to use. So I was wondering, how many is actually using pf and is it time to get together and update the current port of pf included in FreeBSD to a more recent version?, e.x. the version from OpenBSD 4.7? Has anyone considered this? / is anyone interested in doing this? Best regards, Kristian Kræmmer, Odense, Denmark From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 01:28:20 2010 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 8C606106566B for ; Wed, 28 Jul 2010 01:28:20 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 36C8E8FC1E for ; Wed, 28 Jul 2010 01:28:20 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 0519DA5A759; Wed, 28 Jul 2010 09:28:19 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id AhTUd6HYMP06; Wed, 28 Jul 2010 09:28:12 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 0CB8FA55189; Wed, 28 Jul 2010 09:28:10 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:references:in-reply-to:x-enigmail-version:openpgp: content-type:content-transfer-encoding; b=apbjAsASxYqSMbNu9P4XYK+CL8W1r/tK8+UyUrLy328ogLUKAwDMQtjZJNGS+mjp3 +zAT4G5FteRPEq3E59G9g== Message-ID: <4C4F87A4.9020601@delphij.net> Date: Tue, 27 Jul 2010 18:28:04 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100721 Thunderbird/3.0.6 ThunderBrowse/3.3.1 MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <4C4F86AD.9040703@com.jkkn.dk> In-Reply-To: <4C4F86AD.9040703@com.jkkn.dk> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: Time to upgrade the pf port in FreeBSD ? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net 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, 28 Jul 2010 01:28:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/07/27 18:23, Kristian Kræmmer Nielsen wrote: > Hey, > > As of time being, we still include pf as of OpenBSD 4.1 (released May > 2007). > > Recently syntax has changed a lot in the releases of pf in OpenBSD 4.7, > just notice that "nat-to" and "rtr-to" are now part of the > pass-commands. This means also means that refereeing to the OpenBSD FAQ > from the FreeBSD manual is close to useless. I have not be able to find > a online copy of the FAQ for PF from OpenBSD 4.1, so simply changing the > documentation link is not an easy option. > > The later version of pf is easier to use. > > So I was wondering, how many is actually using pf and is it time to get > together and update the current port of pf included in FreeBSD to a more > recent version?, e.x. the version from OpenBSD 4.7? > > Has anyone considered this? / is anyone interested in doing this? IIRC someone have work in progress in a svn branch but I'm not sure if it's HEAD-ready or not... Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMT4ekAAoJEATO+BI/yjfBODoIAMmiorsrnfFZWpxXTDjBqM7X Hm8cMvDaTJcoV43sx4M+EO66D1oTAcwuT7k1XNSjum4WZyjSEUyrChwLjjpHJzAw rqVnlIljanX+E19D6P/oAv6G4aF+M7QrCyLALrJaa+703PtawmsBX0gRfAGHMRLi 0te/FPrvzvUSlccofl6a0UARG1hX0AP5vKK+wTjJUEiGfFpotB03vGNHwwTTG1Hw gZRkaRjI9LAy2oDlJtm1vuLg54V1fP30YDjNpjSLGaclFtpO0AlAqA43p9qQjX39 pQG5NR8W5KfGhOXVoCroenL7d3zK3WxjAciKm2HFz9d72TGKcPNoHmWMaARAC6E= =6yGZ -----END PGP SIGNATURE----- From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 01:31:45 2010 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 8D15F1065672 for ; Wed, 28 Jul 2010 01:31:45 +0000 (UTC) (envelope-from merlyn@stonehenge.com) Received: from red.stonehenge.com (red.stonehenge.com [IPv6:2607:f2f8:3080::]) by mx1.freebsd.org (Postfix) with ESMTP id 757D78FC0A for ; Wed, 28 Jul 2010 01:31:45 +0000 (UTC) Received: by red.stonehenge.com (Postfix, from userid 1001) id 1477E3BF0B; Tue, 27 Jul 2010 18:31:38 -0700 (PDT) From: merlyn@stonehenge.com (Randal L. Schwartz) To: Kristian =?utf-8?Q?Kr=C3=A6mmer?= Nielsen References: <4C4F86AD.9040703@com.jkkn.dk> x-mayan-date: Long count = 12.19.17.10.2; tzolkin = 10 Ik; haab = 15 Xul Date: Tue, 27 Jul 2010 18:31:37 -0700 In-Reply-To: <4C4F86AD.9040703@com.jkkn.dk> ("Kristian =?utf-8?Q?Kr=C3=A6m?= =?utf-8?Q?mer?= Nielsen"'s message of "Wed, 28 Jul 2010 03:23:57 +0200") Message-ID: <864ofk2xza.fsf@red.stonehenge.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: Time to upgrade the pf port in FreeBSD ? 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, 28 Jul 2010 01:31:45 -0000 >>>>> "Kristian" =3D=3D Kristian Kr=C3=A6mmer Nielsen = writes: Kristian> The later version of pf is easier to use. Indeed, but when I asked this a while back, one of the issues is that the new syntax is *not* upward compatible. Judging from the traffic on the openbsd list, this has caused a bunch of upgrade questions. This would have to be handled carefully with freebsd as well. --=20 Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 01:51:25 2010 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 812CD106564A for ; Wed, 28 Jul 2010 01:51:25 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [69.42.208.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6CB7F8FC13 for ; Wed, 28 Jul 2010 01:51:25 +0000 (UTC) Received: from [192.168.1.64] (99-118-214-35.lightspeed.irvnca.sbcglobal.net [99.118.214.35]) by sed.awknet.com (Postfix) with ESMTP id C9D481082462; Wed, 28 Jul 2010 01:51:24 +0000 (UTC) Message-ID: <4C4F8D19.2020609@sk1llz.net> Date: Tue, 27 Jul 2010 18:51:21 -0700 From: Justin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Daniel Hartmeier , freebsd-pf@freebsd.org References: <4C4D7EED.4060704@sk1llz.net> <20100727074850.GB1114@insomnia.benzedrine.cx> In-Reply-To: <20100727074850.GB1114@insomnia.benzedrine.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: pf synproxy 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, 28 Jul 2010 01:51:25 -0000 Hello Daniel, Didn't get any sort of information from pfctl -x misc. Here's the output from the commands you suggested; (3 SSH connections to run/log the tcpdump and pfctl outputs, 1 attempted proxy) Pre HTTP end host attempt; # pfctl -vvsi No ALTQ support in kernel ALTQ related functions disabled Status: Enabled for 0 days 00:01:21 Debug: Urgent Hostid: 0x144de36b Checksum: 0xda84c38c7e2412bb81511fe0620a1012 State Table Total Rate current entries 9 searches 407 5.0/s inserts 22 0.3/s removals 13 0.2/s Source Tracking Table current entries 0 searches 0 0.0/s inserts 0 0.0/s removals 0 0.0/s Counters match 26 0.3/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 0 0.0/s state-mismatch 0 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 14 0.2/s Limit Counters max states per rule 0 0.0/s max-src-states 0 0.0/s max-src-nodes 0 0.0/s max-src-conn 0 0.0/s max-src-conn-rate 0 0.0/s overload table insertion 0 0.0/s overload flush states 0 0.0/s after attempt and failure; # pfctl -vvsi No ALTQ support in kernel ALTQ related functions disabled Status: Enabled for 0 days 00:02:53 Debug: Urgent Hostid: 0x144de36b Checksum: 0xda84c38c7e2412bb81511fe0620a1012 State Table Total Rate current entries 5 searches 9552 55.2/s inserts 25 0.1/s removals 20 0.1/s Source Tracking Table current entries 0 searches 0 0.0/s inserts 0 0.0/s removals 0 0.0/s Counters match 35 0.2/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 0 0.0/s state-mismatch 0 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 3274 18.9/s Limit Counters max states per rule 0 0.0/s max-src-states 0 0.0/s max-src-nodes 0 0.0/s max-src-conn 0 0.0/s max-src-conn-rate 0 0.0/s overload table insertion 0 0.0/s overload flush states 0 0.0/s # pfctl -vvss No ALTQ support in kernel ALTQ related functions disabled all tcp FIREWALL_EXTERNAL_IP:22 <- REMOTE_VIEWING_HOST:53065 ESTABLISHED:ESTABLISHED [51278071 + 64060](+3232864399) [4177391361 + 65535](+803461391) age 00:02:49, expires in 04:59:45, 515:920 pkts, 28140:866768 bytes, rule 3 id: 4c4f86b600000031 creatorid: 144de36b all tcp FIREWALL_EXTERNAL_IP:22 <- REMOTE_VIEWING_HOST:53067 ESTABLISHED:ESTABLISHED [3663860670 + 63784](+2459193596) [1446109858 + 65535](+1445587765) age 00:02:19, expires in 04:59:45, 490:862 pkts, 27452:809608 bytes, rule 3 id: 4c4f86b60000003b creatorid: 144de36b all tcp FIREWALL_EXTERNAL_IP:22 <- REMOTE_VIEWING_HOST:53070 ESTABLISHED:ESTABLISHED [1850293048 + 63336](+3364896299) [442076181 + 65535](+2933418221) age 00:02:00, expires in 05:00:00, 84:108 pkts, 7728:17192 bytes, rule 3 id: 4c4f86b600000042 creatorid: 144de36b all tcp CLIENT_DESTINATION_IP:80 <- REMOTE_VIEWING_HOST:53075 PROXY:DST [0 + 3477913824] [3572604858 + 3688639377] age 00:00:26, expires in 00:00:04, 0:0 pkts, 0:0 bytes, rule 3 id: 4c4f86b600000048 creatorid: 144de36b tcpdump -nvSi [interface] tcp port 80 external interface: REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 01:39:14.466318 IP (tos 0x0, ttl 118, id 27612, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 01:39:14.467753 IP (tos 0x0, ttl 118, id 27613, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 01:39:14.468718 IP (tos 0x0, ttl 118, id 27614, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 01:39:14.469965 IP (tos 0x0, ttl 118, id 27615, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 01:39:14.470957 IP (tos 0x0, ttl 118, id 27616, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [R.], cksum 0xa088 (correct), seq 3572604859, ack 2966276940, win 0, length 0 internal interface: REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], length 0 01:39:14.467760 IP (tos 0x10, ttl 64, id 8944, offset 0, flags [DF], proto TCP (6), length 44) REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], length 0 01:39:14.468725 IP (tos 0x10, ttl 64, id 8945, offset 0, flags [DF], proto TCP (6), length 44) REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], length 0 01:39:14.469969 IP (tos 0x10, ttl 64, id 8946, offset 0, flags [DF], proto TCP (6), length 44) REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], length 0 01:39:14.470964 IP (tos 0x10, ttl 64, id 8947, offset 0, flags [DF], proto TCP (6), length 44) REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], length 0 01:39:34.524975 IP (tos 0x10, ttl 64, id 9091, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [R.], cksum 0xa089 (correct), seq 2966276939, ack 3572604859, win 0, length 0 On 7/27/2010 12:48 AM, Daniel Hartmeier wrote: > On Mon, Jul 26, 2010 at 05:26:21AM -0700, Justin wrote: > > >> When using synproxy state - the connection never completes. If we change >> synproxy to keep, everything works fine. Alternately, if the service in >> question is running locally on the actual firewall itself, I'll see >> state entries show up in pfctl -s doing a proxy and then passing the >> connection on to its self - so why doesn't it work in the same manner >> when passing on to a host behind the machine? I've tried all sorts of >> variations and skipping processing on internal interface, but I just >> can't seem to get it to work. All my searching has turned up nothing. >> I've also tried state-policy if-bound and there appears to be no change. >> Is this a bug? Have I missed something totally obvious? >> > Concurrently run > > # tcpdump -nvSi em0 tcp port 80 > > and > > # tcpdump -nvSi em1 tcp port 80 > > and reproduce one connection failure. What do you see? > Does the TCP handshake (SYN, SYN+ACK, ACK) complete between > client and pf? And the one between pf and the server? > > Right after the failure, does pfctl -vvss show a state entry > for the failed connection? What does it look like? > > Run pfctl -vvsi before and after the failure. Which counters > are increasing? > > Enable verbose logging (pfctl -x misc), does /var/log/messages > show any message possibly related to the failure? > > Kind regards, > Daniel > From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 02:25:00 2010 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 D3863106566C for ; Wed, 28 Jul 2010 02:25:00 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [69.42.208.18]) by mx1.freebsd.org (Postfix) with ESMTP id BE23A8FC1A for ; Wed, 28 Jul 2010 02:25:00 +0000 (UTC) Received: from [192.168.1.64] (99-118-214-35.lightspeed.irvnca.sbcglobal.net [99.118.214.35]) by sed.awknet.com (Postfix) with ESMTP id 59D5B107D9B1; Wed, 28 Jul 2010 02:25:00 +0000 (UTC) Message-ID: <4C4F94F8.5050709@sk1llz.net> Date: Tue, 27 Jul 2010 19:24:56 -0700 From: Justin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Daniel Hartmeier , freebsd-pf@freebsd.org References: <4C4D7EED.4060704@sk1llz.net> <20100727074850.GB1114@insomnia.benzedrine.cx> <4C4F8D19.2020609@sk1llz.net> In-Reply-To: <4C4F8D19.2020609@sk1llz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: pf synproxy 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, 28 Jul 2010 02:25:00 -0000 - tcpdumps showing the initial connect attempt (logs below were furhter along the process); external: 02:21:25.595977 IP (tos 0x0, ttl 118, id 10020, offset 0, flags [DF], proto TCP (6), length 52) REMOTE_VIEWING_HOST.53782 > CLIENT_DESTINATION_IP.80: Flags [S], cksum 0x537b (correct), se q 2569879850, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 02:21:25.596000 IP (tos 0x10, ttl 64, id 27957, offset 0, flags [DF], proto TCP (6), length 44) CLIENT_DESTINATION_IP.80 > REMOTE_VIEWING_HOST.53782: Flags [S.], cksum 0x7920 (correct), s eq 3819585455, ack 2569879851, win 0, options [mss 1460], length 0 02:21:25.605825 IP (tos 0x0, ttl 118, id 10021, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_VIEWING_HOST.53782 > CLIENT_DESTINATION_IP.80: Flags [.], cksum 0x95ec (correct), ac k 3819585456, win 64240, length 0 02:21:25.615953 IP (tos 0x0, ttl 118, id 10022, offset 0, flags [DF], proto TCP (6), length 40) internal: 02:22:34.717332 IP (tos 0x0, ttl 118, id 22015, offset 0, flags [DF], proto TCP (6), length 52) REMOTE_VIEWING_HOST.53786 > CLIENT_DESTINATION_IP.80: Flags [S], cksum 0x84ee (correct), se q 1816476827, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 02:22:34.717354 IP (tos 0x10, ttl 64, id 39898, offset 0, flags [DF], proto TCP (6), length 44) CLIENT_DESTINATION_IP.80 > REMOTE_VIEWING_HOST.53786: Flags [S.], cksum 0x1d5d (correct), s eq 76721150, ack 1816476828, win 0, options [mss 1460], length 0 02:22:34.728880 IP (tos 0x0, ttl 118, id 22016, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_VIEWING_HOST.53786 > CLIENT_DESTINATION_IP.80: Flags [.], cksum 0x3a29 (correct), ac k 76721151, win 64240, length 0 02:22:34.742691 IP (tos 0x0, ttl 118, id 22017, offset 0, flags [DF], proto TCP (6), length 40) On 7/27/2010 6:51 PM, Justin wrote: > Hello Daniel, > > Didn't get any sort of information from pfctl -x misc. Here's the > output from the commands you suggested; > > (3 SSH connections to run/log the tcpdump and pfctl outputs, 1 > attempted proxy) > > Pre HTTP end host attempt; > > # pfctl -vvsi > No ALTQ support in kernel > ALTQ related functions disabled > Status: Enabled for 0 days 00:01:21 Debug: Urgent > > Hostid: 0x144de36b > Checksum: 0xda84c38c7e2412bb81511fe0620a1012 > > State Table Total Rate > current entries 9 > searches 407 5.0/s > inserts 22 0.3/s > removals 13 0.2/s > Source Tracking Table > current entries 0 > searches 0 0.0/s > inserts 0 0.0/s > removals 0 0.0/s > Counters > match 26 0.3/s > bad-offset 0 0.0/s > fragment 0 0.0/s > short 0 0.0/s > normalize 0 0.0/s > memory 0 0.0/s > bad-timestamp 0 0.0/s > congestion 0 0.0/s > ip-option 0 0.0/s > proto-cksum 0 0.0/s > state-mismatch 0 0.0/s > state-insert 0 0.0/s > state-limit 0 0.0/s > src-limit 0 0.0/s > synproxy 14 0.2/s > Limit Counters > max states per rule 0 0.0/s > max-src-states 0 0.0/s > max-src-nodes 0 0.0/s > max-src-conn 0 0.0/s > max-src-conn-rate 0 0.0/s > overload table insertion 0 0.0/s > overload flush states 0 0.0/s > > > after attempt and failure; > > # pfctl -vvsi > No ALTQ support in kernel > ALTQ related functions disabled > Status: Enabled for 0 days 00:02:53 Debug: Urgent > > Hostid: 0x144de36b > Checksum: 0xda84c38c7e2412bb81511fe0620a1012 > > State Table Total Rate > current entries 5 > searches 9552 55.2/s > inserts 25 0.1/s > removals 20 0.1/s > Source Tracking Table > current entries 0 > searches 0 0.0/s > inserts 0 0.0/s > removals 0 0.0/s > Counters > match 35 0.2/s > bad-offset 0 0.0/s > fragment 0 0.0/s > short 0 0.0/s > normalize 0 0.0/s > memory 0 0.0/s > bad-timestamp 0 0.0/s > congestion 0 0.0/s > ip-option 0 0.0/s > proto-cksum 0 0.0/s > state-mismatch 0 0.0/s > state-insert 0 0.0/s > state-limit 0 0.0/s > src-limit 0 0.0/s > synproxy 3274 18.9/s > Limit Counters > max states per rule 0 0.0/s > max-src-states 0 0.0/s > max-src-nodes 0 0.0/s > max-src-conn 0 0.0/s > max-src-conn-rate 0 0.0/s > overload table insertion 0 0.0/s > overload flush states 0 0.0/s > > > > # pfctl -vvss > No ALTQ support in kernel > ALTQ related functions disabled > all tcp FIREWALL_EXTERNAL_IP:22 <- REMOTE_VIEWING_HOST:53065 > ESTABLISHED:ESTABLISHED > [51278071 + 64060](+3232864399) [4177391361 + 65535](+803461391) > age 00:02:49, expires in 04:59:45, 515:920 pkts, 28140:866768 > bytes, rule 3 > id: 4c4f86b600000031 creatorid: 144de36b > all tcp FIREWALL_EXTERNAL_IP:22 <- REMOTE_VIEWING_HOST:53067 > ESTABLISHED:ESTABLISHED > [3663860670 + 63784](+2459193596) [1446109858 + 65535](+1445587765) > age 00:02:19, expires in 04:59:45, 490:862 pkts, 27452:809608 > bytes, rule 3 > id: 4c4f86b60000003b creatorid: 144de36b > all tcp FIREWALL_EXTERNAL_IP:22 <- REMOTE_VIEWING_HOST:53070 > ESTABLISHED:ESTABLISHED > [1850293048 + 63336](+3364896299) [442076181 + 65535](+2933418221) > age 00:02:00, expires in 05:00:00, 84:108 pkts, 7728:17192 bytes, > rule 3 > id: 4c4f86b600000042 creatorid: 144de36b > all tcp CLIENT_DESTINATION_IP:80 <- REMOTE_VIEWING_HOST:53075 > PROXY:DST > [0 + 3477913824] [3572604858 + 3688639377] > age 00:00:26, expires in 00:00:04, 0:0 pkts, 0:0 bytes, rule 3 > id: 4c4f86b600000048 creatorid: 144de36b > > > tcpdump -nvSi [interface] tcp port 80 > > external interface: > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], > cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 > 01:39:14.466318 IP (tos 0x0, ttl 118, id 27612, offset 0, flags [DF], > proto TCP (6), length 40) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], > cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 > 01:39:14.467753 IP (tos 0x0, ttl 118, id 27613, offset 0, flags [DF], > proto TCP (6), length 40) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], > cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 > 01:39:14.468718 IP (tos 0x0, ttl 118, id 27614, offset 0, flags [DF], > proto TCP (6), length 40) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], > cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 > 01:39:14.469965 IP (tos 0x0, ttl 118, id 27615, offset 0, flags [DF], > proto TCP (6), length 40) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.], > cksum 0xa59b (correct), ack 2966276940, win 64240, length 0 > 01:39:14.470957 IP (tos 0x0, ttl 118, id 27616, offset 0, flags [DF], > proto TCP (6), length 40) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [R.], > cksum 0xa088 (correct), seq 3572604859, ack 2966276940, win 0, length 0 > > internal interface: > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], > cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], > length 0 > 01:39:14.467760 IP (tos 0x10, ttl 64, id 8944, offset 0, flags [DF], > proto TCP (6), length 44) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], > cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], > length 0 > 01:39:14.468725 IP (tos 0x10, ttl 64, id 8945, offset 0, flags [DF], > proto TCP (6), length 44) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], > cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], > length 0 > 01:39:14.469969 IP (tos 0x10, ttl 64, id 8946, offset 0, flags [DF], > proto TCP (6), length 44) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], > cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], > length 0 > 01:39:14.470964 IP (tos 0x10, ttl 64, id 8947, offset 0, flags [DF], > proto TCP (6), length 44) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S], > cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460], > length 0 > 01:39:34.524975 IP (tos 0x10, ttl 64, id 9091, offset 0, flags [DF], > proto TCP (6), length 40) > REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [R.], > cksum 0xa089 (correct), seq 2966276939, ack 3572604859, win 0, length 0 > > > > On 7/27/2010 12:48 AM, Daniel Hartmeier wrote: >> On Mon, Jul 26, 2010 at 05:26:21AM -0700, Justin wrote: >> >>> When using synproxy state - the connection never completes. If we >>> change >>> synproxy to keep, everything works fine. Alternately, if the service in >>> question is running locally on the actual firewall itself, I'll see >>> state entries show up in pfctl -s doing a proxy and then passing the >>> connection on to its self - so why doesn't it work in the same manner >>> when passing on to a host behind the machine? I've tried all sorts of >>> variations and skipping processing on internal interface, but I just >>> can't seem to get it to work. All my searching has turned up nothing. >>> I've also tried state-policy if-bound and there appears to be no >>> change. >>> Is this a bug? Have I missed something totally obvious? >> Concurrently run >> >> # tcpdump -nvSi em0 tcp port 80 >> >> and >> >> # tcpdump -nvSi em1 tcp port 80 >> >> and reproduce one connection failure. What do you see? >> Does the TCP handshake (SYN, SYN+ACK, ACK) complete between >> client and pf? And the one between pf and the server? >> >> Right after the failure, does pfctl -vvss show a state entry >> for the failed connection? What does it look like? >> >> Run pfctl -vvsi before and after the failure. Which counters >> are increasing? >> >> Enable verbose logging (pfctl -x misc), does /var/log/messages >> show any message possibly related to the failure? >> >> Kind regards, >> Daniel > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 03:08:54 2010 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 41BB11065674 for ; Wed, 28 Jul 2010 03:08:54 +0000 (UTC) (envelope-from labstaff@cs.rpi.edu) Received: from cliffclavin.cs.rpi.edu (cliffclavin.cs.rpi.edu [128.113.126.25]) by mx1.freebsd.org (Postfix) with ESMTP id 767A18FC1C for ; Wed, 28 Jul 2010 03:08:53 +0000 (UTC) X-Hash: S|53bfbb19e7815ed4dd3a35b97805228c1861b2ca|4dfb5885221c9d3272224b901c3335e3 X-Countries: United States X-SMTP-From: accepted localhost [127.0.0.1] (localhost.localdomain) X-Spam-Report: Spam Report from cliffclavin.cs.rpi.edu (SA:3.2.5): -0.2 SPF_PASS SPF: sender matches SPF record -0.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 SARE_URI_CONS7 body contains link to probable spammer 0.1 BOUNCE_MESSAGE MTA bounce message 0.1 ANY_BOUNCE_MESSAGE Message is some kind of bounce message -0.1 AWL AWL: From: address is in the auto white-list X-Spam-Info: -0.7, local; ANY_BOUNCE_MESSAGE,AWL,BAYES_00,BOUNCE_MESSAGE,SARE_URI_CONS7, SPF_PASS X-Spam-Scanned-By: cliffclavin.cs.rpi.edu using SpamAssassin 3.2.5 X-Virus-Scanned-By: cliffclavin.cs.rpi.edu Received: from localhost.localdomain (mailnull@localhost [127.0.0.1]) by cliffclavin.cs.rpi.edu (8.14.3/8.14.3) with ESMTP id o6S2bKQs076434 for ; Tue, 27 Jul 2010 22:37:20 -0400 (EDT) (envelope-from labstaff@cs.rpi.edu) Received: from newman.cs.rpi.edu (root@newman.cs.rpi.edu [128.113.126.12]) by cliffclavin.cs.rpi.edu (8.14.3/8.14.3) with ESMTP id o6S2Ztqv076405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Jul 2010 22:35:55 -0400 (EDT) (envelope-from darmiwati55@gmail.com) Received: from mail-iw0-f177.google.com (mail-iw0-f177.google.com [209.85.214.177]) by newman.cs.rpi.edu (8.14.3/8.14.3) with ESMTP id o6S2Zpfh079651 for ; Tue, 27 Jul 2010 22:35:53 -0400 (EDT) (envelope-from darmiwati55@gmail.com) Received: by iwn40 with SMTP id 40so5050600iwn.36 for ; Tue, 27 Jul 2010 19:35:50 -0700 (PDT) Received: by 10.231.146.129 with SMTP id h1mr11179047ibv.181.1280284547558; Tue, 27 Jul 2010 19:35:47 -0700 (PDT) Received: by 10.231.111.154 with HTTP; Tue, 27 Jul 2010 19:35:47 -0700 (PDT) X-Scanned-By: MIMEDefang 2.67 on 128.113.126.25 X-Scanned-BY: MIMEDefang 2.67 on 128.113.126.25 X-Scanned-BY: MIMEDefang 2.67 on 128.113.126.12 X-Countries: United States X-Countries: United States X-NATS-EnvFrom: darmiwati55@gmail.com Tue Jul 27 22:36:36 2010 In-Reply-To: X-Hash: SCt|f48fdc3a3d3b7e2c9f792d88527d00373630bbf0|9e5bb6e65201c769d6c3cea3f4e76310 X-Hash: SCt|f48fdc3a3d3b7e2c9f792d88527d00373630bbf0|9e5bb6e65201c769d6c3cea3f4e76310 References: Message-ID: X-Auth-Passed: newman.cs.rpi.edu:o6S2Zpfh079651 DomainKeys:darmiwati55@gmail.com DKIM:darmiwati55@gmail.com SPF:darmiwati55@gmail.com X-Spam-Score: 0.3 () BAYES_00, DKIM_SIGNED, DKIM_VERIFIED, DK_SIGNED, HTML_IMAGE_ONLY_28, HTML_MESSAGE, SPF_PASS X-Spam-Info: 0.3; BAYES_00,DKIM_SIGNED,DKIM_VERIFIED,DK_SIGNED,HTML_IMAGE_ONLY_28, HTML_MESSAGE,SPF_PASS X-NATS-Orig-Authentication-Results: newman.cs.rpi.edu; DomainKeys=pass (pass) header.sender=darmiwati55@gmail.com; DKIM=pass (pass) header.from=darmiwati55@gmail.com; SPF=pass (mfrom; Mechanism 'ip4:209.85.128.0/17' matched) smtp.mail=darmiwati55@gmail.com X-Virus-Scanned-BY: cliffclavin.cs.rpi.edu X-Virus-Scanned-BY: newman.cs.rpi.edu X-Spam-Report: Spam Report from newman.cs.rpi.edu (SA:3.2.5): -0.2 SPF_PASS SPF: sender matches SPF record 0.0 DK_SIGNED Domain Keys: message has a signature -0.2 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.0 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 1.6 HTML_IMAGE_ONLY_28 BODY: HTML: images with 2400-2800 bytes of words 0.0 HTML_MESSAGE BODY: HTML included in message -0.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] X-NATS-Orig-Domainkey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=IBVwWqhMjrOnKEIkvmGxPojySAukVdaIp9O8ami0ydj1sQQIe26x0mZdA9ChN1dWcq weLjlxYNkmWGzAeLO3BApptCgzYGJ+Ky8pFolpAuXuiJaMD5JymyvFr5wy7RQbn6ace+ lm3zKM0GeNx2ty/42CH6uvLIUrEtO5J0wp/Nk= X-NATS-Orig-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=KpNkR3KL67XVR/HWgOFv6AZRSc2AE6gE4/D50kzO9Y8=; b=OPE3DMlTMZPndGV8+bytMmwVk0ttWIy80DGXrjCq6gSeoCIk63YUBTVXmHPWNuEf6g oY1zOSXY7yiw1ppJIEnqmCXAFwfid6jUjixVTKupt9vBPHKAGNUc0YJ0M4DSbo6k1pLP nZtuaQAvPvAcpeEiW0a7O1ZlTci1/z8sN3t5Q= X-NATS-Orig-Date: Wed, 28 Jul 2010 10:35:47 +0800 X-Spam-Scanned-BY: newman.cs.rpi.edu using SpamAssassin 3.2.5 (hard limit 15) X-SMTP-From: passed newman.cs.rpi.edu [128.113.126.12] (newman.cs.rpi.edu) {United States} X-SMTP-From: accepted mail-iw0-f177.google.com [209.85.214.177] (mail-iw0-f177.google.com) {United States} X-NATS-Orig-To: lettings.knutsford@mellerbraggins.com, spam@nopdesign.com, stoertebecker@uni-bremen.de, jranke@uni-bremen.de, koenig@chemie.uni-regensburg.de, linkyorganics@gmail.com, freebsd-pf@freebsd.org, enquiries@nasaa.com.au, orchidgarden@pldtdsl.net, labstaff@cs.rpi.edu, newspirit4u@verizon.net, 1460@gmail.com, ecocert@sancharnet.in, info@onecertasia.in, pipsales@nedbank.co.za, baldwidl@mda.state.md.us, contact@somohuile.com.tn, dcrabtree@mt.gov, php@rose.net, kurrimeats@bigpond.com, globalorganicalliance@hughes.net, ronpurcell1@hotmail.com, jhansi71315@rediffmail.com, offthewall31@yahoo.co.uk, alan-panther@stoxphotos.freeserve.co.uk, sipp-users@lists.sourceforge.net, shehzad.zia@lums.edu.pk, sales@organicvegetablesuppliers.com, me@myPLEASENOSPAM.org, kankyo@ai.u-hyogo.ac.jp, Larryozanne@rcn.com, rodrigo.allnat@hotmail.com, somana1993@gmail.com X-NATS-From: darmiwati sahril Auto-Submitted: auto-replied Date: Tue, 27 Jul 2010 22:37:15 -0400 (EDT) Auto-Submitted: auto-replied X-Mailer: NATS v2.0 From: NATS X-NATS-Ticket: 25688 X-NATS-Priority: 5 X-NATS-State: open X-NATS-Generated: cliffclavin.cs.rpi.edu Errors-to: labstaff-real@cs.rpi.edu Sender: labstaff-real@cs.rpi.edu To: freebsd-pf@freebsd.org Subject: [TICKET #25688] Fwd: peluang bisnes online!!! X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: labstaff@cs.rpi.edu 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, 28 Jul 2010 03:08:54 -0000 Thank you, Your problem report has been accepted into the Department of Computer Science automated ticketing system. Please note: * You can check the status of your tickets at this URL: https://cgi.cs.rpi.edu/nats/ * Your ticket number is included in the subject of this email. Please reference this number in all future correspondence regarding this issue (one way to do this is to reply to this message) If this is an emergency situation, please open a NEW ticket, by sending a NEW email, without a ticket number, with the word "EMERGENCY" in the subject line. this will immediately alert labstaff, who will contact you shortly. (An emergency is only when a serious problem affects multiple computers or users) If you require our help to meet an urgent deadline, you may mention this by replying to this message. We will accommodate your request to the best of our abilities. Your original report is included below for reference. -------------- Problem Report ------------------- From: darmiwati55@gmail.com, 2010-07-27 22:37:14.176938 KLIK DI SINI --- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html (discarded) --- From: darmiwati55@gmail.com, 2010-07-27 22:37:14.192464 ** Added copy email address lettings.knutsford@mellerbraggins.com ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.208829 ** Added copy email address spam@nopdesign.com ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.227318 ** Added copy email address stoertebecker@uni-bremen.de ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.250553 ** Added copy email address jranke@uni-bremen.de ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.267293 ** Added copy email address koenig@chemie.uni-regensburg.de ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.288779 ** Added copy email address linkyorganics@gmail.com ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.311266 ** Added copy email address freebsd-pf@freebsd.org ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.327629 ** Added copy email address enquiries@nasaa.com.au ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.340496 ** Added copy email address orchidgarden@pldtdsl.net ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.355611 ** Added copy email address newspirit4u@verizon.net ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.365106 ** Added copy email address 1460@gmail.com ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.375724 ** Added copy email address ecocert@sancharnet.in ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.394587 ** Added copy email address info@onecertasia.in ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.413451 ** Added copy email address pipsales@nedbank.co.za ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.42382 ** Added copy email address baldwidl@mda.state.md.us ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.442557 ** Added copy email address contact@somohuile.com.tn ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.453301 ** Added copy email address dcrabtree@mt.gov ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.474288 ** Added copy email address php@rose.net ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.489404 ** Added copy email address kurrimeats@bigpond.com ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.504395 ** Added copy email address globalorganicalliance@hughes.net ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.514513 ** Added copy email address ronpurcell1@hotmail.com ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.538623 ** Added copy email address jhansi71315@rediffmail.com ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.549492 ** Added copy email address offthewall31@yahoo.co.uk ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.56748 ** Added copy email address alan-panther@stoxphotos.freeserve.co.uk ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.58547 ** Added copy email address sipp-users@lists.sourceforge.net ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.603583 ** Added copy email address shehzad.zia@lums.edu.pk ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.620448 ** Added copy email address sales@organicvegetablesuppliers.com ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.628693 ** Added copy email address me@myPLEASENOSPAM.org ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.639436 ** Added copy email address kankyo@ai.u-hyogo.ac.jp ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.663421 ** Added copy email address Larryozanne@rcn.com ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.687531 ** Added copy email address rodrigo.allnat@hotmail.com ** From: darmiwati55@gmail.com, 2010-07-27 22:37:14.70552 ** Added copy email address somana1993@gmail.com ** - labstaff@cs.rpi.edu From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 06:40:06 2010 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 7F1241065676 for ; Wed, 28 Jul 2010 06:40:06 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 37FD78FC12 for ; Wed, 28 Jul 2010 06:40:06 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id CD6A237277; Wed, 28 Jul 2010 08:23:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id dhLYy6fndQ4v; Wed, 28 Jul 2010 08:23:31 +0200 (CEST) Received: from danger-mbp.local (bband-dyn162.95-103-232.t-com.sk [95.103.232.162]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id C9ED737258; Wed, 28 Jul 2010 08:23:31 +0200 (CEST) Message-ID: <4C4FCCE3.7000603@FreeBSD.org> Date: Wed, 28 Jul 2010 08:23:31 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9pre) Gecko/20100727 Lanikai/3.1.2pre MIME-Version: 1.0 To: freebsd-pf@freebsd.org, =?ISO-8859-1?Q?Ermal_Lu=E7i?= References: <4C4F86AD.9040703@com.jkkn.dk> <4C4F87A4.9020601@delphij.net> In-Reply-To: <4C4F87A4.9020601@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: Time to upgrade the pf port in FreeBSD ? 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, 28 Jul 2010 06:40:06 -0000 On 28.7.2010 3:28, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 2010/07/27 18:23, Kristian Kræmmer Nielsen wrote: >> Hey, >> >> As of time being, we still include pf as of OpenBSD 4.1 (released May >> 2007). >> >> So I was wondering, how many is actually using pf and is it time to get >> together and update the current port of pf included in FreeBSD to a more >> recent version?, e.x. the version from OpenBSD 4.7? >> >> Has anyone considered this? / is anyone interested in doing this? > > IIRC someone have work in progress in a svn branch but I'm not sure if > it's HEAD-ready or not... It is Ermal Luci (eri@) who is working on it. Unfortunately, I couldn't get any update for this project from him for the latest status report, however 6 months ago he submitted this: http://www.freebsd.org/news/status/report-2009-10-2009-12.html#Syncing-pf%284%29-with-OpenBSD-4.5 -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 07:06:25 2010 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 65CEC106564A for ; Wed, 28 Jul 2010 07:06:25 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id D915B8FC13 for ; Wed, 28 Jul 2010 07:06:23 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id o6S76LQu014258 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 28 Jul 2010 09:06:21 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id o6S76LiO024394; Wed, 28 Jul 2010 09:06:21 +0200 (MEST) Date: Wed, 28 Jul 2010 09:06:21 +0200 From: Daniel Hartmeier To: Justin Message-ID: <20100728070621.GA11444@insomnia.benzedrine.cx> References: <4C4D7EED.4060704@sk1llz.net> <20100727074850.GB1114@insomnia.benzedrine.cx> <4C4F8D19.2020609@sk1llz.net> <4C4F94F8.5050709@sk1llz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C4F94F8.5050709@sk1llz.net> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-pf@freebsd.org Subject: Re: pf synproxy 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, 28 Jul 2010 07:06:25 -0000 On Tue, Jul 27, 2010 at 07:24:56PM -0700, Justin wrote: > - tcpdumps showing the initial connect attempt (logs below were > furhter along the process); > > external: > 02:21:25.595977 IP (tos 0x0, ttl 118, id 10020, offset 0, flags [DF], > proto TCP > (6), length 52) > REMOTE_VIEWING_HOST.53782 > CLIENT_DESTINATION_IP.80: Flags [S], > cksum 0x537b (correct), se > q 2569879850, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], > length 0 > 02:21:25.596000 IP (tos 0x10, ttl 64, id 27957, offset 0, flags [DF], > proto TCP > (6), length 44) > CLIENT_DESTINATION_IP.80 > REMOTE_VIEWING_HOST.53782: Flags [S.], > cksum 0x7920 (correct), s > eq 3819585455, ack 2569879851, win 0, options [mss 1460], length 0 > 02:21:25.605825 IP (tos 0x0, ttl 118, id 10021, offset 0, flags [DF], > proto TCP > (6), length 40) > REMOTE_VIEWING_HOST.53782 > CLIENT_DESTINATION_IP.80: Flags [.], > cksum 0x95ec (correct), ac > k 3819585456, win 64240, length 0 > 02:21:25.615953 IP (tos 0x0, ttl 118, id 10022, offset 0, flags [DF], > proto TCP > (6), length 40) The TCP handshake with the client makes sense. The client's SYN offers wscale and sack, pf's SYN+ACK has IP tos 0x10 and neither wscale nor sack, and win 0. > internal: > 02:22:34.717332 IP (tos 0x0, ttl 118, id 22015, offset 0, flags [DF], > proto TCP > (6), length 52) > REMOTE_VIEWING_HOST.53786 > CLIENT_DESTINATION_IP.80: Flags [S], > cksum 0x84ee (correct), se > q 1816476827, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], > length 0 This doesn't seem to be captured on the internal interface, at least it is not the server handshake replayed by pf's synproxy. Note the (random) client source port 53786 doesn't match 53782 of the external capture above. Instead, it looks like ANOTHER connection captured on the external interface. The SYN has IP tos 0x0 and offers wscale and sack, so this CANNOT be a packet generated by pf's synproxy... What we want to see is the two TCP handshakes related to the same client connection, once on the interface towards the client, once on the interface towards the server. The client source port is the same. Ideally, tcpdump on both interface, writing to two files with tcpdump -w. Reproduce the issue. Find out what client source port was used for that connection. Then tcpdump -r and extract all packets of that port (src or dst) in both files... And the pfctl -vvss output should contain the state with that port as well. There is precisely one external and one internal interface, and pf is the only connection between these two networks, right? If the client's SYN can somehow reach the server bypassing pf, the synproxy will not work, there'd be two handshakes to the server using different sequence numbers, the server would accept the first, ignore the other, confusion would ensue ;) Daniel From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 08:43:23 2010 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 5F8D61065676 for ; Wed, 28 Jul 2010 08:43:23 +0000 (UTC) (envelope-from dennylin93@hs.ntnu.edu.tw) Received: from mail.hs.ntnu.edu.tw (mail.hs.ntnu.edu.tw [140.131.149.3]) by mx1.freebsd.org (Postfix) with ESMTP id CA6DF8FC21 for ; Wed, 28 Jul 2010 08:43:21 +0000 (UTC) Received: by mail.hs.ntnu.edu.tw (Postfix, from userid 1001) id C7DA64B781B; Wed, 28 Jul 2010 16:43:20 +0800 (CST) Date: Wed, 28 Jul 2010 16:43:20 +0800 From: Denny Lin To: Kristian =?utf-8?Q?Kr=C3=A6mmer?= Nielsen Message-ID: <20100728084320.GA9685@mail.hs.ntnu.edu.tw> References: <4C4F86AD.9040703@com.jkkn.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C4F86AD.9040703@com.jkkn.dk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-pf@freebsd.org Subject: Re: Time to upgrade the pf port in FreeBSD ? 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, 28 Jul 2010 08:43:23 -0000 On Wed, Jul 28, 2010 at 03:23:57AM +0200, Kristian Kræmmer Nielsen wrote: > As of time being, we still include pf as of OpenBSD 4.1 (released May 2007). > > Recently syntax has changed a lot in the releases of pf in OpenBSD 4.7, > just notice that "nat-to" and "rtr-to" are now part of the > pass-commands. This means also means that refereeing to the OpenBSD FAQ > from the FreeBSD manual is close to useless. I have not be able to find > a online copy of the FAQ for PF from OpenBSD 4.1, so simply changing the > documentation link is not an easy option. It can be found here: ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq41.pdf -- Denny Lin From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 19:06:28 2010 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 E4B151065679 for ; Wed, 28 Jul 2010 19:06:28 +0000 (UTC) (envelope-from Aleksej.Spenst@harman.com) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by mx1.freebsd.org (Postfix) with SMTP id 3AC858FC18 for ; Wed, 28 Jul 2010 19:06:27 +0000 (UTC) Received: from source ([194.121.90.173]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKTFB/s1TRBRu2ldLGIWzcOaVyWMmq5IOT@postini.com; Wed, 28 Jul 2010 12:06:28 PDT Received: from HIKAWSEX01.ad.harman.com ([fe80::f023:31d4:f809:b22e]) by HIKAWSEX02.ad.harman.com ([172.16.1.216]) with mapi; Wed, 28 Jul 2010 20:55:32 +0200 From: "Spenst, Aleksej" To: "freebsd-pf@freebsd.org" Date: Wed, 28 Jul 2010 20:55:31 +0200 Thread-Topic: For better security: always "block all" or "block in all" is enough? Thread-Index: AcsuhnPxDAhf7j3xSK6TAzUseHLnBQ== Message-ID: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: For better security: always "block all" or "block in all" is enough? 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, 28 Jul 2010 19:06:29 -0000 Hi All, I have to provide for my system better security and I guess it would be bet= ter to start pf.conf with the "block all" rule opening afterwards only thos= e incoming and outcoming ports that are supposed to be used by the system o= n external interfaces. However, it would be easier for me to write all pf r= ules if I start pf.conf with "block in all", i.e. if I block only traffic c= oming in from the outside and open all ports for outgoing traffic. - Incoming ports: only udp/68 (for dhcp client) and http/80 (for http serve= r) always open; - Outgoing ports: all ports always opened. All traffic going outside from t= he system has "keep state"; What disadvantages does it have in term of security in comparison with "blo= ck all"? In other words, how bad it is to have all outgoing ports always op= ened and whether someone can use this to hack the sysem? Thanks a lot for any tips!! Aleksej. From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 19:29:40 2010 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 7AA96106566B for ; Wed, 28 Jul 2010 19:29:40 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 38EDD8FC0A for ; Wed, 28 Jul 2010 19:29:39 +0000 (UTC) Received: by qwk3 with SMTP id 3so1311422qwk.13 for ; Wed, 28 Jul 2010 12:29:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.37.19 with SMTP id v19mr9227081qad.65.1280345378860; Wed, 28 Jul 2010 12:29:38 -0700 (PDT) Received: by 10.229.230.14 with HTTP; Wed, 28 Jul 2010 12:29:38 -0700 (PDT) In-Reply-To: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> References: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> Date: Wed, 28 Jul 2010 15:29:38 -0400 Message-ID: From: Michael Proto To: "Spenst, Aleksej" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-pf@freebsd.org" Subject: Re: For better security: always "block all" or "block in all" is enough? 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, 28 Jul 2010 19:29:40 -0000 On Wed, Jul 28, 2010 at 2:55 PM, Spenst, Aleksej wrote: > Hi All, > > I have to provide for my system better security and I guess it would be b= etter to start pf.conf with the "block all" rule opening afterwards only th= ose incoming and outcoming ports that are supposed to be used by the system= on external interfaces. However, it would be easier for me to write all pf= rules if I start pf.conf with "block in all", i.e. if I block only traffic= coming in from the outside and open all ports for outgoing traffic. > > - Incoming ports: only udp/68 (for dhcp client) and http/80 (for http ser= ver) always open; > - Outgoing ports: all ports always opened. All traffic going outside from= the system has "keep state"; > > What disadvantages does it have in term of security in comparison with "b= lock all"? In other words, how bad it is to have all outgoing ports always = opened and whether someone can use this to hack the sysem? > > Thanks a lot for any tips!! > Aleksej. > Outgoing ports aren't really used as an attack on that system, but as a jump-point to other systems. Say server A allows all outbound traffic. Server B, with sensitive data on it, blocks all inbound access from the Internet but does allow connections from the network where server A is located. Someone hacks server A, and now they have a route to attack server B they didn't have before. Ideally, limiting outgoing traffic to only intended hosts and/or ports is preferred from a security perspective, but you also have to frame it in the context of what the system will be doing. If you have a good knowledge of what the system needs for both inbound and outbound connectivity, it would probably be a good idea to restrict access both ways. I say probably because if the system's outbound traffic profile is intended to change, requiring changes to the firewall ruleset on a regular basis, it wouldn't make much sense. If you know there's outbound traffic you definitely don't need, blocking it isn't a bad idea. For a system with only public IP addresses, denying traffic to RFC1918 space is a good example. -Proto From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 19:30:02 2010 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 B4ECB1065675 for ; Wed, 28 Jul 2010 19:30:02 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 653028FC0C for ; Wed, 28 Jul 2010 19:30:02 +0000 (UTC) Received: from iad-wprd-xchw02.corp.verio.net (iad-wprd-xchw02.corp.verio.net [198.87.7.165]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id 2316BB0380D6 for ; Wed, 28 Jul 2010 15:30:01 -0400 (EDT) Thread-Index: AcsuiuJJVXUSBPGLQ9eik0HfQVaALw== Received: from dllstx1-8sst9f1.corp.verio.net ([10.144.2.52]) by iad-wprd-xchw02.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 15:27:13 -0400 Received: by dllstx1-8sst9f1.corp.verio.net (sSMTP sendmail emulation); Wed, 28 Jul 2010 14:27:13 -0500 Content-Transfer-Encoding: 7bit Date: Wed, 28 Jul 2010 14:27:13 -0500 From: "David DeSimone" To: Content-class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 Message-ID: <20100728192712.GW1280@verio.net> Mail-Followup-To: freebsd-pf@freebsd.org References: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> Precedence: bulk User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 28 Jul 2010 19:27:13.0639 (UTC) FILETIME=[E1A73F70:01CB2E8A] Subject: Re: For better security: always "block all" or "block in all" is enough? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jul 2010 19:30:02 -0000 It's all about layers of defense, and whether the reduced convenience is worthwhile. Limiting outbound traffic from your system is a hassle, but I like to think about this scenario: Suppose an attacker did manage to find an exploitable method on your system, and was able to open up a shell. What would they try to do? I think a common next step is for the attacker to download his "bag of tools" onto the system and to try to exploit further, or make himself at home. If your outbound policy blocks him from being able to download his rootkit or exploit tools, you may very well stop him from getting any further into your system. Spenst, Aleksej wrote: > > I have to provide for my system better security and I guess it would > be better to start pf.conf with the "block all" rule opening > afterwards only those incoming and outcoming ports that are supposed > to be used by the system on external interfaces. However, it would be > easier for me to write all pf rules if I start pf.conf with "block in > all", i.e. if I block only traffic coming in from the outside and open > all ports for outgoing traffic. > > - Incoming ports: only udp/68 (for dhcp client) and http/80 (for http > server) always open; > - Outgoing ports: all ports always opened. All traffic going outside > from the system has "keep state"; > > What disadvantages does it have in term of security in comparison with > "block all"? In other words, how bad it is to have all outgoing ports > always opened and whether someone can use this to hack the sysem? > > Thanks a lot for any tips!! > Aleksej. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 19:50:53 2010 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 4865A106568F for ; Wed, 28 Jul 2010 19:50:53 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from mail1.jellyfishnet.co.uk (mail1.jellyfishnet.co.uk [93.91.20.9]) by mx1.freebsd.org (Postfix) with ESMTP id D847F8FC20 for ; Wed, 28 Jul 2010 19:50:52 +0000 (UTC) Received: from pemexhub01.jellyfishnet.co.uk.local (93.91.20.2) by mail1.jellyfishnet.co.uk (93.91.20.9) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 28 Jul 2010 20:39:58 +0100 Received: from PEMEXMBXVS02.jellyfishnet.co.uk.local ([192.168.65.37]) by pemexhub01.jellyfishnet.co.uk.local ([192.168.65.7]) with mapi; Wed, 28 Jul 2010 20:39:56 +0100 From: Greg Hennessy To: "Spenst, Aleksej" , "freebsd-pf@freebsd.org" Date: Wed, 28 Jul 2010 20:39:55 +0100 Thread-Topic: For better security: always "block all" or "block in all" is enough? Thread-Index: AcsuhnPxDAhf7j3xSK6TAzUseHLnBQABes/Q Message-ID: <9E8D76EC267C9444AC737F649CBBAD902769BF6F5B@PEMEXMBXVS02.jellyfishnet.co.uk.local> References: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> In-Reply-To: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: For better security: always "block all" or "block in all" is enough? 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, 28 Jul 2010 19:50:53 -0000 > What disadvantages does it have in term of security in comparison with > "block all"? In other words, how bad it is to have all outgoing ports alw= ays > opened and whether someone can use this to hack the sysem? >=20 It's the principle of 'least privilege'. Explicitly allow what is permitte= d, deny everything else.=20 It should also be=20 block log all A default block policy without logging has a certain ass biting inevitabili= ty to it.=20 Greg =20 From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 20:04:45 2010 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 F1AE3106566C for ; Wed, 28 Jul 2010 20:04:44 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [69.42.208.18]) by mx1.freebsd.org (Postfix) with ESMTP id DE8528FC1A for ; Wed, 28 Jul 2010 20:04:44 +0000 (UTC) Received: from [192.168.1.64] (99-118-214-35.lightspeed.irvnca.sbcglobal.net [99.118.214.35]) by sed.awknet.com (Postfix) with ESMTP id 8F69F10824AC for ; Wed, 28 Jul 2010 20:04:44 +0000 (UTC) Message-ID: <4C508D5A.6000600@sk1llz.net> Date: Wed, 28 Jul 2010 13:04:42 -0700 From: Justin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: pf synproxy 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, 28 Jul 2010 20:04:45 -0000 Logged to files and dumped; Outside: 19:58:09.571810 IP (tos 0x0, ttl 118, id 12726, offset 0, flags [DF], proto TCP (6), length 52) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0xb15f (correct), se q 3641874856, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 19:58:09.571835 IP (tos 0x10, ttl 64, id 6840, offset 0, flags [DF], proto TCP ( 6), length 44) TARGET_HOST.80 > REMOTE_CLIENT.56270: Flags [S.], cksum 0xa352 (correct), s eq 4110180879, ack 3641874857, win 0, options [mss 1460], length 0 19:58:09.583132 IP (tos 0x0, ttl 118, id 12727, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.593498 IP (tos 0x0, ttl 118, id 12728, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.603117 IP (tos 0x0, ttl 118, id 12729, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.617101 IP (tos 0x0, ttl 118, id 12730, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.628812 IP (tos 0x0, ttl 118, id 12731, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.641101 IP (tos 0x0, ttl 118, id 12732, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.652398 IP (tos 0x0, ttl 118, id 12733, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.662468 IP (tos 0x0, ttl 118, id 12734, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.674054 IP (tos 0x0, ttl 118, id 12735, offset 0, flags [DF], proto TCP (6), length 40) Inside: 19:58:09.583144 IP (tos 0x10, ttl 64, id 6841, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.593505 IP (tos 0x10, ttl 64, id 6842, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.603123 IP (tos 0x10, ttl 64, id 6843, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.617107 IP (tos 0x10, ttl 64, id 6844, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.628819 IP (tos 0x10, ttl 64, id 6845, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.641108 IP (tos 0x10, ttl 64, id 6846, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.709553 IP (tos 0x10, ttl 64, id 6852, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.719427 IP (tos 0x10, ttl 64, id 6853, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.729501 IP (tos 0x10, ttl 64, id 6854, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.739096 IP (tos 0x10, ttl 64, id 6855, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.749464 IP (tos 0x10, ttl 64, id 6856, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 Some people on the OpenBSD list suggested it had something to do with synproxy only working on the interface that has a default gateway - I've tried all variations of em0/1 being the default route out, still no changes. em0 tcp TARGET_HOST:80 <- REMOTE_CLIENT:56273 PROXY:DST [0 + 4143199136] [2614600686 + 3007453693] age 00:00:10, expires in 00:01:50, 0:0 pkts, 0:0 bytes, rule 1 id: 4c4f86b6000012a8 creatorid: e7945cd2 Never gets beyond that. On 7/28/2010 12:06 AM, Daniel Hartmeier wrote: > On Tue, Jul 27, 2010 at 07:24:56PM -0700, Justin wrote: > >> - tcpdumps showing the initial connect attempt (logs below were >> furhter along the process); >> >> external: >> 02:21:25.595977 IP (tos 0x0, ttl 118, id 10020, offset 0, flags [DF], >> proto TCP >> (6), length 52) >> REMOTE_VIEWING_HOST.53782> CLIENT_DESTINATION_IP.80: Flags [S], >> cksum 0x537b (correct), se >> q 2569879850, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], >> length 0 >> 02:21:25.596000 IP (tos 0x10, ttl 64, id 27957, offset 0, flags [DF], >> proto TCP >> (6), length 44) >> CLIENT_DESTINATION_IP.80> REMOTE_VIEWING_HOST.53782: Flags [S.], >> cksum 0x7920 (correct), s >> eq 3819585455, ack 2569879851, win 0, options [mss 1460], length 0 >> 02:21:25.605825 IP (tos 0x0, ttl 118, id 10021, offset 0, flags [DF], >> proto TCP >> (6), length 40) >> REMOTE_VIEWING_HOST.53782> CLIENT_DESTINATION_IP.80: Flags [.], >> cksum 0x95ec (correct), ac >> k 3819585456, win 64240, length 0 >> 02:21:25.615953 IP (tos 0x0, ttl 118, id 10022, offset 0, flags [DF], >> proto TCP >> (6), length 40) > The TCP handshake with the client makes sense. > > The client's SYN offers wscale and sack, pf's SYN+ACK has IP tos 0x10 > and neither wscale nor sack, and win 0. > >> internal: >> 02:22:34.717332 IP (tos 0x0, ttl 118, id 22015, offset 0, flags [DF], >> proto TCP >> (6), length 52) >> REMOTE_VIEWING_HOST.53786> CLIENT_DESTINATION_IP.80: Flags [S], >> cksum 0x84ee (correct), se >> q 1816476827, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], >> length 0 > This doesn't seem to be captured on the internal interface, at least > it is not the server handshake replayed by pf's synproxy. > Note the (random) client source port 53786 doesn't match 53782 of the > external capture above. > > Instead, it looks like ANOTHER connection captured on the external > interface. The SYN has IP tos 0x0 and offers wscale and sack, so > this CANNOT be a packet generated by pf's synproxy... > > What we want to see is the two TCP handshakes related to the same > client connection, once on the interface towards the client, once > on the interface towards the server. The client source port is the > same. > > Ideally, tcpdump on both interface, writing to two files with > tcpdump -w. Reproduce the issue. Find out what client source port > was used for that connection. Then tcpdump -r and extract all packets > of that port (src or dst) in both files... > > And the pfctl -vvss output should contain the state with that port > as well. > > There is precisely one external and one internal interface, and > pf is the only connection between these two networks, right? > If the client's SYN can somehow reach the server bypassing pf, > the synproxy will not work, there'd be two handshakes to the server > using different sequence numbers, the server would accept the first, > ignore the other, confusion would ensue ;) > > Daniel From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 20:22:47 2010 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 D65F51065675 for ; Wed, 28 Jul 2010 20:22:47 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 3A6B68FC21 for ; Wed, 28 Jul 2010 20:22:46 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id o6SKMmfB027903 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 28 Jul 2010 22:22:48 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id o6SKMjTV015064; Wed, 28 Jul 2010 22:22:45 +0200 (MEST) Date: Wed, 28 Jul 2010 22:22:45 +0200 From: Daniel Hartmeier To: Justin Message-ID: <20100728202245.GB11444@insomnia.benzedrine.cx> References: <4C508D5A.6000600@sk1llz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C508D5A.6000600@sk1llz.net> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-pf@freebsd.org Subject: Re: pf synproxy 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, 28 Jul 2010 20:22:48 -0000 On Wed, Jul 28, 2010 at 01:04:42PM -0700, Justin wrote: > Logged to files and dumped; > > Outside: > 19:58:09.571810 IP (tos 0x0, ttl 118, id 12726, offset 0, flags [DF], > proto TCP > (6), length 52) > REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0xb15f > (correct), se > q 3641874856, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], > length 0 > 19:58:09.571835 IP (tos 0x10, ttl 64, id 6840, offset 0, flags [DF], > proto TCP ( > 6), length 44) > TARGET_HOST.80 > REMOTE_CLIENT.56270: Flags [S.], cksum 0xa352 > (correct), s > eq 4110180879, ack 3641874857, win 0, options [mss 1460], length 0 > 19:58:09.583132 IP (tos 0x0, ttl 118, id 12727, offset 0, flags [DF], > proto TCP > (6), length 40) > REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e > (correct), ac > k 4110180880, win 64240, length 0 The handshake between client and synproxy looks fine. Now the synproxy should handshake with the server: > Inside: > 19:58:09.583144 IP (tos 0x10, ttl 64, id 6841, offset 0, flags [DF], > proto TCP ( > 6), length 44) > REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 > (correct), se > q 2026752522, win 0, options [mss 1460], length 0 > 19:58:09.593505 IP (tos 0x10, ttl 64, id 6842, offset 0, flags [DF], > proto TCP ( > 6), length 44) > REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 > (correct), se > q 2026752522, win 0, options [mss 1460], length 0 The synproxy keeps sending its SYN, but never gets a SYN+ACK from the server. The handshake doesn't complete. So, the question is why the server doesn't reply with SYN+ACK. - Does the server receive the SYN? Try tcpdump on the server itself. - Does the server consider it invalid for some reason? Firewalling on the server? netstat -s tcp on the server (any errors increasing)? Maybe it doesn't like the zero sized window? What OS is it? - The server hasn't seen the client's original SYN, has it, i.e. through some other path, bypassing the pf box? tcpdump on the server to be sure... - Does the server actually reply with SYN+ACK? Again tcpdump on the server itself. - If so, why does that SYN+ACK not reach the synproxy? - Default gateway of the server correctly set to synproxy's address? - netstat -anr, arp -a on the server? > Some people on the OpenBSD list suggested it had something to do > with synproxy only working on the interface that has a default gateway - > I've tried all variations of em0/1 being the default route out, still no > changes. When synproxy generates a packet (either the SYN+ACK towards the client, or the SYN and ACK towards the server), it will send those out with ip_output(), which simply uses the routing table to decide which interface to use to send the packet. Usually, like in your case, the client is reachable through the default gateway and the server through a local network route, and things work fine. There just isn't any additional logic in synproxy to route generated packets differently (as in "route SYN+ACK always back out through the interface the client SYN came back in through", or such, which some people seem to assume), and route-to/reply-to do not apply to synproxy generated packets, IIRC. Daniel From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 20:31:54 2010 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 4B860106566B for ; Wed, 28 Jul 2010 20:31:54 +0000 (UTC) (envelope-from jon@radel.com) Received: from wave.radel.com (wave.radel.com [216.143.151.4]) by mx1.freebsd.org (Postfix) with ESMTP id E308B8FC1F for ; Wed, 28 Jul 2010 20:31:53 +0000 (UTC) Received: by wave.radel.com (CommuniGate Pro PIPE 4.1.6) with PIPE id 9751850; Wed, 28 Jul 2010 15:31:53 -0400 Received: from [192.168.43.221] (account jon@radel.com HELO braeburn.local) by wave.radel.com (CommuniGate Pro SMTP 4.1.6) with ESMTP-TLS id 9751848 for freebsd-pf@freebsd.org; Wed, 28 Jul 2010 15:31:45 -0400 Message-ID: <4C5085A1.6070905@radel.com> Date: Wed, 28 Jul 2010 15:31:45 -0400 From: Jon Radel User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> In-Reply-To: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000908020603000906060608" X-Radel.com-MailScanner-Information: Please contact Jon for more information X-Radel.com-MailScanner: Found to be clean X-Mailer: CommuniGate Pro CLI mailer X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: For better security: always "block all" or "block in all" is enough? 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, 28 Jul 2010 20:31:54 -0000 This is a cryptographically signed message in MIME format. --------------ms000908020603000906060608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 7/28/10 2:55 PM, Spenst, Aleksej wrote: > Hi All, > > I have to provide for my system better security and I guess it would be= better to start pf.conf with the "block all" rule opening afterwards onl= y those incoming and outcoming ports that are supposed to be used by the = system on external interfaces. However, it would be easier for me to writ= e all pf rules if I start pf.conf with "block in all", i.e. if I block on= ly traffic coming in from the outside and open all ports for outgoing tra= ffic. > > - Incoming ports: only udp/68 (for dhcp client) and http/80 (for http s= erver) always open; > - Outgoing ports: all ports always opened. All traffic going outside fr= om the system has "keep state"; > > What disadvantages does it have in term of security in comparison with = "block all"? In other words, how bad it is to have all outgoing ports alw= ays opened and whether someone can use this to hack the sysem? > > Thanks a lot for any tips!! > Aleksej. > > =20 The only real answer is: It depends. :-) One example of outbound blocking that some find useful: Block all=20 outbound traffic to port 25 that comes from any machine other than=20 authorized e-mail servers. On one network I deal in, this makes sense,=20 as the various Windows workstations have no business sending mail to=20 anything other than the internal mail servers, and if they try there's a = good chance it's a trojan of some sort doing the sending. Obviously,=20 there are other networks where this would make no sense. In a general sort of way, allowing outbound traffic doesn't expose you=20 to attacks, but it makes your machine more valuable to an attacker who=20 does succeed. For example, if you allow outbound ssh and telnet, etc.,=20 etc., it makes it easier to use your machine to stage attacks on other=20 machines. On the other hand, if the firewall is on the server in=20 question, rather than being another piece of equipment, anybody who has=20 root can rearrange your firewall for you.... --=20 --Jon Radel jon@radel.com --------------ms000908020603000906060608-- From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 21:00:21 2010 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 4CCF7106566B for ; Wed, 28 Jul 2010 21:00:21 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [69.42.208.18]) by mx1.freebsd.org (Postfix) with ESMTP id 299018FC1D for ; Wed, 28 Jul 2010 21:00:20 +0000 (UTC) Received: from [192.168.1.64] (99-118-214-35.lightspeed.irvnca.sbcglobal.net [99.118.214.35]) by sed.awknet.com (Postfix) with ESMTP id B5F5B10824AC for ; Wed, 28 Jul 2010 21:00:20 +0000 (UTC) Message-ID: <4C509A62.6040208@sk1llz.net> Date: Wed, 28 Jul 2010 14:00:18 -0700 From: Justin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: pf synproxy 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, 28 Jul 2010 21:00:21 -0000 Logged to files and dumped; Outside: 19:58:09.571810 IP (tos 0x0, ttl 118, id 12726, offset 0, flags [DF], proto TCP (6), length 52) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0xb15f (correct), se q 3641874856, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 19:58:09.571835 IP (tos 0x10, ttl 64, id 6840, offset 0, flags [DF], proto TCP ( 6), length 44) TARGET_HOST.80 > REMOTE_CLIENT.56270: Flags [S.], cksum 0xa352 (correct), s eq 4110180879, ack 3641874857, win 0, options [mss 1460], length 0 19:58:09.583132 IP (tos 0x0, ttl 118, id 12727, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.593498 IP (tos 0x0, ttl 118, id 12728, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.603117 IP (tos 0x0, ttl 118, id 12729, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.617101 IP (tos 0x0, ttl 118, id 12730, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.628812 IP (tos 0x0, ttl 118, id 12731, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.641101 IP (tos 0x0, ttl 118, id 12732, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.652398 IP (tos 0x0, ttl 118, id 12733, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.662468 IP (tos 0x0, ttl 118, id 12734, offset 0, flags [DF], proto TCP (6), length 40) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [.], cksum 0xc01e (correct), ac k 4110180880, win 64240, length 0 19:58:09.674054 IP (tos 0x0, ttl 118, id 12735, offset 0, flags [DF], proto TCP (6), length 40) Inside: 19:58:09.583144 IP (tos 0x10, ttl 64, id 6841, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.593505 IP (tos 0x10, ttl 64, id 6842, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.603123 IP (tos 0x10, ttl 64, id 6843, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.617107 IP (tos 0x10, ttl 64, id 6844, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.628819 IP (tos 0x10, ttl 64, id 6845, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.641108 IP (tos 0x10, ttl 64, id 6846, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.709553 IP (tos 0x10, ttl 64, id 6852, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.719427 IP (tos 0x10, ttl 64, id 6853, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.729501 IP (tos 0x10, ttl 64, id 6854, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.739096 IP (tos 0x10, ttl 64, id 6855, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 19:58:09.749464 IP (tos 0x10, ttl 64, id 6856, offset 0, flags [DF], proto TCP ( 6), length 44) REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0x2a53 (correct), se q 2026752522, win 0, options [mss 1460], length 0 Some people on the OpenBSD list suggested it had something to do with synproxy only working on the interface that has a default gateway - I've tried all variations of em0/1 being the default route out, still no changes. em0 tcp TARGET_HOST:80 <- REMOTE_CLIENT:56273 PROXY:DST [0 + 4143199136] [2614600686 + 3007453693] age 00:00:10, expires in 00:01:50, 0:0 pkts, 0:0 bytes, rule 1 id: 4c4f86b6000012a8 creatorid: e7945cd2 Never gets beyond that. On 7/28/2010 12:06 AM, Daniel Hartmeier wrote: > On Tue, Jul 27, 2010 at 07:24:56PM -0700, Justin wrote: > >> - tcpdumps showing the initial connect attempt (logs below were >> furhter along the process); >> >> external: >> 02:21:25.595977 IP (tos 0x0, ttl 118, id 10020, offset 0, flags [DF], >> proto TCP >> (6), length 52) >> REMOTE_VIEWING_HOST.53782> CLIENT_DESTINATION_IP.80: Flags [S], >> cksum 0x537b (correct), se >> q 2569879850, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], >> length 0 >> 02:21:25.596000 IP (tos 0x10, ttl 64, id 27957, offset 0, flags [DF], >> proto TCP >> (6), length 44) >> CLIENT_DESTINATION_IP.80> REMOTE_VIEWING_HOST.53782: Flags [S.], >> cksum 0x7920 (correct), s >> eq 3819585455, ack 2569879851, win 0, options [mss 1460], length 0 >> 02:21:25.605825 IP (tos 0x0, ttl 118, id 10021, offset 0, flags [DF], >> proto TCP >> (6), length 40) >> REMOTE_VIEWING_HOST.53782> CLIENT_DESTINATION_IP.80: Flags [.], >> cksum 0x95ec (correct), ac >> k 3819585456, win 64240, length 0 >> 02:21:25.615953 IP (tos 0x0, ttl 118, id 10022, offset 0, flags [DF], >> proto TCP >> (6), length 40) > The TCP handshake with the client makes sense. > > The client's SYN offers wscale and sack, pf's SYN+ACK has IP tos 0x10 > and neither wscale nor sack, and win 0. > >> internal: >> 02:22:34.717332 IP (tos 0x0, ttl 118, id 22015, offset 0, flags [DF], >> proto TCP >> (6), length 52) >> REMOTE_VIEWING_HOST.53786> CLIENT_DESTINATION_IP.80: Flags [S], >> cksum 0x84ee (correct), se >> q 1816476827, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], >> length 0 > This doesn't seem to be captured on the internal interface, at least > it is not the server handshake replayed by pf's synproxy. > Note the (random) client source port 53786 doesn't match 53782 of the > external capture above. > > Instead, it looks like ANOTHER connection captured on the external > interface. The SYN has IP tos 0x0 and offers wscale and sack, so > this CANNOT be a packet generated by pf's synproxy... > > What we want to see is the two TCP handshakes related to the same > client connection, once on the interface towards the client, once > on the interface towards the server. The client source port is the > same. > > Ideally, tcpdump on both interface, writing to two files with > tcpdump -w. Reproduce the issue. Find out what client source port > was used for that connection. Then tcpdump -r and extract all packets > of that port (src or dst) in both files... > > And the pfctl -vvss output should contain the state with that port > as well. > > There is precisely one external and one internal interface, and > pf is the only connection between these two networks, right? > If the client's SYN can somehow reach the server bypassing pf, > the synproxy will not work, there'd be two handshakes to the server > using different sequence numbers, the server would accept the first, > ignore the other, confusion would ensue ;) > > Daniel From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 21:01:16 2010 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 0CB8F1065673 for ; Wed, 28 Jul 2010 21:01:16 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [69.42.208.18]) by mx1.freebsd.org (Postfix) with ESMTP id EDF218FC13 for ; Wed, 28 Jul 2010 21:01:15 +0000 (UTC) Received: from [192.168.1.64] (99-118-214-35.lightspeed.irvnca.sbcglobal.net [99.118.214.35]) by sed.awknet.com (Postfix) with ESMTP id D679A10824A0 for ; Wed, 28 Jul 2010 21:01:15 +0000 (UTC) Message-ID: <4C509A99.4030305@sk1llz.net> Date: Wed, 28 Jul 2010 14:01:13 -0700 From: Justin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: pf synproxy 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, 28 Jul 2010 21:01:16 -0000 (forgot to cc freebsd-pf sorry) Ahh. That explains it then. I was operating under the assumption that the machine doing the synproxy would forge the reply such that the TARGET host would reply to the synproxy box, not its default gateway. As in 1.2.3.4 request to client 5.5.5.5 via -> 2.3.4.5, forged 2.3.4.5 request to 5.5.5.5, 5.5.5.5 replies to 2.3.4.5, 2.3.4.5 no long proxies state and allows 1.2.3.4 and 5.5.5.5 to talk to each other directly. The topology is as such: internet - switch -> em0 | pf | em1 -> switch -> client \--------------------------/ So the clients default gateway out is the switch, which doesn't send all traffic back over the PF machine. From what you've described, the PF synproxy box would literally have to be inline and the default gateway. internet - em0 | pf | em1 -> client Is this the case? On 7/28/2010 1:22 PM, Daniel Hartmeier wrote: > On Wed, Jul 28, 2010 at 01:04:42PM -0700, Justin wrote: > >> Logged to files and dumped; >> >> Outside: >> 19:58:09.571810 IP (tos 0x0, ttl 118, id 12726, offset 0, flags [DF], >> proto TCP >> (6), length 52) >> REMOTE_CLIENT.56270> TARGET_HOST.80: Flags [S], cksum 0xb15f >> (correct), se >> q 3641874856, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], >> length 0 >> 19:58:09.571835 IP (tos 0x10, ttl 64, id 6840, offset 0, flags [DF], >> proto TCP ( >> 6), length 44) >> TARGET_HOST.80> REMOTE_CLIENT.56270: Flags [S.], cksum 0xa352 >> (correct), s >> eq 4110180879, ack 3641874857, win 0, options [mss 1460], length 0 >> 19:58:09.583132 IP (tos 0x0, ttl 118, id 12727, offset 0, flags [DF], >> proto TCP >> (6), length 40) >> REMOTE_CLIENT.56270> TARGET_HOST.80: Flags [.], cksum 0xc01e >> (correct), ac >> k 4110180880, win 64240, length 0 > The handshake between client and synproxy looks fine. > > Now the synproxy should handshake with the server: > >> Inside: >> 19:58:09.583144 IP (tos 0x10, ttl 64, id 6841, offset 0, flags [DF], >> proto TCP ( >> 6), length 44) >> REMOTE_CLIENT.56270> TARGET_HOST.80: Flags [S], cksum 0x2a53 >> (correct), se >> q 2026752522, win 0, options [mss 1460], length 0 >> 19:58:09.593505 IP (tos 0x10, ttl 64, id 6842, offset 0, flags [DF], >> proto TCP ( >> 6), length 44) >> REMOTE_CLIENT.56270> TARGET_HOST.80: Flags [S], cksum 0x2a53 >> (correct), se >> q 2026752522, win 0, options [mss 1460], length 0 > The synproxy keeps sending its SYN, but never gets a SYN+ACK from > the server. The handshake doesn't complete. > > So, the question is why the server doesn't reply with SYN+ACK. > > - Does the server receive the SYN? Try tcpdump on the server itself. > - Does the server consider it invalid for some reason? Firewalling > on the server? netstat -s tcp on the server (any errors increasing)? > Maybe it doesn't like the zero sized window? What OS is it? > - The server hasn't seen the client's original SYN, has it, i.e. through > some other path, bypassing the pf box? tcpdump on the server to be > sure... > - Does the server actually reply with SYN+ACK? Again tcpdump on the > server itself. > - If so, why does that SYN+ACK not reach the synproxy? > - Default gateway of the server correctly set to synproxy's address? > - netstat -anr, arp -a on the server? > >> Some people on the OpenBSD list suggested it had something to do >> with synproxy only working on the interface that has a default gateway - >> I've tried all variations of em0/1 being the default route out, still no >> changes. > When synproxy generates a packet (either the SYN+ACK towards the client, > or the SYN and ACK towards the server), it will send those out with > ip_output(), which simply uses the routing table to decide which > interface to use to send the packet. Usually, like in your case, the > client is reachable through the default gateway and the server through > a local network route, and things work fine. There just isn't any > additional logic in synproxy to route generated packets differently > (as in "route SYN+ACK always back out through the interface the client > SYN came back in through", or such, which some people seem to assume), > and route-to/reply-to do not apply to synproxy generated packets, IIRC. > > Daniel From owner-freebsd-pf@FreeBSD.ORG Thu Jul 29 02:52:58 2010 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 6FAA6106566C for ; Thu, 29 Jul 2010 02:52:58 +0000 (UTC) (envelope-from allicient3141@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E9ADF8FC2E for ; Thu, 29 Jul 2010 02:52:57 +0000 (UTC) Received: by bwz12 with SMTP id 12so64066bwz.13 for ; Wed, 28 Jul 2010 19:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=bdoA1Urqt0c4+psKj4jDtEXWkWB/9W3x6u5Q0VhgI9g=; b=xoINvncgM1Ql8m6bu25TF0u1vvF4Ye0TaF7Cho2FORIp2x7AVz7kVylFOQJ4IjJLqd sbfIThrFOMJBbPcXInx6i4DfHyc04jkjAIT3JgicdsOK9jiZmnkxDLaS2ppwDXQJzm1S I7VQf0O0nd7KllXilBHaagDUNYPv4SIZ3Bsuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=B3buTozDBdS5l9KjUaGagJ+TIwgsi7JyqL8BWRa3MfD6QuLxlpJJNy9fMou2FUkKGv 7ge2Fkwd67+Z42uqXZn0h0MLJbMUdMpJwrHCgu2Et20vBQxIB6/JfNlYiHulirAkb5yx wkqnqmoCW61PQEfUniQg/XET1OSUji6jYQgTM= MIME-Version: 1.0 Received: by 10.204.67.147 with SMTP id r19mr7927887bki.176.1280371972753; Wed, 28 Jul 2010 19:52:52 -0700 (PDT) Sender: allicient3141@gmail.com Received: by 10.204.112.208 with HTTP; Wed, 28 Jul 2010 19:52:52 -0700 (PDT) In-Reply-To: <9E8D76EC267C9444AC737F649CBBAD902769BF6F5B@PEMEXMBXVS02.jellyfishnet.co.uk.local> References: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> <9E8D76EC267C9444AC737F649CBBAD902769BF6F5B@PEMEXMBXVS02.jellyfishnet.co.uk.local> Date: Thu, 29 Jul 2010 03:52:52 +0100 X-Google-Sender-Auth: caAbc7hVtBrswdLP6JL3vvl2yIg Message-ID: From: Peter Maxwell To: Greg Hennessy Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Spenst, Aleksej" , "freebsd-pf@freebsd.org" Subject: Re: For better security: always "block all" or "block in all" is enough? 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: Thu, 29 Jul 2010 02:52:58 -0000 On 28 July 2010 20:39, Greg Hennessy wrote: > > > What disadvantages does it have in term of security in comparison with > > "block all"? In other words, how bad it is to have all outgoing ports > always > > opened and whether someone can use this to hack the sysem? > > > > It's the principle of 'least privilege'. Explicitly allow what is > permitted, deny everything else. > > It should also be > > block log all > > A default block policy without logging has a certain ass biting > inevitability to it. > > However not as much "ass biting" potential as with logging on. Ask anyone who has done commercial firewall work and they'll tell you not to enable logging on the default deny/drop rule unless you are debugging/testing - think denial of service. From owner-freebsd-pf@FreeBSD.ORG Thu Jul 29 02:59:22 2010 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 C5758106566C for ; Thu, 29 Jul 2010 02:59:22 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [69.42.208.18]) by mx1.freebsd.org (Postfix) with ESMTP id B2C888FC0C for ; Thu, 29 Jul 2010 02:59:22 +0000 (UTC) Received: from [192.168.1.64] (99-118-214-35.lightspeed.irvnca.sbcglobal.net [99.118.214.35]) by sed.awknet.com (Postfix) with ESMTP id 6083510824B1; Thu, 29 Jul 2010 02:59:22 +0000 (UTC) Message-ID: <4C50EE88.3010206@sk1llz.net> Date: Wed, 28 Jul 2010 19:59:20 -0700 From: Justin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-pf@freebsd.org, misc@openbsd.org References: <4C509A99.4030305@sk1llz.net> In-Reply-To: <4C509A99.4030305@sk1llz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: pf synproxy 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: Thu, 29 Jul 2010 02:59:22 -0000 Confirmed - synproxy works great if the synproxy machine is the default gateway for the end host. Sadly this means scalability (adding multiple synproxy boxes) is not possible, nor is it possible to filter a specific IP out of the end machines ranges. Perhaps I'm shooting for the moon here - but shouldn't it be possible to have a machine validate a remote host to be real and then create a state to simply permit all traffic from it to pass without additional filtering? Thus no breaking of packets and allowing the remote host to respond directly? On 7/28/2010 2:01 PM, Justin wrote: > > > Ahh. That explains it then. I was operating under the assumption > that the machine doing the synproxy would forge the reply such that > the TARGET host would reply to the synproxy box, not its default gateway. > > As in 1.2.3.4 request to client 5.5.5.5 via -> 2.3.4.5, forged 2.3.4.5 > request to 5.5.5.5, 5.5.5.5 replies to 2.3.4.5, 2.3.4.5 no long > proxies state and allows 1.2.3.4 and 5.5.5.5 to talk to each other > directly. > > The topology is as such: > > internet - switch -> em0 | pf | em1 -> switch -> client > \--------------------------/ > > So the clients default gateway out is the switch, which doesn't send > all traffic back over the PF machine. From what you've described, the > PF synproxy box would literally have to be inline and the default > gateway. > > internet - em0 | pf | em1 -> client > > Is this the case? > > From owner-freebsd-pf@FreeBSD.ORG Thu Jul 29 05:37:48 2010 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 6F10B106564A for ; Thu, 29 Jul 2010 05:37:48 +0000 (UTC) (envelope-from mcbride@openbsd.org) Received: from smtp1.countersiege.com (imap.countersiege.com [IPv6:2001:240:581:69::218]) by mx1.freebsd.org (Postfix) with ESMTP id 56C348FC1B for ; Thu, 29 Jul 2010 05:37:48 +0000 (UTC) Received: from anchovy.countersiege.com (unknown [IPv6:::1]) by smtp1.countersiege.com (Postfix) with ESMTP id 2B422192F3; Thu, 29 Jul 2010 05:37:47 +0000 (UTC) Received: by anchovy.countersiege.com (Postfix, from userid 2000) id 835454C238; Thu, 29 Jul 2010 14:37:45 +0900 (JST) Date: Thu, 29 Jul 2010 14:37:45 +0900 From: Ryan McBride To: Justin Message-ID: <20100729053745.GC13817@countersiege.com> References: <4C509A99.4030305@sk1llz.net> <4C50EE88.3010206@sk1llz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C50EE88.3010206@sk1llz.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: misc@openbsd.org, freebsd-pf@freebsd.org Subject: Re: pf synproxy 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: Thu, 29 Jul 2010 05:37:48 -0000 On Wed, Jul 28, 2010 at 07:59:20PM -0700, Justin wrote: > Confirmed - synproxy works great if the synproxy machine is the > default gateway for the end host. Yes, PF has to handle every packet of a synproxy'd connection. > Sadly this means scalability (adding multiple synproxy boxes) is not > possible, nor is it possible to filter a specific IP out of the end > machines ranges. It's not clear what you mean by either of these statements. > Perhaps I'm shooting for the moon here - but shouldn't it be > possible to have a machine validate a remote host to be real and > then create a state to simply permit all traffic from it to pass > without additional filtering? Thus no breaking of packets and > allowing the remote host to respond directly? I don't think it is possible to do what you want. Once you have completed the 3-way handshake and negotiated a set of sequence numbers to use for the connection, there is no way to simply dump the established connection on another box that knows nothing about it. synproxy works by completing the 3-way handshake with the source first, then negotiating a separate 3-way handshake with the client. Because the negotiations are separate and the two endpoints have no direct knowlege of each other, there sequence numbers negotiated are different. PF handles translation between the different sets of sequence numbers, and has to be man-in-the middle for every packet on the connection in order to do this translation. From owner-freebsd-pf@FreeBSD.ORG Thu Jul 29 08:27:14 2010 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 B1FBB1065679 for ; Thu, 29 Jul 2010 08:27:14 +0000 (UTC) (envelope-from denis.doroshenko@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 48D878FC1C for ; Thu, 29 Jul 2010 08:27:13 +0000 (UTC) Received: by wwa36 with SMTP id 36so65686wwa.31 for ; Thu, 29 Jul 2010 01:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=aXLuuUp2o4dYQw0D/QbOskzq9Qbdat+vwCVEOC24GWQ=; b=RfSUnHYTL+yvsCf08pQy8OAglgV5KS4EjKXuIXVnDGuD3okFUJzJ99w+OOkBy6UzTm 0qiA1gDR3zAAAAimoMAX3bRkshZh//sCjVCXFdz1ljLVnSax6Xv/zTpQ+l/2Ek1y3vLZ lMnkRU6rLIQ5D7vQt7gquHUD8C8qiGiTTGpP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fkHx81h830IHV0KZKmJRxAl3pmKX56sPuWa9OSvp/e0TBpzalj6EtabUFG3fs6vs4Z 28A1vabeiKYZZ8tbD7xTDOhGBxzoX09Ecs/LhEWFW8pXO9Y/Wp1T5KIJE7T0pLp7BkOU QrbfAQ3O1lZHvgrj2Lejq/OpOYSfvXnfQlVgs= MIME-Version: 1.0 Received: by 10.227.27.209 with SMTP id j17mr11720408wbc.88.1280390465482; Thu, 29 Jul 2010 01:01:05 -0700 (PDT) Received: by 10.227.132.1 with HTTP; Thu, 29 Jul 2010 01:01:05 -0700 (PDT) In-Reply-To: <20100729053745.GC13817@countersiege.com> References: <4C509A99.4030305@sk1llz.net> <4C50EE88.3010206@sk1llz.net> <20100729053745.GC13817@countersiege.com> Date: Thu, 29 Jul 2010 11:01:05 +0300 Message-ID: From: Denis Doroshenko To: Ryan McBride Content-Type: text/plain; charset=UTF-8 Cc: misc@openbsd.org, freebsd-pf@freebsd.org Subject: Re: pf synproxy 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: Thu, 29 Jul 2010 08:27:14 -0000 On 7/29/10, Ryan McBride wrote: > On Wed, Jul 28, 2010 at 07:59:20PM -0700, Justin wrote: > > Sadly this means scalability (adding multiple synproxy boxes) is not > > possible, ... > synproxy works by completing the 3-way handshake with the source first, > then negotiating a separate 3-way handshake with the client. Because the > negotiations are separate and the two endpoints have no direct knowlege > of each other, there sequence numbers negotiated are different. PF > handles translation between the different sets of sequence numbers, and > has to be man-in-the middle for every packet on the connection in order > to do this translation. maybe the scalability issue raised there may be solved with CARP and pfsync, so there may be two (or more?) gateways? From owner-freebsd-pf@FreeBSD.ORG Thu Jul 29 09:37:02 2010 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 414381065677 for ; Thu, 29 Jul 2010 09:37:02 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 2EBFA8FC21 for ; Thu, 29 Jul 2010 09:36:59 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id o6T9awMo025953 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 29 Jul 2010 11:36:58 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id o6T9aqjd021695; Thu, 29 Jul 2010 11:36:52 +0200 (MEST) Date: Thu, 29 Jul 2010 11:36:52 +0200 From: Daniel Hartmeier To: Justin Message-ID: <20100729093652.GA2497@insomnia.benzedrine.cx> References: <4C509A99.4030305@sk1llz.net> <4C50EE88.3010206@sk1llz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C50EE88.3010206@sk1llz.net> User-Agent: Mutt/1.5.12-2006-07-14 Cc: misc@openbsd.org, freebsd-pf@freebsd.org Subject: Re: pf synproxy 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: Thu, 29 Jul 2010 09:37:02 -0000 On Wed, Jul 28, 2010 at 07:59:20PM -0700, Justin wrote: > Confirmed - synproxy works great if the synproxy machine is the > default gateway for the end host. Sadly this means scalability (adding > multiple synproxy boxes) is not possible, nor is it possible to filter a > specific IP out of the end machines ranges. > > Perhaps I'm shooting for the moon here - but shouldn't it be > possible to have a machine validate a remote host to be real and then > create a state to simply permit all traffic from it to pass without > additional filtering? Thus no breaking of packets and allowing the > remote host to respond directly? As Ryan explained, Direct Server Return cannot work for a synproxied connection, since the synproxy needs to translate the TCP sequence numbers in every subsequent packet of the connection. You can NAT the connection going out through the internal interface, replacing the source address with the synproxy's internal address, like nat on em1 inet proto tcp to $client port 80 -> em1 This works even when the connection is synproxied on em0, the packets generated by synproxy get translated as well. For the internal host, the connection would appear to come from the pf box, and it would reply directly to the pf box, without needing its default route (which can continue to point to the router in your case). This would scale to multiple pf boxes (with individual local IP addresses). I guess they could share one external IP using CARP and arpbalance, to spread the load across the farm of synproxies. The downside is that the web servers don't see the real peer IPs anymore, messing up web server log analysis, for instance. Daniel From owner-freebsd-pf@FreeBSD.ORG Thu Jul 29 11:17:51 2010 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 704C81065670 for ; Thu, 29 Jul 2010 11:17:51 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from mail1.jellyfishnet.co.uk (mail1.jellyfishnet.co.uk [93.91.20.9]) by mx1.freebsd.org (Postfix) with ESMTP id 0715B8FC0C for ; Thu, 29 Jul 2010 11:17:50 +0000 (UTC) Received: from pemexhub02.jellyfishnet.co.uk.local (93.91.20.2) by mail1.jellyfishnet.co.uk (93.91.20.9) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 29 Jul 2010 12:17:51 +0100 Received: from PEMEXMBXVS02.jellyfishnet.co.uk.local ([192.168.65.37]) by pemexhub02.jellyfishnet.co.uk.local ([192.168.65.8]) with mapi; Thu, 29 Jul 2010 12:17:49 +0100 From: Greg Hennessy To: Peter Maxwell Date: Thu, 29 Jul 2010 12:17:49 +0100 Thread-Topic: For better security: always "block all" or "block in all" is enough? Thread-Index: AcsuySpKmRaAcQCoQ3O2ifQc77mY8wAQ8VSp Message-ID: <9E8D76EC267C9444AC737F649CBBAD902767E3BF75@PEMEXMBXVS02.jellyfishnet.co.uk.local> References: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> <9E8D76EC267C9444AC737F649CBBAD902769BF6F5B@PEMEXMBXVS02.jellyfishnet.co.uk.local>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Spenst, Aleksej" , "freebsd-pf@freebsd.org" Subject: RE: For better security: always "block all" or "block in all" is enough? 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: Thu, 29 Jul 2010 11:17:51 -0000 "Ask anyone who has done commercial firewall work...." Yes Peter, of course Peter =20 Meanwhile in the real world.... There are Governance, Risk, and Compliance reasons for logging all attempts= to bypass security policy by hitting the default deny rule. =20 These reasons are both de-facto and de-jure obligatory.=20 The Operational and Reputational risks of driving security control points b= lind, far outweigh the tiny residual risk of a putative DoS attack against = a firewall policy with default block logging enabled.=20 Having made PF on FreeBSD bleed in the past through various nefarious testi= ng methods, I can't say that taking the firewall offline through resource e= xhaustion (CPU, Storage, Network) caused by logging was ever a primary caus= e of a test failing.=20 Kind regards Greg From: allicient3141@gmail.com [allicient3141@gmail.com] On Behalf Of Peter = Maxwell [peter@allicient.co.uk] Sent: 29 July 2010 03:52 To: Greg Hennessy Cc: Spenst, Aleksej; freebsd-pf@freebsd.org Subject: Re: For better security: always "block all" or "block in all" is e= nough? On 28 July 2010 20:39, Greg Hennessy wrote: > What disadvantages does it have in term of security in comparison with > "block all"? In other words, how bad it is to have all outgoing ports alw= ays > opened and whether someone can use this to hack the sysem? > It's the principle of 'least privilege'. Explicitly allow what is permitte= d, deny everything else. It should also be block log all A default block policy without logging has a certain ass biting inevitabili= ty to it. However not as much "ass biting" potential as with logging on. Ask anyone = who has done commercial firewall work and they'll tell you not to enable lo= gging on the default deny/drop rule unless you are debugging/testing - thin= k denial of service.= From owner-freebsd-pf@FreeBSD.ORG Thu Jul 29 15:02:28 2010 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 6043B106568E for ; Thu, 29 Jul 2010 15:02:28 +0000 (UTC) (envelope-from allicient3141@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D365B8FC1B for ; Thu, 29 Jul 2010 15:02:27 +0000 (UTC) Received: by bwz12 with SMTP id 12so278872bwz.13 for ; Thu, 29 Jul 2010 08:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=LCl3YrxcyPbj3V6q8QeezuPPbcYy5fH6smN7wKxdSxI=; b=cT37T6dNZGJK/psDqXyP8fqC0JPAhD7CqX1FAEGDg+m1eJEtd4mh1TnmZtvdSngU+Q EJDx0S6U/YX7akp9l24KZOjql2Rz1NgpQLZoVD/2MiOoQyz8C9bX3xEsovGj5t9nVcll U1poT/9hKdcM1OdlJGksvwYnnzhAlJBs3caN0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=VgHDAVKObhwTFdGYk9Ox5H2nT3VBcp8h6MEYufhqa4YPdS2NrlPRBqIlcyOs+WsU+D SChSKUbS3O8qZEHfBZVituele8FFS9icYwxdAWbmpUxKfCULSIdo44VEBpSGuLwq8kJE E8MX0haF3+jOFFzzBENJ7dK4O3Iq6iVHsU72A= MIME-Version: 1.0 Received: by 10.204.16.82 with SMTP id n18mr108201bka.212.1280415746688; Thu, 29 Jul 2010 08:02:26 -0700 (PDT) Sender: allicient3141@gmail.com Received: by 10.204.112.208 with HTTP; Thu, 29 Jul 2010 08:02:26 -0700 (PDT) In-Reply-To: <9E8D76EC267C9444AC737F649CBBAD902767E3BF75@PEMEXMBXVS02.jellyfishnet.co.uk.local> References: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> <9E8D76EC267C9444AC737F649CBBAD902769BF6F5B@PEMEXMBXVS02.jellyfishnet.co.uk.local> <9E8D76EC267C9444AC737F649CBBAD902767E3BF75@PEMEXMBXVS02.jellyfishnet.co.uk.local> Date: Thu, 29 Jul 2010 16:02:26 +0100 X-Google-Sender-Auth: 6QnUuLmYIiadZYkJhCMlomViOlM Message-ID: From: Peter Maxwell To: Greg Hennessy Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-pf@freebsd.org" Subject: Re: For better security: always "block all" or "block in all" is enough? 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: Thu, 29 Jul 2010 15:02:28 -0000 Ah, sarcasm - that implies you must be right. If, as you say, there are "Governance, Risk, and Compliance reasons", perhaps you'd like to specify one or two for each category? Logging a default deny on an internal firewall, yes - ok - I agree with you, that's probably reasonable. However, logging every blocked packet on an internet facing firewall is plain daft. Even the storage requirements would be somewhat onerous, and that's before trying to process the data into something meaningful. And all to confirm that there's a lot of noise and port scanning going on. In practical terms, it may not make much of a difference with pf on FreeBSD - personally, I haven't tested it. I have however seen commercial firewalls fall-over from less. What sort of bandwidth and new connections per second rates and hardware were you using, out of interest? On 29 July 2010 12:17, Greg Hennessy wrote: > "Ask anyone who has done commercial firewall work...." > > > Yes Peter, of course Peter > > > Meanwhile in the real world.... > There are Governance, Risk, and Compliance reasons for logging all attempts > to bypass security policy by hitting the default deny rule. > These reasons are both de-facto and de-jure obligatory. > > > > The Operational and Reputational risks of driving security control points > blind, far outweigh the tiny residual risk of a putative DoS attack against > a firewall policy with default block logging enabled. > > > Having made PF on FreeBSD bleed in the past through various nefarious > testing methods, I can't say that taking the firewall offline through > resource exhaustion (CPU, Storage, Network) caused by logging was ever a > primary cause of a test failing. > > > > > Kind regards > > Greg > > > > From: allicient3141@gmail.com [allicient3141@gmail.com] On Behalf Of Peter > Maxwell [peter@allicient.co.uk] > Sent: 29 July 2010 03:52 > To: Greg Hennessy > Cc: Spenst, Aleksej; freebsd-pf@freebsd.org > Subject: Re: For better security: always "block all" or "block in all" is > enough? > > > > > > On 28 July 2010 20:39, Greg Hennessy wrote: > > > > What disadvantages does it have in term of security in comparison with > > "block all"? In other words, how bad it is to have all outgoing ports > always > > opened and whether someone can use this to hack the sysem? > > > > > It's the principle of 'least privilege'. Explicitly allow what is > permitted, deny everything else. > > It should also be > > block log all > > A default block policy without logging has a certain ass biting > inevitability to it. > > > > > However not as much "ass biting" potential as with logging on. Ask anyone > who has done commercial firewall work and they'll tell you not to enable > logging on the default deny/drop rule unless you are debugging/testing - > think denial of service. > From owner-freebsd-pf@FreeBSD.ORG Thu Jul 29 19:08:30 2010 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 B7A791065670 for ; Thu, 29 Jul 2010 19:08:30 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from mail2.jellyfishnet.co.uk (mail2.jellyfishnet.co.uk [93.91.20.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4DD0B8FC08 for ; Thu, 29 Jul 2010 19:08:30 +0000 (UTC) Received: from pemexhub01.jellyfishnet.co.uk.local (93.91.20.2) by mail2.jellyfishnet.co.uk (93.91.20.10) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 29 Jul 2010 20:09:13 +0100 Received: from PEMEXMBXVS02.jellyfishnet.co.uk.local ([192.168.65.37]) by pemexhub01.jellyfishnet.co.uk.local ([192.168.65.7]) with mapi; Thu, 29 Jul 2010 20:08:28 +0100 From: Greg Hennessy To: Peter Maxwell Date: Thu, 29 Jul 2010 20:08:27 +0100 Thread-Topic: For better security: always "block all" or "block in all" is enough? Thread-Index: AcsvLw/YW5uWLtM9RsKdzfQsP8s+fAAH4DTw Message-ID: <9E8D76EC267C9444AC737F649CBBAD902769C51EE9@PEMEXMBXVS02.jellyfishnet.co.uk.local> References: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> <9E8D76EC267C9444AC737F649CBBAD902769BF6F5B@PEMEXMBXVS02.jellyfishnet.co.uk.local> <9E8D76EC267C9444AC737F649CBBAD902767E3BF75@PEMEXMBXVS02.jellyfishnet.co.uk.local> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "freebsd-pf@freebsd.org" Subject: RE: For better security: always "block all" or "block in all" is enough? 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: Thu, 29 Jul 2010 19:08:30 -0000 DQoNCj4gSWYsIGFzIHlvdSBzYXksIHRoZXJlIGFyZSAiR292ZXJuYW5jZSwgUmlzaywgYW5kIENv bXBsaWFuY2UgcmVhc29ucyIsIA0KPiBwZXJoYXBzIHlvdSdkIGxpa2UgdG8gc3BlY2lmeSBvbmUg b3IgdHdvIGZvciBlYWNoIGNhdGVnb3J5Pw0KDQpTdGFydCB3aXRoIGFuIElTTVMgZGVyaXZlZCBm cm9tIDI3aywgYWRkIGEgc291cGNvbiBvZiBQQ0kgRFNTIHJlcXVpcmVtZW50IDEwLCBCYXNlbCBJ SSwgdGhyb3cgaW4gU09YIDQwNCBvciBhbiBTQVMgNzAgdHlwZSBJSSBhdWRpdCwgeW91IGdldCB0 aGUgcGljdHVyZS4gDQoNCj4gTG9nZ2luZyBhIGRlZmF1bHQgZGVueSBvbiBhbiBpbnRlcm5hbCBm aXJld2FsbCwgeWVzIC0gb2sgLSBJIGFncmVlIHdpdGggeW91LCB0aGF0J3MgcHJvYmFibHkgcmVh c29uYWJsZS4NCg0KT25seSBwcm9iYWJseT8gSG93IG11Y2ggJ2NvbW1lcmNpYWwnIGZpcmV3YWxs IHdvcmsgaGF2ZSB5b3UgZG9uZSBhZ2Fpbiwgc2VyaW91c2x5ID8NCiANCj4gwqBIb3dldmVyLCBs b2dnaW5nIGV2ZXJ5IGJsb2NrZWQgcGFja2V0IG9uIGFuIGludGVybmV0IGZhY2luZyBmaXJld2Fs bCBpcyBwbGFpbiBkYWZ0LiANCg0KU2F5aW5nIGl0IGRvZXNu4oCZdCBtYWtlIGl0IHNvLiANCg0K PiBFdmVuIHRoZSBzdG9yYWdlIHJlcXVpcmVtZW50cyB3b3VsZCBiZSBzb21ld2hhdCBvbmVyb3Vz LCANCg0KU3RvcmFnZSBpcyBjaGVhcC4gRGFtYWdlIHRvIHJlcHV0YXRpb24gY2F1c2VkIGJ5IGJl aW5nIGluIGJyZWFjaCBvZiByZWd1bGF0b3J5IHJlcXVpcmVtZW50cyB3LnIudCBsb2cgcmV0ZW50 aW9uIGlzIG5vdC4gDQoNCj4gYW5kIHRoYXQncyBiZWZvcmUgdHJ5aW5nIHRvIHByb2Nlc3MgdGhl IGRhdGEgaW50byBzb21ldGhpbmcgbWVhbmluZ2Z1bC4gwqANCj4gQW5kIGFsbCB0byBjb25maXJt IHRoYXQgdGhlcmUncyBhIGxvdCBvZiBub2lzZSBhbmQgcG9ydCBzY2FubmluZyBnb2luZyBvbi4N Cg0KT3IgaXQncyBwYXJ0IG9mIGEgbXVjaCBsYXJnZXIgcGljdHVyZSB3aGljaCBpcyBmZWQgaW50 byBhbiBTSUVNIHN5c3RlbSBmb3IgZXZlbnQgY29ycmVsYXRpb24gYW5kIGNvbnNlcXVlbnQgYWxl cnRpbmcuIA0KDQpGaXJld2FsbHMgYXJlIG5vdCB0aGUgb25seSBzZWN1cml0eSBjb250cm9sIHBv aW50cw0KDQoNCkdyZWcNCg0K From owner-freebsd-pf@FreeBSD.ORG Thu Jul 29 21:09:48 2010 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 A044D106566B for ; Thu, 29 Jul 2010 21:09:48 +0000 (UTC) (envelope-from allicient3141@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1EAA08FC13 for ; Thu, 29 Jul 2010 21:09:47 +0000 (UTC) Received: by bwz12 with SMTP id 12so531526bwz.13 for ; Thu, 29 Jul 2010 14:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=tvBrwwyh35eUjI9VCdgPhzwTGUtBCA4JVOzVMshdC64=; b=Tsmz0yE5s3DDqX77ePoNA22zSyrDhMXZ2FO+Ae7Y0acEgjhfhXVXvlL5fp9erRbT/t n1nlCPXSPj1KqHIgaK7ObRY/wC8oD3Nf/0ammeClHNE7ArPr51CSCkOS7Dvxy0JfXswa atlhky349e0k9QN4hFQd556vZFnoEgu6eYTUI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=IHShMZmvW1OKshfockQ+QOEiv7gMrR/DdD7m/lNgbCxeTnanX6bAG/U7gplQk4sip8 U7QOKQhjKMGSCN1SsPBvOzCHOdJ+RjPW/5kPhjBrLT8ljIQP3aSFNWd9wVXMuq+1uFVX ePM80fOtxBhQN94bJNITiW8LKhBzDApY1swzE= MIME-Version: 1.0 Received: by 10.204.178.68 with SMTP id bl4mr462496bkb.119.1280437786937; Thu, 29 Jul 2010 14:09:46 -0700 (PDT) Sender: allicient3141@gmail.com Received: by 10.204.112.208 with HTTP; Thu, 29 Jul 2010 14:09:46 -0700 (PDT) In-Reply-To: <9E8D76EC267C9444AC737F649CBBAD902769C51EE9@PEMEXMBXVS02.jellyfishnet.co.uk.local> References: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> <9E8D76EC267C9444AC737F649CBBAD902769BF6F5B@PEMEXMBXVS02.jellyfishnet.co.uk.local> <9E8D76EC267C9444AC737F649CBBAD902767E3BF75@PEMEXMBXVS02.jellyfishnet.co.uk.local> <9E8D76EC267C9444AC737F649CBBAD902769C51EE9@PEMEXMBXVS02.jellyfishnet.co.uk.local> Date: Thu, 29 Jul 2010 22:09:46 +0100 X-Google-Sender-Auth: G3FcEk-vKYqYaOEv6wcxdilP53c Message-ID: From: Peter Maxwell To: Greg Hennessy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-pf@freebsd.org" Subject: Re: For better security: always "block all" or "block in all" is enough? 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: Thu, 29 Jul 2010 21:09:48 -0000 On 29 July 2010 20:08, Greg Hennessy wrote: > > > > If, as you say, there are "Governance, Risk, and Compliance reasons", > > perhaps you'd like to specify one or two for each category? > > Start with an ISMS derived from 27k, add a soupcon of PCI DSS requirement > 10, Basel II, throw in SOX 404 or an SAS 70 type II audit, you get the > picture. > An ISMS, is a company defined document so will likely have different entrie= s or even none at all for that matter depending on the company. In a previou= s company I worked for, you would have just supported my point. And nice try, what documents & sections in PCI DSS, Basel II, and SOX are you referring to? > > Logging a default deny on an internal firewall, yes - ok - I agree with > you, that's probably reasonable. > > Only probably? How much 'commercial' firewall work have you done again, > seriously ? > Again? I didn't tell you to begin with. As it happens, more than ten years, a significant proportion of which was in a major ISP. Since we're playing who's willy is bigger, what about yourself? > > > However, logging every blocked packet on an internet facing firewall i= s > plain daft. > > Saying it doesn=E2=80=99t make it so. > The converse applies to your position. > > > Even the storage requirements would be somewhat onerous, > > Storage is cheap. Damage to reputation caused by being in breach of > regulatory requirements w.r.t log retention is not. > Not that cheap. And at the current point in time, in the UK at least, I know of no statutory requirement to keep such logs. I'd asked before what sort of bandwidth & connections per second the firewalls you/you've worked on tend to handle? > > > and that's before trying to process the data into something meaningful. > > And all to confirm that there's a lot of noise and port scanning going > on. > > Or it's part of a much larger picture which is fed into an SIEM system fo= r > event correlation and consequent alerting. > So, you're also exposing a node in you SEM to a shed load of unnecessary noise. > > Firewalls are not the only security control points > Nope, they're not. They're also are a fairly blunt instrument but must be extremely reliable. From owner-freebsd-pf@FreeBSD.ORG Thu Jul 29 21:50:48 2010 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 630531065677 for ; Thu, 29 Jul 2010 21:50:48 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from mail2.jellyfishnet.co.uk (mail2.jellyfishnet.co.uk [93.91.20.10]) by mx1.freebsd.org (Postfix) with ESMTP id B99DE8FC0A for ; Thu, 29 Jul 2010 21:50:45 +0000 (UTC) Received: from pemexhub01.jellyfishnet.co.uk.local (93.91.20.2) by mail2.jellyfishnet.co.uk (93.91.20.10) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 29 Jul 2010 22:51:29 +0100 Received: from PEMEXMBXVS02.jellyfishnet.co.uk.local ([192.168.65.37]) by pemexhub01.jellyfishnet.co.uk.local ([192.168.65.7]) with mapi; Thu, 29 Jul 2010 22:50:44 +0100 From: Greg Hennessy To: Peter Maxwell Date: Thu, 29 Jul 2010 22:50:43 +0100 Thread-Topic: For better security: always "block all" or "block in all" is enough? Thread-Index: AcsvYmCrB+XLiUjyQCyHNKbo0xjiNAAAJrBQ Message-ID: <9E8D76EC267C9444AC737F649CBBAD902769C51F15@PEMEXMBXVS02.jellyfishnet.co.uk.local> References: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> <9E8D76EC267C9444AC737F649CBBAD902769BF6F5B@PEMEXMBXVS02.jellyfishnet.co.uk.local> <9E8D76EC267C9444AC737F649CBBAD902767E3BF75@PEMEXMBXVS02.jellyfishnet.co.uk.local> <9E8D76EC267C9444AC737F649CBBAD902769C51EE9@PEMEXMBXVS02.jellyfishnet.co.uk.local> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-pf@freebsd.org" Subject: RE: For better security: always "block all" or "block in all" is enough? 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: Thu, 29 Jul 2010 21:50:48 -0000 VGVsbCB5b3Ugd2hhdCBQZXRlciwNCg0KSSBib3cgdG8geW91ciBvYnZpb3VzbHkgc3VwZXJpb3Ig a25vd2xlZGdlIG9uIHRoaXMgYW5kIGFsbCBvdGhlciBtYXR0ZXJzLg0KDQpIZWxsLCB3aGF0IGRv IEkga25vdywgaG93IGNvdWxkIEkgcG9zc2libHkgY29tcGV0ZSB3aXRoIHNvbWVvbmUgd2hvIGhh cyBzcGVudCBhIOKAmHNpZ25pZmljYW50IHByb3BvcnRpb27igJkgb2YgdGhlaXIgY2FyZWVyIHdv cmtpbmcgZm9yIOKAmG1ham9yIElTUOKAmSAoc2ljKS4NCg0KDQpSZWdhcmRzDQoNCkdyZWcNCg0K DQpPbiBhIHNpZGUgbm90ZToNClRoZSBkaW1lbnNpb25zIG9mIG15IHdpbGx5IChzbyB0byBzcGVh aykgYXJlIHJlYWRpbHkgZGV0ZXJtaW5lZCB0aHJvdWdoIGh0dHA6Ly93d3cuZ29vZ2xlLmNvLnVr Lw0KDQoNCg0KRnJvbTogYWxsaWNpZW50MzE0MUBnbWFpbC5jb20gW21haWx0bzphbGxpY2llbnQz MTQxQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIFBldGVyIE1heHdlbGwNClNlbnQ6IDI5IEp1bHkg MjAxMCAxMDoxMCBQTQ0KVG86IEdyZWcgSGVubmVzc3kNCkNjOiBmcmVlYnNkLXBmQGZyZWVic2Qu b3JnDQpTdWJqZWN0OiBSZTogRm9yIGJldHRlciBzZWN1cml0eTogYWx3YXlzICJibG9jayBhbGwi IG9yICJibG9jayBpbiBhbGwiIGlzIGVub3VnaD8NCg0KDQpPbiAyOSBKdWx5IDIwMTAgMjA6MDgs IEdyZWcgSGVubmVzc3kgPEdyZWcuSGVubmVzc3lAbnZpei5uZXQ8bWFpbHRvOkdyZWcuSGVubmVz c3lAbnZpei5uZXQ+PiB3cm90ZToNCg0KDQo+IElmLCBhcyB5b3Ugc2F5LCB0aGVyZSBhcmUgIkdv dmVybmFuY2UsIFJpc2ssIGFuZCBDb21wbGlhbmNlIHJlYXNvbnMiLA0KPiBwZXJoYXBzIHlvdSdk IGxpa2UgdG8gc3BlY2lmeSBvbmUgb3IgdHdvIGZvciBlYWNoIGNhdGVnb3J5Pw0KU3RhcnQgd2l0 aCBhbiBJU01TIGRlcml2ZWQgZnJvbSAyN2ssIGFkZCBhIHNvdXBjb24gb2YgUENJIERTUyByZXF1 aXJlbWVudCAxMCwgQmFzZWwgSUksIHRocm93IGluIFNPWCA0MDQgb3IgYW4gU0FTIDcwIHR5cGUg SUkgYXVkaXQsIHlvdSBnZXQgdGhlIHBpY3R1cmUuDQoNCg0KQW4gSVNNUywgaXMgYSBjb21wYW55 IGRlZmluZWQgZG9jdW1lbnQgc28gd2lsbCBsaWtlbHkgaGF2ZSBkaWZmZXJlbnQgZW50cmllcyBv ciBldmVuIG5vbmUgYXQgYWxsIGZvciB0aGF0IG1hdHRlciBkZXBlbmRpbmcgb24gdGhlIGNvbXBh bnkuICBJbiBhIHByZXZpb3VzIGNvbXBhbnkgSSB3b3JrZWQgZm9yLCB5b3Ugd291bGQgaGF2ZSBq dXN0IHN1cHBvcnRlZCBteSBwb2ludC4NCg0KQW5kIG5pY2UgdHJ5LCB3aGF0IGRvY3VtZW50cyAm IHNlY3Rpb25zIGluIFBDSSBEU1MsIEJhc2VsIElJLCBhbmQgU09YIGFyZSB5b3UgcmVmZXJyaW5n IHRvPw0KDQoNCj4gTG9nZ2luZyBhIGRlZmF1bHQgZGVueSBvbiBhbiBpbnRlcm5hbCBmaXJld2Fs bCwgeWVzIC0gb2sgLSBJIGFncmVlIHdpdGggeW91LCB0aGF0J3MgcHJvYmFibHkgcmVhc29uYWJs ZS4NCk9ubHkgcHJvYmFibHk/IEhvdyBtdWNoICdjb21tZXJjaWFsJyBmaXJld2FsbCB3b3JrIGhh dmUgeW91IGRvbmUgYWdhaW4sIHNlcmlvdXNseSA/DQoNCkFnYWluPyAgSSBkaWRuJ3QgdGVsbCB5 b3UgdG8gYmVnaW4gd2l0aC4gIEFzIGl0IGhhcHBlbnMsIG1vcmUgdGhhbiB0ZW4geWVhcnMsIGEg c2lnbmlmaWNhbnQgcHJvcG9ydGlvbiBvZiB3aGljaCB3YXMgaW4gYSBtYWpvciBJU1AuICBTaW5j ZSB3ZSdyZSBwbGF5aW5nIHdobydzIHdpbGx5IGlzIGJpZ2dlciwgd2hhdCBhYm91dCB5b3Vyc2Vs Zj8NCg0KDQoNCj4gIEhvd2V2ZXIsIGxvZ2dpbmcgZXZlcnkgYmxvY2tlZCBwYWNrZXQgb24gYW4g aW50ZXJuZXQgZmFjaW5nIGZpcmV3YWxsIGlzIHBsYWluIGRhZnQuDQpTYXlpbmcgaXQgZG9lc27i gJl0IG1ha2UgaXQgc28uDQoNClRoZSBjb252ZXJzZSBhcHBsaWVzIHRvIHlvdXIgcG9zaXRpb24u DQoNCg0KDQo+IEV2ZW4gdGhlIHN0b3JhZ2UgcmVxdWlyZW1lbnRzIHdvdWxkIGJlIHNvbWV3aGF0 IG9uZXJvdXMsDQpTdG9yYWdlIGlzIGNoZWFwLiBEYW1hZ2UgdG8gcmVwdXRhdGlvbiBjYXVzZWQg YnkgYmVpbmcgaW4gYnJlYWNoIG9mIHJlZ3VsYXRvcnkgcmVxdWlyZW1lbnRzIHcuci50IGxvZyBy ZXRlbnRpb24gaXMgbm90Lg0KDQpOb3QgdGhhdCBjaGVhcC4gIEFuZCBhdCB0aGUgY3VycmVudCBw b2ludCBpbiB0aW1lLCBpbiB0aGUgVUsgYXQgbGVhc3QsIEkga25vdyBvZiBubyBzdGF0dXRvcnkg cmVxdWlyZW1lbnQgdG8ga2VlcCBzdWNoIGxvZ3MuDQoNCkknZCBhc2tlZCBiZWZvcmUgd2hhdCBz b3J0IG9mIGJhbmR3aWR0aCAmIGNvbm5lY3Rpb25zIHBlciBzZWNvbmQgdGhlIGZpcmV3YWxscyB5 b3UveW91J3ZlIHdvcmtlZCBvbiB0ZW5kIHRvIGhhbmRsZT8NCg0KDQoNCg0KPiBhbmQgdGhhdCdz IGJlZm9yZSB0cnlpbmcgdG8gcHJvY2VzcyB0aGUgZGF0YSBpbnRvIHNvbWV0aGluZyBtZWFuaW5n ZnVsLg0KPiBBbmQgYWxsIHRvIGNvbmZpcm0gdGhhdCB0aGVyZSdzIGEgbG90IG9mIG5vaXNlIGFu ZCBwb3J0IHNjYW5uaW5nIGdvaW5nIG9uLg0KT3IgaXQncyBwYXJ0IG9mIGEgbXVjaCBsYXJnZXIg cGljdHVyZSB3aGljaCBpcyBmZWQgaW50byBhbiBTSUVNIHN5c3RlbSBmb3IgZXZlbnQgY29ycmVs YXRpb24gYW5kIGNvbnNlcXVlbnQgYWxlcnRpbmcuDQoNClNvLCB5b3UncmUgYWxzbyBleHBvc2lu ZyBhIG5vZGUgaW4geW91IFNFTSB0byBhIHNoZWQgbG9hZCBvZiB1bm5lY2Vzc2FyeSBub2lzZS4N Cg0KDQoNCkZpcmV3YWxscyBhcmUgbm90IHRoZSBvbmx5IHNlY3VyaXR5IGNvbnRyb2wgcG9pbnRz DQoNCk5vcGUsIHRoZXkncmUgbm90LiAgVGhleSdyZSBhbHNvIGFyZSBhIGZhaXJseSBibHVudCBp bnN0cnVtZW50IGJ1dCBtdXN0IGJlIGV4dHJlbWVseSByZWxpYWJsZS4NCg0KDQoNCg0K From owner-freebsd-pf@FreeBSD.ORG Thu Jul 29 23:09:16 2010 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 DE6001065674 for ; Thu, 29 Jul 2010 23:09:16 +0000 (UTC) (envelope-from cbuechler@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4EF8FC19 for ; Thu, 29 Jul 2010 23:09:16 +0000 (UTC) Received: by wwc33 with SMTP id 33so740907wwc.31 for ; Thu, 29 Jul 2010 16:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=3jmi4o8sIAMM80iTPSQ5nKIwR8vT7/6bO/QvSJ0F5Dc=; b=pgIN/i2UDC4TD6N/iLvTotmXvNdPJ5VYKTwqAY4qZ7AbAOtrmdMHivyNU9s45crPTA cjD5HZgF9s2NHg4k+5oepoYHhtX1l/oyLV2XRaRm5VBvCgsGv+oO6i5eikLX24iW+ZuP Jv7m+sxGuxaaAkKpw5O3QTVIWAu4boyrn71hg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=YYvvSn9aGoVGTqKQORNqn9khYlIa9fI0s3yf7p1mSYQ3aSnuHXhWBGBCVh+uoadsMH ll5YMR2sZ+IoedcuXzxG63mvZ/QR8B6Ece1dN+rOf4eP8DAG2a2Ezfl8oNYi4u13u48a ZYMZqJqyRw2MIYtG/+SvGAypwGox4BRdnOfBc= Received: by 10.227.128.18 with SMTP id i18mr861750wbs.135.1280444955383; Thu, 29 Jul 2010 16:09:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.156.84 with HTTP; Thu, 29 Jul 2010 16:08:54 -0700 (PDT) In-Reply-To: References: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> <9E8D76EC267C9444AC737F649CBBAD902769BF6F5B@PEMEXMBXVS02.jellyfishnet.co.uk.local> <9E8D76EC267C9444AC737F649CBBAD902767E3BF75@PEMEXMBXVS02.jellyfishnet.co.uk.local> <9E8D76EC267C9444AC737F649CBBAD902769C51EE9@PEMEXMBXVS02.jellyfishnet.co.uk.local> From: Chris Buechler Date: Thu, 29 Jul 2010 19:08:54 -0400 Message-ID: To: Peter Maxwell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Greg Hennessy , "freebsd-pf@freebsd.org" Subject: Re: For better security: always "block all" or "block in all" is enough? 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: Thu, 29 Jul 2010 23:09:16 -0000 On Thu, Jul 29, 2010 at 5:09 PM, Peter Maxwell wrot= e: > > An ISMS, is a company defined document so will likely have different entr= ies > or even none at all for that matter depending on the company. =A0In a pre= vious > company I worked for, you would have just supported my point. > > And nice try, what documents & sections in PCI DSS, Basel II, and SOX are > you referring to? > I'm not going to bother looking up any specifics, but by your comments as a whole it's blatantly obvious you haven't spent any time in a highly regulated environment with internal and external auditors plus federal regulators auditing more on top of that. Or maybe things across the pond are vastly different than they are in the US, but I doubt that. >> Or it's part of a much larger picture which is fed into an SIEM system f= or >> event correlation and consequent alerting. >> > > So, you're also exposing a node in you SEM to a shed load of unnecessary > noise. > Not true in the least. Block logs are probably overvalued as a whole since what you're dropping by definition can't hurt you and the less clueful tend to be more concerned about what they're blocking than what they're passing, but there is value in analysis there. If your hourly/daily average is X log entries and all of a sudden it's drastically higher or lower than normal, there's something going on that should be investigated. What Greg describes is very common (nearly universal aside from small institutions) in highly regulated environments and provides value. The bulk of such organizations I've done work for do the equivalent of adding a 'log' to every single line in your pf.conf (or very close to it), and dump huge amounts of log data to their SIEM. Or use something like NetFlow for passed traffic, and just let the firewall log all blocks only. From owner-freebsd-pf@FreeBSD.ORG Fri Jul 30 00:07:02 2010 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 7DE751065672 for ; Fri, 30 Jul 2010 00:07:02 +0000 (UTC) (envelope-from allicient3141@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id F146A8FC12 for ; Fri, 30 Jul 2010 00:07:01 +0000 (UTC) Received: by bwz12 with SMTP id 12so588790bwz.13 for ; Thu, 29 Jul 2010 17:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=VXI8vYLaOcebrGNQIjrGEffpTBJTkAAQQFg6OLd/hHU=; b=ohih73geny+Rum0zjdz/aaoDasrt6ROrRdZpeVJesT5dd/X8BlMJJsG3ykc37+umTE jmL83KLVau8xx42g5NbhRksj+1eW7GJRX1IoTUPTkm2E4uLgvlfEMX8uslRGie+RBqbU 0XyDCYMmCya7A6N5mMsnCG1Zv94uOlwkoJq+w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Cp9KbPP2pbYhrtz3qxDo1qDPqMOF/PTwmxdzNOyBQDPNFgx6IqS0SBWAH+nvkZ4NYO dk5W0KpFIMMF6vIchL3tsg3uPtqEtmMP4tFP05l7k/7K6ju0fCRvDIoKMlBxsTweXyqv +8OBXeDBY0+C68kfI37MtpXwLzRE4YPrzx2XQ= MIME-Version: 1.0 Received: by 10.204.45.136 with SMTP id e8mr608903bkf.94.1280448420673; Thu, 29 Jul 2010 17:07:00 -0700 (PDT) Sender: allicient3141@gmail.com Received: by 10.204.112.208 with HTTP; Thu, 29 Jul 2010 17:07:00 -0700 (PDT) In-Reply-To: References: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> <9E8D76EC267C9444AC737F649CBBAD902769BF6F5B@PEMEXMBXVS02.jellyfishnet.co.uk.local> <9E8D76EC267C9444AC737F649CBBAD902767E3BF75@PEMEXMBXVS02.jellyfishnet.co.uk.local> <9E8D76EC267C9444AC737F649CBBAD902769C51EE9@PEMEXMBXVS02.jellyfishnet.co.uk.local> Date: Fri, 30 Jul 2010 01:07:00 +0100 X-Google-Sender-Auth: 6s5HCn3MDyfeCBoemXUq8TI76VM Message-ID: From: Peter Maxwell To: Chris Buechler Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-pf@freebsd.org" Subject: Re: For better security: always "block all" or "block in all" is enough? 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: Fri, 30 Jul 2010 00:07:02 -0000 On 30 July 2010 00:08, Chris Buechler wrote: > On Thu, Jul 29, 2010 at 5:09 PM, Peter Maxwell > wrote: > > > > An ISMS, is a company defined document so will likely have different > entries > > or even none at all for that matter depending on the company. In a > previous > > company I worked for, you would have just supported my point. > > > > And nice try, what documents & sections in PCI DSS, Basel II, and SOX are > > you referring to? > > > > I'm not going to bother looking up any specifics, but by your comments > as a whole it's blatantly obvious you haven't spent any time in a > highly regulated environment with internal and external auditors plus > federal regulators auditing more on top of that. Or maybe things > across the pond are vastly different than they are in the US, but I > doubt that. > If you're going to make broad statements about my background or capabilities, it would be massively ignorant not to use specifics. So go on, don't be lazy - if it is blatantly obvious to you, give us the benefit of your wisdom. While you are at it, why don't you furnish us with an example from either statutory legislation, regulatory guidelines or similar which actually states a requirement to log all dropped packets on a firewall. Then show that it is mandatory for a company to include that in the scope of their ISMS and information security policy. There probably is not a direct analogy with a Federal regulator here, the nearest I can think of are CESG certified staff/consultants. > > > >> Or it's part of a much larger picture which is fed into an SIEM system > for > >> event correlation and consequent alerting. > >> > > > > So, you're also exposing a node in you SEM to a shed load of unnecessary > > noise. > > > > Not true in the least. Block logs are probably overvalued as a whole > since what you're dropping by definition can't hurt you and the less > clueful tend to be more concerned about what they're blocking than > what they're passing, but there is value in analysis there. If your > hourly/daily average is X log entries and all of a sudden it's > drastically higher or lower than normal, there's something going on > that should be investigated. If we're taking pf as an example, there are per-rule statistics that will tell you that without the overhead of logging every packet. Then you have a considered choice on whether to enable logging of every dropped packet, or only a subset, say dropped udp packets. > What Greg describes is very common > (nearly universal aside from small institutions) in highly regulated > environments and provides value. The bulk of such organizations I've > done work for do the equivalent of adding a 'log' to every single line > in your pf.conf (or very close to it), and dump huge amounts of log > data to their SIEM. Or use something like NetFlow for passed traffic, > and just let the firewall log all blocks only. > In an organisational context, that may work. There is still the issue of whether it's extra load on the firewall, but put that aside for the moment. A typical organisation will not have that many firewall devices, and typically there won't be massive amounts of data traversing them, so you can probably afford to drop that amount of data into a SEM; of dubious use, but you can do it. When you start looking at a carrier environment managing many, many, more firewall modules, it starts to get a tad silly to dump all blocked packets into a SEM - what do you really expect it to tell you for the much more expensive price tag? From owner-freebsd-pf@FreeBSD.ORG Sat Jul 31 23:48:17 2010 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 194E11065674 for ; Sat, 31 Jul 2010 23:48:17 +0000 (UTC) (envelope-from milu@dat.pl) Received: from jab.dat.pl (dat.pl [80.51.155.34]) by mx1.freebsd.org (Postfix) with ESMTP id 821E78FC1A for ; Sat, 31 Jul 2010 23:48:16 +0000 (UTC) Received: from jab.dat.pl (jsrv.dat.pl [127.0.0.1]) by jab.dat.pl (Postfix) with ESMTP id 33E345C5A for ; Sun, 1 Aug 2010 01:32:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at dat.pl Received: from jab.dat.pl ([127.0.0.1]) by jab.dat.pl (jab.dat.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id k0lfP41CR+Az for ; Sun, 1 Aug 2010 01:32:42 +0200 (CEST) Received: from snifi.localnet (77-253-105-8.adsl.inetia.pl [77.253.105.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jab.dat.pl (Postfix) with ESMTPSA id 1E4DF5C4A for ; Sun, 1 Aug 2010 01:32:42 +0200 (CEST) From: Maciej Milewski To: freebsd-pf@freebsd.org Date: Sun, 1 Aug 2010 01:32:37 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.34-ARCH; KDE/4.4.5; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201008010132.38555.milu@dat.pl> Subject: pf filtering openvpn problem 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: Sat, 31 Jul 2010 23:48:17 -0000 Hi All, I'm trying to setup OpenVPN in non-nat mode and I stopped on something what I don't understand. The setup is rather simple: (internet) -> (nat)->(ovpn gate-10.0.10.4) -> (host-10.0.10.2) | vpn client Routing is set properly on the server otherwise in tcpdump it shouldn't show returning packets from that host. Firewall on host is disabled. Ping from client to host is working fine. The problem is connecting to ssh or http - it's blocked by gate on returning packet. Can someone point me where is the problem? If ping works then I think tcp should work too. The NAT mode in the same setup works correctly but I'd like to go without nating. Is it possible at all? pf rules are following: # pfctl -s rules block drop in log all pass out log on sk0 inet from (sk0) to any flags S/SA keep state pass out log on tun0 inet from (tun0) to any flags S/SA keep state pass in log on sk0 inet proto tcp from any to 10.0.10.4 port = ssh flags S/SA keep state (source-track rule, max-src-conn 15, max-src-conn-rate 5/3, overload flush global, src.track 3) pass in log on sk0 inet proto udp from any to 10.0.10.4 port = 1194 keep state pass log on tun0 inet proto tcp from 10.10.0.0/24 to 10.0.10.2 flags S/SA keep state pass log on tun0 inet proto udp from 10.10.0.0/24 to 10.0.10.2 keep state pass log on tun0 inet proto icmp from 10.10.0.0/24 to 10.0.10.2 keep state pass log on sk0 inet proto tcp from 10.0.10.2 to 10.10.0.0/24 flags S/SA keep state pass log on sk0 inet proto udp from 10.0.10.2 to 10.10.0.0/24 keep state pass log on sk0 inet proto icmp from 10.0.10.2 to 10.10.0.0/24 keep state and the tcpdump output from pflog: # tcpdump -n -e -ttt -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes 00:00:00.000259 rule 7/0(match): pass in on tun0: 10.10.0.8 > 10.0.10.2: ICMP echo request, id 6381, seq 1, length 64 00:00:00.000494 rule 10/0(match): pass in on sk0: 10.0.10.2 > 10.10.0.8: ICMP echo reply, id 6381, seq 1, length 64 00:00:02.392510 rule 5/0(match): pass in on tun0: 10.10.0.8.33259 > 10.0.10.2.22: [|tcp] 00:00:00.000630 rule 0/0(match): block in on sk0: 10.0.10.2.22 > 10.10.0.8.33259: [|tcp] 00:00:02.997354 rule 0/0(match): block in on sk0: 10.0.10.2.22 > 10.10.0.8.33259: [|tcp] 00:00:02.999400 rule 0/0(match): block in on sk0: 10.0.10.2.22 > 10.10.0.8.33259: [|tcp] 00:00:02.999907 rule 0/0(match): block in on sk0: 10.0.10.2.22 > 10.10.0.8.33259: [|tcp] Regards, Maciej