From owner-freebsd-pf@FreeBSD.ORG Mon Sep 14 04:29:54 2009 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 446E71065676 for ; Mon, 14 Sep 2009 04:29:54 +0000 (UTC) (envelope-from gaurav@subisu.net.np) Received: from mx-02.subisu.net.np (mx-02.subisu.net.np [202.63.240.2]) by mx1.freebsd.org (Postfix) with ESMTP id D93DB8FC08 for ; Mon, 14 Sep 2009 04:29:53 +0000 (UTC) Received: from localhost (mx-02.subisu.net.np [127.0.0.1]) by mx-02.subisu.net.np (Postfix) with ESMTP id 3EAF91C015F for ; Mon, 14 Sep 2009 09:51:42 +0545 (NPT) X-Virus-Scanned: amavisd-new at subisu.net.np Received: from mx-02.subisu.net.np ([127.0.0.1]) by localhost (mx-02.subisu.net.np [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeGFukFP9LAp for ; Mon, 14 Sep 2009 09:51:33 +0545 (NPT) Received: from [202.63.244.34] (unknown [202.63.244.34]) by mx-02.subisu.net.np (Postfix) with ESMTP id B8AA71C0153 for ; Mon, 14 Sep 2009 09:51:32 +0545 (NPT) Message-ID: <4AADC15B.5060501@subisu.net.np> Date: Mon, 14 Sep 2009 09:51:51 +0545 From: Gaurav Ghimire User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Packet Filter alerting system. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gaurav@subisu.net.np 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, 14 Sep 2009 04:29:54 -0000 Hi all, Just curious to know if we have something, some alerting system or mechanism that provides the administrator with the daily reports that pf itself or some other tool collects on pf's behalf. That probably reports the admin of: ~ Total connection counts matched on each rulesets. ~ Total number of counts matched on deny rules. ~ IP/Port attack logs and relatives. I would really appreciate if there are any mechanisms, or am provided with any pointers on achieving this. Regards, -- Gaurav Ghimire System Administrator Subisu Cablenet (P.) Ltd. 148 Thirbum Sadak Baluwatar, Kathmandu Nepal T: 00977 1 4429616/17 Ext.: 110 F: 00977 1 4430572 http://www.subisu.net.np (An ISO 9001:2000 Certified Company) From owner-freebsd-pf@FreeBSD.ORG Mon Sep 14 11:07:06 2009 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 0949B1065693 for ; Mon, 14 Sep 2009 11:07:06 +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 E2ABD8FC18 for ; Mon, 14 Sep 2009 11:07:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8EB75QD072433 for ; Mon, 14 Sep 2009 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8EB754r072429 for freebsd-pf@FreeBSD.org; Mon, 14 Sep 2009 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Sep 2009 11:07:05 GMT Message-Id: <200909141107.n8EB754r072429@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, 14 Sep 2009 11:07:06 -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/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 36 problems total. From owner-freebsd-pf@FreeBSD.ORG Tue Sep 15 17:46:07 2009 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 1282C106568D for ; Tue, 15 Sep 2009 17:46:07 +0000 (UTC) (envelope-from mkhitrov@gmail.com) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.211.179]) by mx1.freebsd.org (Postfix) with ESMTP id BE8748FC33 for ; Tue, 15 Sep 2009 17:46:06 +0000 (UTC) Received: by ywh9 with SMTP id 9so5951920ywh.32 for ; Tue, 15 Sep 2009 10:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=IGsp8/cLuS/5Pyg/UG7wlgxZol40XTxdbiQO/gIAPVo=; b=XCp7qyMzFKP6PsOYAe7rxa/1cXeGnb0fIRmB4S6CRysKL/y+eIOY0Rh37eCcgKOZYa IdDaLBdzv6M3hjoPC3hnZ5498K76shoJgtdAj+cTBvMDkwnBUA5K6EZIq51pPgmHRVMa p7yQFaqYYlY31T5HZ3xArRyXqVTIV+S47sM2s= 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=bhN4yIH9ku6zur+uXcDi7VCznefTXuo1KmeYyA/xUcONihDIBayL0fSWRxdlPMvg+l /AtoclXDs0zYcc/+Z8Oj+t156os8Zo55VLTujE/lr2Y3wDxaCUf1uPx7NFxie4rEZUam HTGn/eaTeoKaZrlwrLI97ExkgLz9XxlvdicZo= MIME-Version: 1.0 Received: by 10.91.189.1 with SMTP id r1mr4742064agp.109.1253036763989; Tue, 15 Sep 2009 10:46:03 -0700 (PDT) In-Reply-To: <4A36A051.3040007@FreeBSD.org> References: <4A242035.8010101@FreeBSD.org> <20090615065817.GJ290@greenie.muc.de> <4A36A051.3040007@FreeBSD.org> From: Maxim Khitrov Date: Tue, 15 Sep 2009 13:45:42 -0400 Message-ID: <26ddd1750909151045ia8bc7f1r9abfccb360538c8@mail.gmail.com> To: Doug Barton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kan@freebsd.org, bzeeb-lists@lists.zabbadoz.net, Gert Doering , freebsd-pf@freebsd.org Subject: Re: Moving the pf rc.d scripts to run before netif 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, 15 Sep 2009 17:46:07 -0000 On Mon, Jun 15, 2009 at 3:26 PM, Doug Barton wrote: > Gert Doering wrote: >> Hi Doug, >> >> thanks for taking this up - and sorry for not responding more timely. >> >> I can't answer all the questions but might have a yet-unmentioned idea >> that could solve all this in one go :-) >> >> On Mon, Jun 01, 2009 at 11:38:45AM -0700, Doug Barton wrote: >>> 2. The previous rcorder for the pf script was right after netif (the >>> network coming up) and before routing .... why? Is this related to how >>> pf does its work? The reason I ask this question is that in order to >>> fix the IPv6 rcorder problem in the pr the way that Gert is suggesting >>> the "BEFORE: routing" would have to be removed because our IPv6 >>> startup depends on RA which depends on routing being up. (Side note, >>> in the long term I'd like to revise this so that an IPv6-only host >>> and/or a host with statically assigned IPv6 addresses can easily be >>> configured within rc.d, but that's another thing altogether.) >>> >>> 3. Is the need to be able to use $ext_if after the network is up so >>> overwhelmingly important that it justifies running pf after netif? Or >>> is using ($ext_if) a reasonable solution? >> >> Well - let's turn this one around: since we *have* the functionality in >> pf(4), let's not cripple it by building a framework that makes using thi= s >> functionality effectively impossible. =C2=A0If I understand Bjoern right= , this >> is also a performance issue - ($ext_if) needs a per-packet lookup to >> get the now-current address, while $ext_if reads the address at pf setup >> time. >> >> >> I can see the arguments for having the firewall initialization right at >> the start - to avoid opening an window of opportunity where services are >> "up" but the firewall hasn't yet been loaded. >> >> >> So what about the following approach: >> >> =C2=A0- split the firewall initialization into two halves >> >> =C2=A0- the first half is run before any other networking stuff is confi= gured >> =C2=A0 =C2=A0and basically sets up a "deny everything incoming" filter (= with >> =C2=A0 =C2=A0exceptions for IPv6 RD/ND, of course). >> >> =C2=A0 =C2=A0Optionally this could permit outbound connections (with sta= te), to >> =C2=A0 =C2=A0enable things like bgpd to run. >> >> =C2=A0- after this, run interface configuration, set up routing, ... >> >> =C2=A0- when all this is finished, load the "real" set of firewall rules= , >> =C2=A0 =C2=A0which can now (if so desired) safely use $ext_if > > I already said I support this solution, I'm just waiting for someone > with some real pf knowledge to propose something. > > Doug Hello all, I just ran into this problem of pf start-up order on 7.2. I have a number of nat and rdr rules that allow people on the outside to access some internal servers (web, mail, etc.). To avoid having to specify public and private IPs once in the DNS server, which is on the internal interface, and a second time in the pf configuration, all of these rules use host names. During start-up, the DNS server cannot be reached, so pf.conf is not loaded due to unresolved hostnames. The solution I used is basically as explained by Gert. It works for me, but would be much better if someone could commit a more permanent fix. The idea is to have two separate pf configuration files and rc scripts. One rc script (I called mine pf_init and put it into /usr/local/etc/rc.d/ for now) runs instead of the current /etc/rc.d/pf (before routing is enabled). This script loads /etc/pf.init which contains the following configuration: # pf configuration that is loaded before routing set skip on lo scrub in block in Just a basic filter that has no external dependencies and blocks all incoming traffic. Outgoing traffic, like DNS queries, would be allowed by the default pass rule. The second rc script is a modified version of the current /etc/rc.d/pf. All I did was change two lines: --- /usr/src/etc/rc.d/pf 2009-04-14 23:14:26.000000000 -0400 +++ /etc/rc.d/pf 2009-09-15 13:06:07.000000000 -0400 @@ -7,2 +7,2 @@ -# REQUIRE: FILESYSTEMS netif pflog pfsync -# BEFORE: routing +# REQUIRE: FILESYSTEMS netif pflog pfsync named +# BEFORE: DAEMON ntpdate I added named to the REQUIRE list, which in my case is provided by dnsmasq. This allows the firewall to query ISP and internal DNS servers before the real pf.conf is loaded. I also wanted pf.conf loaded before other network-related scripts like ntpdate. Not sure if there are some other things that need to be included for a more general solution, but this works for me. My pf_init script is at the bottom of this message. Feel free to take any of my work, improve it, and commit to the source tree. You would need to move pf_init_rules variable, which is currently defined in pf_init to /etc/defaults/rc.conf. That would allow people to specify a config to use other than /etc/pf.init. The only thing I wasn't sure about is if there is a better way to disable stop and restart rc commands than to set stop_cmd and restart_cmd to an empty function. We don't want to use pf_init to reload or restart the firewall, since that would replace the correct ruleset with the pre-routing one. - Max /usr/local/etc/rc.d/pf_init: #!/bin/sh # # PROVIDE: pf_init # REQUIRE: FILESYSTEMS netif pflog pfsync # BEFORE: routing # KEYWORD: nojail . /etc/rc.subr name=3D"pf_init" rcvar=3D`set_rcvar` load_rc_config "pf" start_cmd=3D"" stop_cmd=3D"pf_pass" restart_cmd=3D"pf_pass" pf_init_rules=3D"/etc/pf.init" required_files=3D"$pf_init_rules" required_modules=3D"pf" pf_start() { echo "Enabling pf (init)." $pf_program -F all > /dev/null 2>&1 $pf_program -f "$pf_init_rules" $pf_flags if ! $pf_program -s info | grep -q "Enabled" ; then $pf_program -e fi } pf_pass() { } run_rc_command "$1" From owner-freebsd-pf@FreeBSD.ORG Tue Sep 15 19:05:19 2009 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 8037F106566C for ; Tue, 15 Sep 2009 19:05:19 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (uffner.com [66.208.243.25]) by mx1.freebsd.org (Postfix) with ESMTP id 284448FC1A for ; Tue, 15 Sep 2009 19:05:18 +0000 (UTC) Received: from xiombarg.uffner.com (static-71-162-143-94.phlapa.fios.verizon.net [71.162.143.94]) (authenticated bits=0) by eris.uffner.com (8.14.3/8.14.3) with ESMTP id n8FIs5sh082856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Sep 2009 14:54:19 -0400 (EDT) (envelope-from tom@uffner.com) Message-ID: <4AAFE24A.2040602@uffner.com> Date: Tue, 15 Sep 2009 14:51:54 -0400 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.23) Gecko/20090907 SeaMonkey/1.1.18 MIME-Version: 1.0 To: gaurav@subisu.net.np References: <4AADC15B.5060501@subisu.net.np> In-Reply-To: <4AADC15B.5060501@subisu.net.np> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: Packet Filter alerting system. 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, 15 Sep 2009 19:05:19 -0000 Gaurav Ghimire wrote: > Just curious to know if we have something, some alerting system or mechanism that provides the administrator with the daily reports that pf itself or some other > tool collects on pf's behalf. > > That probably reports the admin of: > ~ Total connection counts matched on each rulesets. > ~ Total number of counts matched on deny rules. /etc/periodic/security/520.pfdenied it should be enabled by default if you haven't done anything unnatural to the /etc/periodic system > ~ IP/Port attack logs and relatives. only if you specify "log" in one or more of your pf rules, in which case you will find it in /var/log/pflog, /var/log/pflog.?.bz2, and /var/log/pf.{today,yesterday} tom From owner-freebsd-pf@FreeBSD.ORG Wed Sep 16 16:28:35 2009 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 52312106568D for ; Wed, 16 Sep 2009 16:28:35 +0000 (UTC) (envelope-from steinex@nognu.de) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id C63E58FC15 for ; Wed, 16 Sep 2009 16:28:34 +0000 (UTC) Received: by ewy4 with SMTP id 4so5223192ewy.36 for ; Wed, 16 Sep 2009 09:28:33 -0700 (PDT) Received: by 10.210.3.14 with SMTP id 14mr2554450ebc.61.1253116520091; Wed, 16 Sep 2009 08:55:20 -0700 (PDT) Received: from haydn.nognu.de (haydn.nognu.de [81.169.170.112]) by mx.google.com with ESMTPS id 5sm256840eyh.11.2009.09.16.08.55.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 16 Sep 2009 08:55:19 -0700 (PDT) Date: Wed, 16 Sep 2009 17:55:17 +0200 From: Frank Steinborn To: freebsd-pf@freebsd.org Message-ID: <20090916155517.GA78914@haydn.nognu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: NAT traffic not seen on an interface 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, 16 Sep 2009 16:28:35 -0000 Hi, I have configured seven jails on the lo1 interface, NAT is configured via pf, and all works fine. Now i configured an eight jail where i need to measure the traffic going through this special jail, so I configured it's IP on a dedicated lo2 interface. However, after some testing (eg. watching 'systat if' and generating traffic on that jail) I don't see the traffic at all. There actually is some traffic, but it's definitely not all. What am I missing? Is that approach reasonable at all? Thanks! From owner-freebsd-pf@FreeBSD.ORG Wed Sep 16 20:41:58 2009 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 D7F76106568B for ; Wed, 16 Sep 2009 20:41:58 +0000 (UTC) (envelope-from admin@anes.su) Received: from out.cm.hc.ru (out.cm.hc.ru [89.111.177.10]) by mx1.freebsd.org (Postfix) with ESMTP id 918028FC0A for ; Wed, 16 Sep 2009 20:41:57 +0000 (UTC) Received: from be.static.corbina.ru ([78.107.248.157]) by mx.cm.hc.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mo10K-000Elq-JD for freebsd-pf@freebsd.org; Thu, 17 Sep 2009 00:21:36 +0400 Message-ID: <4AB148CA.9050901@anes.su> Date: Thu, 17 Sep 2009 00:21:30 +0400 From: Anes Muhametov User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-HCMAIL-Auth: admin@anes.su X-ClamAV-Status: malware not found X-HCMAIL-Node: 8 X-SpamTest-Envelope-From: admin@anes.su X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 9686 [Sep 16 2009] X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-SPF: unknown X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Subject: Relayd l3 redirect send/expect check 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, 16 Sep 2009 20:41:58 -0000 It seems like the problem is still not resolved. Situation the same on freebsd 7.2. Is freebsd-pf correct for this problem? From owner-freebsd-pf@FreeBSD.ORG Thu Sep 17 19:30:27 2009 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 1E0221065672 for ; Thu, 17 Sep 2009 19:30:27 +0000 (UTC) (envelope-from tim@hoganzoo.com) Received: from wolf.hoganzoo.com (wolf.hoganzoo.com [66.37.133.25]) by mx1.freebsd.org (Postfix) with ESMTP id C32A08FC19 for ; Thu, 17 Sep 2009 19:30:26 +0000 (UTC) Received: from [127.0.0.1] (unknown [10.1.1.1]) by wolf.hoganzoo.com (Postfix) with ESMTP id BAEA47E8C5; Thu, 17 Sep 2009 13:13:54 -0600 (MDT) Message-ID: <4AB28A7A.2060206@hoganzoo.com> Date: Thu, 17 Sep 2009 13:14:02 -0600 From: Tim Hogan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Tom Uffner References: <4AADC15B.5060501@subisu.net.np> <4AAFE24A.2040602@uffner.com> In-Reply-To: <4AAFE24A.2040602@uffner.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050806040209080301030403" Cc: freebsd-pf@freebsd.org Subject: Re: Packet Filter alerting system. 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, 17 Sep 2009 19:30:27 -0000 This is a cryptographically signed message in MIME format. --------------ms050806040209080301030403 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Tom Uffner wrote: > Gaurav Ghimire wrote: >> Just curious to know if we have something, some alerting system or >> mechanism that provides the administrator with the daily reports that >> pf itself or some other >> tool collects on pf's behalf. >> >> That probably reports the admin of: >> ~ Total connection counts matched on each rulesets. >> ~ Total number of counts matched on deny rules. > > /etc/periodic/security/520.pfdenied > > it should be enabled by default if you haven't done anything unnatural to > the /etc/periodic system > > > ~ IP/Port attack logs and relatives. > > only if you specify "log" in one or more of your pf rules, in which > case you will find it in /var/log/pflog, /var/log/pflog.?.bz2, and > /var/log/pf.{today,yesterday} > > tom > Not sure if this will help but I have added the following line to /etc/periodic/security/520.pfdenied pfctl -sr -v | grep -v "Inserted:" | awk '/^[apb]/ { printf "\n%s\n", $0 } $0 !~ /^[apb]/' | mailx -s "Daily PF Hit Report" root This will produce something like the following for each rule that you have; pass in quick on vr0 inet proto udp from 10.0.0.1 to 10.0.0.2 port = syslog keep state [ Evaluations: 560355 Packets: 46 Bytes: 4058 States: 0 ] The down side is that the numbers will increment from the last time PF was restarted, not from the previous day. Regards, Tim --------------ms050806040209080301030403 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK6jCC BXEwggNZoAMCAQICAwcTezANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA2 MjkxNDU5MTlaFw0wOTEyMjYxNDU5MTlaMGMxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEf MB0GCSqGSIb3DQEJARYQdGltQGhvZ2Fuem9vLmNvbTEmMCQGCSqGSIb3DQEJARYXdGltQHJl ZmxlY3RpdmVzaWdodC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPSBR0 GkAbcXOe35zauH3SM+c8EKinb1+CrwpRubJW30AQWajUkJoEvrqxjm81ZhJkdtFggwvwbYeQ lUIkQh5r0GDrkYQ+M4FyToQ/EhofWh25M10H7IPaYeHRvpvpOXUlDcVLUIWsfbDWQ7R7CQB+ lpN4M9Hq1QeLMf1qNZdmwInSg5MYJ3kwkE+X0VTfT4wMzWamdi1HlzUUmYXygO+gI4maBG+A 1n0+cKecL1ipR5jxWFacIRc9xyFd4fskQLMquKgdgBrf/VL+27dhWgoFA9rnAL2mY+0Y/E6h vlZJbt1iEWLomkFGQeik3WKsK6sQatQ7dP5dzU8QeHD2evrJAgMBAAGjggEWMIIBEjAMBgNV HRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUg Zm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3 BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIE ATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcw NAYDVR0RBC0wK4EQdGltQGhvZ2Fuem9vLmNvbYEXdGltQHJlZmxlY3RpdmVzaWdodC5jb20w DQYJKoZIhvcNAQEFBQADggIBADMtUgMi0xH+uzjmjogAiOeUO9+XYBV0vMxdTw+IiWVTViy4 vu6yDYRQTd/oSHV1045B/v8UodS2mTX4bL8djjMiahQpitXuDnBGvcix0DTt47acD2AYEH5k BhnAYO/sNZ90stexCfsSEziPDbxjrcAN4duZfOyF8HKl85fTk/4Cnxtma8vNX9jyMSodqX7T IIygSFhnhLBpnOU1yidpSaZoLdEcsWwkIeGxE0cp9lzex9vSBzsMWqeJg20we47Ibdt+O38y SRIZhrkkTLihw8lUWXZwq6M1uhCSuaib0uq+TvZF+Ewpi9M6B8S88CCc81bJ611L529MEt9U uSZmXE+PCYaCQ83CoGB/1w8iLqmWBlW2JD+0YnwK7e0YYa00/pjfwT13O/Uh+PLXuLCYB8QX aZbJavc4H4258mdjG5Zsnv4BtVWAaRYhJqQBfiWJup0oW6JUchgJ6Hylz3LEl6zz+q0guLh8 Ta1OVAMd0Ijk/B3fodOkYvrjgPGTAwpZ3xFgLlH7F4Mwu1Bna34UqPGjKznvry9AUIlEPYeH givVXAG1eVQwrPyREqx+JnmGcD/FFr4iKvJMu0b8heNMmfq+AC1JVkhnifKLdFrrD6xwYnF4 Mw1w1smNuBQj7hE0gOHr5kDySUmFoBoJ6CO9x+lUuAgdbTc/BzEV/QriCXEvMIIFcTCCA1mg AwIBAgIDBxN7MA0GCSqGSIb3DQEBBQUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA5MDYyOTE0NTkx OVoXDTA5MTIyNjE0NTkxOVowYzEYMBYGA1UEAxMPQ0FjZXJ0IFdvVCBVc2VyMR8wHQYJKoZI hvcNAQkBFhB0aW1AaG9nYW56b28uY29tMSYwJAYJKoZIhvcNAQkBFhd0aW1AcmVmbGVjdGl2 ZXNpZ2h0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM9IFHQaQBtxc57f nNq4fdIz5zwQqKdvX4KvClG5slbfQBBZqNSQmgS+urGObzVmEmR20WCDC/Bth5CVQiRCHmvQ YOuRhD4zgXJOhD8SGh9aHbkzXQfsg9ph4dG+m+k5dSUNxUtQhax9sNZDtHsJAH6Wk3gz0erV B4sx/Wo1l2bAidKDkxgneTCQT5fRVN9PjAzNZqZ2LUeXNRSZhfKA76AjiZoEb4DWfT5wp5wv WKlHmPFYVpwhFz3HIV3h+yRAsyq4qB2AGt/9Uv7bt2FaCgUD2ucAvaZj7Rj8TqG+Vklu3WIR YuiaQUZB6KTdYqwrqxBq1Dt0/l3NTxB4cPZ6+skCAwEAAaOCARYwggESMAwGA1UdEwEB/wQC MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUF BwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsG AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA0BgNVHREE LTArgRB0aW1AaG9nYW56b28uY29tgRd0aW1AcmVmbGVjdGl2ZXNpZ2h0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAgEAMy1SAyLTEf67OOaOiACI55Q735dgFXS8zF1PD4iJZVNWLLi+7rINhFBN 3+hIdXXTjkH+/xSh1LaZNfhsvx2OMyJqFCmK1e4OcEa9yLHQNO3jtpwPYBgQfmQGGcBg7+w1 n3Sy17EJ+xITOI8NvGOtwA3h25l87IXwcqXzl9OT/gKfG2Zry81f2PIxKh2pftMgjKBIWGeE sGmc5TXKJ2lJpmgt0RyxbCQh4bETRyn2XN7H29IHOwxap4mDbTB7jsht2347fzJJEhmGuSRM uKHDyVRZdnCrozW6EJK5qJvS6r5O9kX4TCmL0zoHxLzwIJzzVsnrXUvnb0wS31S5JmZcT48J hoJDzcKgYH/XDyIuqZYGVbYkP7RifArt7RhhrTT+mN/BPXc79SH48te4sJgHxBdplslq9zgf jbnyZ2Mblmye/gG1VYBpFiEmpAF+JYm6nShbolRyGAnofKXPcsSXrPP6rSC4uHxNrU5UAx3Q iOT8Hd+h06Ri+uOA8ZMDClnfEWAuUfsXgzC7UGdrfhSo8aMrOe+vL0BQiUQ9h4eCK9VcAbV5 VDCs/JESrH4meYZwP8UWviIq8ky7RvyF40yZ+r4ALUlWSGeJ8ot0WusPrHBicXgzDXDWyY24 FCPuETSA4evmQPJJSYWgGgnoI73H6VS4CB1tNz8HMRX9CuIJcS8xggOUMIIDkAIBATCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBv cnRAY2FjZXJ0Lm9yZwIDBxN7MAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDkxNzE5MTQwMlowIwYJKoZIhvcNAQkEMRYEFO+Z IBi1R9Tk4QS2P0LSl5sF72scMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMHE3swgZMGCyqG SIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMHE3swDQYJKoZIhvcNAQEBBQAEggEA bwNj0YSnGfrZv1FKVTLjV0ncucrr/Hxp6ah6698qrTyIbl+n1LkJdVnvdNqN5dDMucRtj4/n FMT1cUgwY3HKa8nwSwJR7fKTEB5HkH7NK1XlfT25jzLQTN/5/i4cTNP0byWausiNJPfDnAcF kCyD3Y3/LYdeJpkEjpk9WSIEEJYR/sp/2MQGzPH5LgHoL3FDj6+iVfS/4HHHNBT5BQmFWUY5 KJXm1dUFUg1dNfpOsHF3+oXkLMHRJs9RxZaSiNvbDOdLcDZll4/znsz4XhRhcaYmG5xhiB/Y PXItaXEjyVSr98kWi0horMadb1y/w7sf6x1Jzz7mKeFRXwiiyWyY5gAAAAAAAA== --------------ms050806040209080301030403-- From owner-freebsd-pf@FreeBSD.ORG Fri Sep 18 05:10:38 2009 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 91E48106566B for ; Fri, 18 Sep 2009 05:10:38 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: from mail-qy0-f188.google.com (mail-qy0-f188.google.com [209.85.221.188]) by mx1.freebsd.org (Postfix) with ESMTP id 1EBE58FC17 for ; Fri, 18 Sep 2009 05:10:37 +0000 (UTC) Received: by qyk26 with SMTP id 26so1023550qyk.7 for ; Thu, 17 Sep 2009 22:10:36 -0700 (PDT) Received: by 10.224.16.71 with SMTP id n7mr1060269qaa.162.1253250636570; Thu, 17 Sep 2009 22:10:36 -0700 (PDT) Received: from kevin (not.enough.unixsluts.com [76.10.166.187]) by mx.google.com with ESMTPS id 8sm1287719qwj.51.2009.09.17.22.10.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Sep 2009 22:10:34 -0700 (PDT) From: "Kevin" To: "'Tom Uffner'" , References: <4AADC15B.5060501@subisu.net.np> <4AAFE24A.2040602@uffner.com> In-Reply-To: <4AAFE24A.2040602@uffner.com> Date: Fri, 18 Sep 2009 01:10:08 -0400 Message-ID: <020001ca381e$4b8bade0$e2a309a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Aco2N4JCmiqdPo1ASU66p+Jb9cxIaQB5oxNA Content-Language: en-us Cc: freebsd-pf@freebsd.org Subject: RE: Packet Filter alerting system. 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, 18 Sep 2009 05:10:38 -0000 > Gaurav Ghimire wrote: > > Just curious to know if we have something, some alerting system or > mechanism that provides the administrator with the daily reports that > pf itself or some other > > tool collects on pf's behalf. > > > > That probably reports the admin of: > > ~ Total connection counts matched on each rulesets. > > ~ Total number of counts matched on deny rules. > > /etc/periodic/security/520.pfdenied > > it should be enabled by default if you haven't done anything unnatural > to > the /etc/periodic system > > > ~ IP/Port attack logs and relatives. > > only if you specify "log" in one or more of your pf rules, in which > case you will find it in /var/log/pflog, /var/log/pflog.?.bz2, and > /var/log/pf.{today,yesterday} > > tom I wrote a script that compiles a daily report on any pf table based threshold breaches -- something that could be modified to produce many different types of daily pf based reports : http://blog.stardothosting.com/2009/08/12/freebsd-pf-packet-filter-shell-scr ipt-to-report-on-hacking-attempts/ Something to look at anyways.