From owner-freebsd-pf@FreeBSD.ORG Fri Apr 12 15:30:56 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 256A6B8 for ; Fri, 12 Apr 2013 15:30:56 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by mx1.freebsd.org (Postfix) with ESMTP id AFF15DFD for ; Fri, 12 Apr 2013 15:30:55 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id jc3so1439268bkc.29 for ; Fri, 12 Apr 2013 08:30:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:date:user-agent:mime-version :content-type:content-transfer-encoding:message-id :x-gm-message-state; bh=YhO0oQYiuC87cw+Tg0gySTGel1bfFH7+0nIq6OtE5K0=; b=cAAgQmWqSbd+GiEUhPK8oM2c39IDiRj7vvvXeFJyiMMDDDdJP1gswWGfkNPMZTYgCw Kf0wHcmydiymInoECBMbyekzBH2chCq2Zc1S/GQm7aUPpFv+Ff/LGAXLQz1PVqJzKDWY ciW1eqOARF0IHGM4cMwZL12BxlcsWLhsavfKM0Ql+lXndwoE00dumpzfjl4GIJ/oY84Z PWbiFLPNZ7hutPaQRc7+csf2i+4Epy9dLAbaCeE5CXhb3+JrpWHz9CGy6cD6jf0ljLgv iDU+8dyfIF+lxLHlClipqq/t2q7YTGn89ZdEmsrCHI0sAIeXd/a/rVMlZel5uSoxfSR+ zHPg== X-Received: by 10.205.96.69 with SMTP id cf5mr4268564bkc.132.1365780653462; Fri, 12 Apr 2013 08:30:53 -0700 (PDT) Received: from zvezda.localnet ([212.48.107.10]) by mx.google.com with ESMTPS id 2sm4104498bki.19.2013.04.12.08.30.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Apr 2013 08:30:52 -0700 (PDT) From: Kajetan Staszkiewicz To: freebsd-pf@freebsd.org Subject: issues with counting packets dropped by accepting rules Date: Fri, 12 Apr 2013 17:30:51 +0200 User-Agent: KMail/1.13.5 (Linux/3.6.6-vegeta.1; KDE/4.4.5; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201304121730.51925.vegeta@tuxpowered.net> X-Gm-Message-State: ALoCoQnFQEvgpfMOaU765RBQeUiQaQ8kdxKQZJ2VXQms4BchD35oje79G4BSkqt/lQZn4tv2K8WK X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Apr 2013 15:30:56 -0000 I'd like to point out some things I find unclear when packets traveling through pf are counted. Currently per-rule counting is performed only for packets that are accepted by any rule or any packets matched by a droping rule. Counting on per-interface basis is perfomed properly. There are some possibilities for a packet do be dropped by an accepting rule: 1. SYN/SYN+ACK/ACK packets going through synproxy are dropped with PF_SYNPROXY_DROP action. Therefore a storm of SYNs hitting a synproxy rule will not be visible on per-rule (/label) statistics. SYN+ACKs sent back by this rule to client will also not be visible at all. 2. Creation of a state or a src-node might fail due to memory or per-rule state limits. The packet is told to "not match this rule" according to manual. This is not fully true, have a look on: http://www.freebsd.org/cgi/query-pr.cgi?pr=177808 With the fix or without (so forwarded or not), if state limit is hit, the packet is not counted. I'm now thinking how this should be really fixed. Original code is: 7093 if (action == PF_PASS || r->action == PF_DROP) An easy fix that addesses both aforementioned problems is: 7093 if ( action == PF_PASS || /* Matched and passed by a rule. */ 7094 action == PF_LIMIT_DROP || /* Dropped by a rule because of internal errors. */ 7095 action == PF_SYNPROXY_DROP || /* Dropped due to synproxy. */ 7096 r->action == PF_DROP /* Matched by a drop rule. */ 7097 ) { PF_LIMIT_DROP is my addition, returned by pf_create_state in case of failure instead of PF_DROP. It could also be (action==PF_DROP && r->action==PF_PASS). Are there any other combinations of action and r->action possible? Maybe the aforementioned test is not necessary at all? Grepping the code shows that other possibilities in "enum { PF_PASS,..." are used for rule action, not result action. I assume that for synproxy rules it would also make sense to count packets sent out by synproxy, after original incoming packet was dropped. -- | pozdrawiam / greetings | powered by Debian, CentOS and FreeBSD | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------'