From owner-freebsd-pf@FreeBSD.ORG Sun Dec 31 06:04:14 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34C9016A403 for ; Sun, 31 Dec 2006 06:04:14 +0000 (UTC) (envelope-from myninku@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id C662213C458 for ; Sun, 31 Dec 2006 06:04:13 +0000 (UTC) (envelope-from myninku@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so6047663nfc for ; Sat, 30 Dec 2006 22:04:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=cWghDapcPvkeT+wpLcO1wXKgygiGATrfYBaPWBG1w3vSyiJGg19xSkVO80RXiYjdpI+GOgcaxfzERiQgVSQ+0ts1++/tgI8N8q0FjyoWZksZjMRa+3UELspWesvYsoTCIv+0Pc2BiBM7v3RAoGy124EaLNmxynCkaA+gFhP3Fm4= Received: by 10.49.93.13 with SMTP id v13mr2084796nfl.1167543566472; Sat, 30 Dec 2006 21:39:26 -0800 (PST) Received: by 10.48.206.9 with HTTP; Sat, 30 Dec 2006 21:39:26 -0800 (PST) Message-ID: Date: Sun, 31 Dec 2006 05:39:26 +0000 From: sukaca To: freebsd-pf@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Rules must be in order 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: Sun, 31 Dec 2006 06:04:14 -0000 dear all i just configure pf+altq and got error masssage this my config ext_if="lnc0" # replace with actual external interface name i.e., dc0 int_if="lnc0" # replace with actual internal interface name i.e., dc1 internal_net1="10.10.1.1/24" internal_net2="10.10.2.1/24" altq on lnc0 cbq bandwidth 128Kb queue { internal_net1, internal_net2 } queue internal_net2 bandwidth 64Kb cbq(default borrow) queue internal_net1 bandwidth 64Kb cbq(red borrow) pass out on lnc0 from any to any queue (internal_net1, internal_net2) pass in on lnc0 from any to any queue (internal_net1, internal_net2) nat on lnc0 from 10.10.1.0/24 to any -> 124.81.224.194 nat on lnc0 from 10.10.2.0/24 to any -> 124.81.224.194 the error is pfctl -f /etc/pf.conf /etc/pf.conf:13: Rules must be in order: options, normalization, queueing, translation, filtering /etc/pf.conf:14: Rules must be in order: options, normalization, queueing, translation, filtering pfctl: Syntax error in config file: pf rules not loaded where is my wrong and what should i do thanks and regard vicky From owner-freebsd-pf@FreeBSD.ORG Sun Dec 31 07:43:22 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E12C16A403 for ; Sun, 31 Dec 2006 07:43:22 +0000 (UTC) (envelope-from huzeyfe.onal@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 9D77B13C468 for ; Sun, 31 Dec 2006 07:43:21 +0000 (UTC) (envelope-from huzeyfe.onal@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so6067327nfc for ; Sat, 30 Dec 2006 23:43:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XJHezD6th54C/SW66j02rRn3TtfKjHhLo/vMOwkD+UPQ5IvzohwX8Gbdr8cLpKLfOvN7PxLoDOOYVO5RPuwyTnEKbvMSeig1Lt3exkDS+obDSPq5zewdyuYoedkdQaclGe7oozQ/CaqcT47NcCll+5R/naDz0LQmaqqSauYi5qA= Received: by 10.48.202.11 with SMTP id z11mr21012555nff.1167549398714; Sat, 30 Dec 2006 23:16:38 -0800 (PST) Received: by 10.49.9.19 with HTTP; Sat, 30 Dec 2006 23:16:38 -0800 (PST) Message-ID: Date: Sun, 31 Dec 2006 09:16:38 +0200 From: "Huzeyfe Onal" To: sukaca In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Cc: freebsd-pf@freebsd.org Subject: Re: Rules must be in order 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: Sun, 31 Dec 2006 07:43:22 -0000 Hi, error says what sohuld you do: "/etc/pf.conf:13: Rules must be in order: options, normalization, queueing,= " Your pf rules order is wrong. The order should be like...Queue->NAT->Filtering... new pf.conf ; --- ext_if=3D"lnc0" # replace with actual external interface name i.e., dc0 int_if=3D"lnc0" # replace with actual internal interface name i.e., dc1 internal_net1=3D"10.10.1.1/24" internal_net2=3D"10.10.2.1/24" altq on lnc0 cbq bandwidth 128Kb queue { internal_net1, internal_net2 } queue internal_net2 bandwidth 64Kb cbq(default borrow) queue internal_net1 bandwidth 64Kb cbq(red borrow) nat on lnc0 from 10.10.1.0/24 to any -> 124.81.224.194 nat on lnc0 from 10.10.2.0/24 to any -> 124.81.224.194 pass out on lnc0 from any to any queue (internal_net1, internal_net2) pass in on lnc0 from any to any queue (internal_net1, internal_net2) ---- On 12/31/06, sukaca wrote: > dear all > > i just configure pf+altq > and got error masssage > > this my config > > ext_if=3D"lnc0" # replace with actual external interface name i.e., dc0 > int_if=3D"lnc0" # replace with actual internal interface name i.e., dc1 > internal_net1=3D"10.10.1.1/24" > internal_net2=3D"10.10.2.1/24" > > altq on lnc0 cbq bandwidth 128Kb queue { internal_net1, internal_net2 } > queue internal_net2 bandwidth 64Kb cbq(default borrow) > queue internal_net1 bandwidth 64Kb cbq(red borrow) > > pass out on lnc0 from any to any queue (internal_net1, internal_net2) > pass in on lnc0 from any to any queue (internal_net1, internal_net2) > > nat on lnc0 from 10.10.1.0/24 to any -> 124.81.224.194 > nat on lnc0 from 10.10.2.0/24 to any -> 124.81.224.194 > > the error is > > pfctl -f /etc/pf.conf > /etc/pf.conf:13: Rules must be in order: options, normalization, queueing= , > translation, filtering > /etc/pf.conf:14: Rules must be in order: options, normalization, queueing= , > translation, filtering > pfctl: Syntax error in config file: pf rules not loaded > > where is my wrong > and what should i do > > thanks and regard > > vicky > _______________________________________________ > 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" > --=20 Huzeyfe =D6NAL EnderUnix Core Team Member huzeyfe@enderunix.org http://www.enderunix.org/huzeyfe +90 555 255 4593 Ag guvenligi listesine uye oldunuz mu? http://www.huzeyfe.net/netsec.html --- From owner-freebsd-pf@FreeBSD.ORG Sun Dec 31 08:45:02 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5379B16A407 for ; Sun, 31 Dec 2006 08:45:02 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id D04DA13C45A for ; Sun, 31 Dec 2006 08:45:01 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 8798B7BFCCF; Sun, 31 Dec 2006 09:21:02 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id J3UOzm3wZWz1; Sun, 31 Dec 2006 09:21:02 +0100 (CET) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 1520D7BFCC9; Sun, 31 Dec 2006 09:21:01 +0100 (CET) Date: Sun, 31 Dec 2006 09:21:01 +0100 From: Gergely CZUCZY To: sukaca Message-ID: <20061231082101.GA42160@harmless.hu> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-pf@freebsd.org Subject: Re: Rules must be in order 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: Sun, 31 Dec 2006 08:45:02 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 31, 2006 at 05:39:26AM +0000, sukaca wrote: > dear all >=20 > i just configure pf+altq > and got error masssage >=20 > this my config >=20 > ext_if=3D"lnc0" # replace with actual external interface name i.e., dc0 > int_if=3D"lnc0" # replace with actual internal interface name i.e., dc1 > internal_net1=3D"10.10.1.1/24" > internal_net2=3D"10.10.2.1/24" >=20 > altq on lnc0 cbq bandwidth 128Kb queue { internal_net1, internal_net2 } > queue internal_net2 bandwidth 64Kb cbq(default borrow) > queue internal_net1 bandwidth 64Kb cbq(red borrow) >=20 > pass out on lnc0 from any to any queue (internal_net1, internal_net2) > pass in on lnc0 from any to any queue (internal_net1, internal_net2) >=20 > nat on lnc0 from 10.10.1.0/24 to any -> 124.81.224.194 > nat on lnc0 from 10.10.2.0/24 to any -> 124.81.224.194 >=20 > the error is >=20 > pfctl -f /etc/pf.conf > /etc/pf.conf:13: Rules must be in order: options, normalization, queueing, > translation, filtering > /etc/pf.conf:14: Rules must be in order: options, normalization, queueing, > translation, filtering > pfctl: Syntax error in config file: pf rules not loaded >=20 > where is my wrong > and what should i do you should read the docmentation. start at http://www.openbsd.org/faq/pf/, http://www.freebsd.org/handbook/ and pf.conf(5). please read the documentation before asking such questions. >=20 > thanks and regard >=20 > vicky > _______________________________________________ > 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" >=20 Bye, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owG1VUFrJEUUjru6Cy17yD94xEtCunu6eyYh05Lsxk1YREVwAx5EQnX365naVFd1 qqozOxE9eVDwIF48iHjwIuiCiCcR/Af+Bw/iZb2IP8BXPdOZzLquitg0dFe99773 3vfqvfrwxtWVK6s/fv3tG5sffPTJUw+un2V+1VgrR0HF9BmXQRxFcTBI4u2IfoOt 4U6URNvDPmKcD1l5+LH+9baSFqUNjqY1pmDxvu3VgnH5PORjpg3a3caWwY7X6R1w UyvDLVcyBS4Fl3ghO9JMmhJ1cChzVXA5SuG0URaLoNZcWpYJ9LxXJdxtpA8HmEM/ 9iGJom1gFqKttD9Mk+39V2AzoscH05ywnMFEE0Tq7UGBTAMTwtvbTSJac7jXGAu5 kiUfNRqhLjeZsKckYrKAkbKAWisNFTPGsBF2hnbMDVTTuWW3S6kf83K3f7AmZB6t AcBzoJHIyBEm3I6B5bZhwumhlvRDKaEunViyCoGHGPpQ5G1o8p9htRBPwIpnWK3O sUQbO8g4Ct0bxr1ksPaIQrJQSDqFWXqOGVASXECQZ6eQEUkTXlAwcbLzUgZUK2wQ 3lp26C/Dw9sENVNc3l+gbQ8IjBysF1iyRljIFFVhsvFYw/hxhhqLhdEs+ppKCKqx FxmUWlVU5ilY1X668NefFP1Gh8Ql/GekWWCSPRJTV52IyO8ggz3ieBDuxGFCn3g4 +GvD5O8MuyOM88PNzQVHZW4FBCX00Oa9ugzd+ab9y8s07qfwWiOQGsA1T+bKAUoX qFNQtWtr44NUumKCnzO39md8UDv7zrHrcTEXlFwQJyT5k5fB/+SlzTGFu1MaJ/c7 BuS8k50mDbG6BN36ljQBhGIFFh1FkzHSnJh1P82VFtLNismYqmHGqhEFjZVCeVPV dGuNrGj5LlRe0Zhrowo9Y5m2bnCNra3TXm8ymYSqRpmZIlR61CvZKdHR8y/LS43Y ycfkN1PqpOe5AObErW9thJ5XC2QGlxw3F56JzFJREsycECU0JPOxo860pIaL88Hk iWlz0zhi+oKBM56fTOl7/O8espgHH9TlrUt50HDlwgUiuLGkNc/WrcxSvk6vYrKV cFmq3gKPzI4UNNI0mck1z5BmP1LkrgOcmeuGtYV6cEnzcijzUee9MEXf8+6gHqGY wu3zJj+feg7HqhRGs+0wb7dv0R1X0VEx4bjxvCBw9q8jSk6nxxKnIdyhRWNoaZQ4 oytGK7rFKuMIpuprbjD03rt59ZkVd5l2V/HqlR9+X/nsnc9ffPPLb/b3v3r56S+u 2d8eHj549nzl09Xv4N7P7//kDXJ4+O7R96MbB79c+wM= =inyn -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-pf@FreeBSD.ORG Sun Dec 31 15:56:15 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FCDF16A59A for ; Sun, 31 Dec 2006 15:56:14 +0000 (UTC) (envelope-from myninku@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 84F0513C45A for ; Sun, 31 Dec 2006 15:56:13 +0000 (UTC) (envelope-from myninku@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so6178550nfc for ; Sun, 31 Dec 2006 07:56:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=IVpO9k+C/vZVFMmHgCOmybrjanlr8LUvMInSKiO9WXWgBReGcbwvRl+EvDsGyxCqB6TcxCn7rQqNm14Wv0G2LUSz9or49UHnCSD18mVY1r9mDnVmiyLV/iWrq8mi72n8R12I9hTnMaNjHJY/6cYFjOe37nMZoujTBk3GiM+/z5o= Received: by 10.48.216.8 with SMTP id o8mr2553558nfg.1167580572450; Sun, 31 Dec 2006 07:56:12 -0800 (PST) Received: by 10.48.206.9 with HTTP; Sun, 31 Dec 2006 07:56:12 -0800 (PST) Message-ID: Date: Sun, 31 Dec 2006 15:56:12 +0000 From: sukaca To: freebsd-pf@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: second queue 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: Sun, 31 Dec 2006 15:56:15 -0000 this my config as yester day ext_if="lnc0" # replace with actual external interface name i.e., dc0 int_if="lnc0" # replace with actual internal interface name i.e., dc1 internal_net1="10.10.1.0/24" internal_net2="10.10.2.0/24" altq on lnc0 cbq bandwidth 128Kb queue { internal_net1, internal_net2 } queue internal_net2 bandwidth 64Kb cbq(default) queue internal_net1 bandwidth 64Kb cbq( borrow) pass out on lnc0 from any to any flags S/SA keep state queue (internal_net1, internal_net2) pass in on lnc0 from any to any flags S/SA keep state queue (internal_net1, internal_net2) #my output queue root_lnc0 bandwidth 128Kb priority 0 cbq( wrr root ) {internal_net2, internal_net1} [ pkts: 76936 bytes: 38239304 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 9.6 packets/s, 63.76Kb/s ] queue internal_net2 bandwidth 64Kb cbq( default ) [ pkts: 76936 bytes: 38239304 dropped pkts: 95 bytes: 15176 ] [ qlength: 17/ 50 borrows: 0 suspends: 19056 ] [ measured: 9.6 packets/s, 63.76Kb/s ] queue internal_net1 bandwidth 64Kb cbq( borrow ) [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.0 packets/s, 0 b/s ] #my second queue always not catch packet at all. #even i use this rule for pass rule pass out on lnc0 from any to any flags S/SA keep state queue internal_net1 pass out on lnc0 from any to any flags S/SA keep state queue internal_net2 pass in on lnc0 from any to any flags S/SA keep state queue internal_net2 pass in on lnc0 from any to any flags S/SA keep state queue internal_net1 do i have mistake again? regard vicky From owner-freebsd-pf@FreeBSD.ORG Mon Dec 25 11:08:46 2006 Return-Path: X-Original-To: freebsd-pf@FreeBSD.org Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2E5716A5FA for ; Mon, 25 Dec 2006 11:08:46 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id B1B7813C487 for ; Mon, 25 Dec 2006 11:08:46 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kBPB8k77034630 for ; Mon, 25 Dec 2006 11:08:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kBPB8j8n034626 for freebsd-pf@FreeBSD.org; Mon, 25 Dec 2006 11:08:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Dec 2006 11:08:45 GMT Message-Id: <200612251108.kBPB8j8n034626@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 25 Dec 2006 11:08:46 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/82271 pf [pf] cbq scheduler cause bad latency o kern/92949 pf [pf] PF + ALTQ problems with latency o sparc/93530 pf Incorrect checksums when using pf's route-to on sparc6 3 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f conf/81042 pf [pf] [patch] /etc/pf.os doesn't match FreeBSD 5.3->5.4 o kern/93825 pf [pf] pf reply-to doesn't work o kern/103304 pf pf accepts nonexistent queue in rules o kern/106400 pf fatal trap 12 at restart of PF with ALTQ if ng0 device 4 problems total. From owner-freebsd-pf@FreeBSD.ORG Fri Dec 29 12:06:17 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA60516A40F for ; Fri, 29 Dec 2006 12:06:17 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 2BA6013C441 for ; Fri, 29 Dec 2006 12:06:17 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so3820873uge for ; Fri, 29 Dec 2006 04:06:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eee8DFc/jwiG0lgaYU5gGb0nfY4SiDQ6jlGCi/VbGBwleOVeUDeaY0bJxpoHasmkb/PYdTzK/Iru0iV56HdheOPw3Vh9HP3cFIEerBDQ5+vIpbwovZq3lK/lWLJeFTLPxUZL/4wQXDwYWYZnoLJYw3QtjzjQbsiJoUual/3swLg= Received: by 10.67.22.14 with SMTP id z14mr20980832ugi.1167390336668; Fri, 29 Dec 2006 03:05:36 -0800 (PST) Received: by 10.67.27.15 with HTTP; Fri, 29 Dec 2006 03:05:36 -0800 (PST) Message-ID: <499c70c0612290305w11eee312ma02e482b69e77f01@mail.gmail.com> Date: Fri, 29 Dec 2006 14:05:36 +0300 From: "Abdullah Al-Marrie" To: "Max Laier" , "Jon Simola" In-Reply-To: <200611232013.41558.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <499c70c0611231047k84747frf91def08d509cba6@mail.gmail.com> <8eea04080611231059x6e229d09lfd3f25965511d7ee@mail.gmail.com> <499c70c0611231101k68429053l40ec68712ca66263@mail.gmail.com> <200611232013.41558.max@love2party.net> Cc: freebsd-pf@freebsd.org Subject: Re: rate limit with pf instead of IPFW 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, 29 Dec 2006 12:06:17 -0000 On 11/23/06, Max Laier wrote: > > On 11/23/06, Jon Simola wrote: > > > > Greetings BPF gurus! > > > > > > PF? bpf is different and has little to do with firewalling. > > > > > > > Could someone please give me full example to setup > > > > limit {src-addr | src-port | dst-addr | dst-port} to do what IPFW > > > > 01000 allow tcp from any to me setup limit src-addr 5 currently > > > > does > > > > > > I use something like this: > > > > > > pass in on $ext_if proto tcp from any to $ext_if port smtp flags S/SA > > > keep state (source-track rule, mac-src-states 5) > > > > > > -- > > > > Greetings Jon, > > > > Could you please post your pf.conf with the rules so I can use it as a > > guide? > > If you are looking for a guide - I suggest reading the pf-faq on the > OpenBSD site or Peter's great tutorial, available from: > http://home.nuug.no/~peter/pf/ The topic in question, is discussed here: > http://home.nuug.no/~peter/pf/en/bruteforce.html > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News Thank you Max, and Jon for your kind prompts to help me to sort this problem. PF is very powerful, again thanks for porting it to FreeBSD. :) I checked http://home.nuug.no/~peter/pf/en/bruteforce.html I still didn't find something in the faq covers table persist , do I need to create a file like /etc/bruteforce or no need for that and will be stored in kernel until they expire or I reboot the box? Here is my pf.conf # Macros: define common values, so they can be referenced and changed easily. ext_if="fxp0" # replace with actual external interface name i.e., dc0 int_if="fxp0" # replace with actual internal interface name i.e., dc1 tcp_services="{ 22, 25, 26, 53, 80, 110, 143, 443, 465, 783, 953, 993, 995, 3306, 59999 }" udp_services="{ 53, 514 }" icmp_types="8" # Tables: similar to macros, but more flexible for many addresses. table persist # Options: tune the behavior of pf, default values are given. set timeout { interval 10, frag 30 } set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 } set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 } set timeout { udp.first 60, udp.single 30, udp.multiple 60 } set timeout { icmp.first 20, icmp.error 10 } set timeout { other.first 60, other.single 30, other.multiple 60 } set timeout { adaptive.start 0, adaptive.end 0 } set limit { states 10000, frags 5000 } set loginterface $ext_if set optimization normal set block-policy drop #set require-order yes #set fingerprints "/etc/pf.os" #scrub in all scrub in on $ext_if all fragment reassemble min-ttl 15 max-mss 1400 scrub in on $ext_if all no-df scrub on $ext_if all reassemble tcp # Filtering: the implicit first two rules are pass in all pass out all # Pass all 'quick' on localhost loopback device pass quick on lo0 all ## Default DENY & Log filter rules block in log all block out log all # Drop our 'foo' 'quick' with no reply or logging. block in quick on $ext_if from to any # Drop our rfc1918 ranges #block in quick on $ext_if from to any # Pass in rules for Various services defined above. Using 'synproxy-state' for # basic dDoS mitigation on TCP services. pass in on $ext_if proto tcp from any to $ext_if port $tcp_services flags S/SA synproxy state pass inet proto tcp from any to any port 80 \ flags S/SA keep state \ (max-src-conn-rate 4/50, \ overload flush global) # Pass UDP keeping state pass in on $ext_if proto udp from any to $ext_if port $udp_services keep state # Pass ICMP Type 8 (echo-reply) only with state pass in on $ext_if inet proto icmp all icmp-type $icmp_types keep state # Pass FTP pass in quick on $ext_if proto tcp from any to any port 21 flags S/SA keep state pass in quick on $ext_if proto tcp from any to any port > 49151 keep state # Pass out rule allowing all with modulate state pass out on $ext_if proto tcp all modulate state flags S/SA # Pass out rules for UDP, ICMP pass out on $ext_if proto { udp, icmp } all keep state # End Am I missing something? as su I type pfctl -t foo -Tl -f /etc/pf.conf but it returns nothing. I want to see the current IPs being blocked since I used overload -- Regards, -Abdullah From owner-freebsd-pf@FreeBSD.ORG Fri Dec 29 12:57:41 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEA1116A4A7; Fri, 29 Dec 2006 12:57:41 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id 1DD5213C484; Fri, 29 Dec 2006 12:57:40 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 91E838C99C0; Fri, 29 Dec 2006 09:21:18 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 8897A8C99BF; Fri, 29 Dec 2006 09:21:18 +0800 (CST) Date: Fri, 29 Dec 2006 09:21:18 +0800 (CST) From: Tai-hwa Liang To: Max Laier In-Reply-To: <200612161709.48875.max@love2party.net> Message-ID: <061229091759A.42827@www.mmlab.cse.yzu.edu.tw> References: <200612161335.kBGDZkMj012022@freefall.freebsd.org> <200612161709.48875.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: csjp@freebsd.org, freebsd-pf@freebsd.org Subject: Re: debug.mpsafenet=1 vs. user/group rules [Re: kern/106805: ...] 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, 29 Dec 2006 12:57:42 -0000 On Sat, 16 Dec 2006, Max Laier wrote: [...] > The attached diff circumvents the problem by **always** doing the > credential lookup *before* walking the pf rules. This has the benefit, > that it works (at least I think it should), but there is a price to pay. > Now we have to pay for the socket lookup for *every* tcp and udp packet > instead of just for those that really hit uid/gid rules. That's why I > decided to make is a config option "PF_MPFSAFE_UGID" which you can turn > on if you are running a setup that will benefit. The patch turns it on > for the module-built by default. > > A possible scenario that should benefit is a big iron SMP box running lot > of services that you want to filter using *stateful* uid/gid rules. For > this setup where a huge percentage of the packets that are not captured > by states eventually match a uid/gid rule, you will even get added > parallelism with this patch. > > On every other typical setup, it should be better to avoid user/group > rules or to disable mpsafenet. > > In order for this to hit the tree, I need tests confirming that it really > helps and possibly benchmarks that qualify the impact of it. Thanks. Your patch works great here. The box in question never ran into a single lockup in the last 7 days. -- Thanks, Tai-hwa Liang From owner-freebsd-pf@FreeBSD.ORG Fri Dec 29 13:29:14 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48EA216A407 for ; Fri, 29 Dec 2006 13:29:14 +0000 (UTC) (envelope-from earl.lapus@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id DCF7013C441 for ; Fri, 29 Dec 2006 13:29:13 +0000 (UTC) (envelope-from earl.lapus@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so3839125uge for ; Fri, 29 Dec 2006 05:29:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=KjsOxdjSdB4qIs6TiPDGI4V6S9FXOwTtpNJKh9LLd3CyMbQshsnVPwpd2XflT9++vm9Fa291ugg9yWkljppwLkbVSGPrxIWCs5+10CjzX7fVNOf54pShnmOVwFDadnNULKtf62S3NkXVKL8MwxKJOwh9jIi5RvZ7xSyJOAaILKE= Received: by 10.78.178.5 with SMTP id a5mr738966huf.1167361632710; Thu, 28 Dec 2006 19:07:12 -0800 (PST) Received: by 10.78.137.13 with HTTP; Thu, 28 Dec 2006 19:07:12 -0800 (PST) Message-ID: <604f76120612281907l42a02640ia7806d452618109a@mail.gmail.com> Date: Fri, 29 Dec 2006 11:07:12 +0800 From: "Earl Lapus" To: freebsd-pf@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: cleanup_pf_zone() 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, 29 Dec 2006 13:29:14 -0000 hi all, Just a small query about cleanup_pf_zone() in pf_ioctl.c All of the allocated structures using UMA_CREATE() in pfattach() were detroyed using UMA_DESTROY() in cleanup_pf_zone() except for pfr_kentry_pl2. Is there a particular reason why pfr_kentry_pl2 is being left out? -- There are seven words in this sentence. From owner-freebsd-pf@FreeBSD.ORG Fri Dec 29 13:51:38 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA7B116A407 for ; Fri, 29 Dec 2006 13:51:37 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id 7CFBE13C4E0 for ; Fri, 29 Dec 2006 13:51:37 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.182.75] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1H0Hwp2q9L-0007sk; Fri, 29 Dec 2006 14:38:59 +0100 From: Max Laier Organization: FreeBSD To: "Abdullah Al-Marrie" Date: Fri, 29 Dec 2006 14:38:52 +0100 User-Agent: KMail/1.9.4 References: <499c70c0611231047k84747frf91def08d509cba6@mail.gmail.com> <200611232013.41558.max@love2party.net> <499c70c0612290305w11eee312ma02e482b69e77f01@mail.gmail.com> In-Reply-To: <499c70c0612290305w11eee312ma02e482b69e77f01@mail.gmail.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10064744.S49oolbEj4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612291438.58733.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-pf@freebsd.org Subject: Re: rate limit with pf instead of IPFW 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, 29 Dec 2006 13:51:38 -0000 --nextPart10064744.S49oolbEj4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 29 December 2006 12:05, Abdullah Al-Marrie wrote: > On 11/23/06, Max Laier wrote: > > > On 11/23/06, Jon Simola wrote: > > > > > Greetings BPF gurus! > > > > > > > > PF? bpf is different and has little to do with firewalling. > > > > > > > > > Could someone please give me full example to setup > > > > > limit {src-addr | src-port | dst-addr | dst-port} to do what > > > > > IPFW 01000 allow tcp from any to me setup limit src-addr 5 > > > > > currently does > > > > > > > > I use something like this: > > > > > > > > pass in on $ext_if proto tcp from any to $ext_if port smtp flags > > > > S/SA keep state (source-track rule, mac-src-states 5) > > > > > > > > -- > > > > > > Greetings Jon, > > > > > > Could you please post your pf.conf with the rules so I can use it > > > as a guide? > > > > If you are looking for a guide - I suggest reading the pf-faq on the > > OpenBSD site or Peter's great tutorial, available from: > > http://home.nuug.no/~peter/pf/ The topic in question, is discussed > > here: http://home.nuug.no/~peter/pf/en/bruteforce.html > > > > -- > > /"\ Best regards, | mlaier@freebsd.org > > \ / Max Laier | ICQ #67774661 > > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > Thank you Max, and Jon for your kind prompts to help me to sort this > problem. > > PF is very powerful, again thanks for porting it to FreeBSD. :) > > I checked http://home.nuug.no/~peter/pf/en/bruteforce.html > > I still didn't find something in the faq covers table > persist , do I need to create a file like /etc/bruteforce or no need > for that and will be stored in kernel until they expire or I reboot the > box? You can *load* a table from a file pf.conf(5) has the syntax to do so. =20 Afterwards the table exists in kernel memory and all updates only happen=20 there (and are not written back to the file). There are tools that help=20 with that, however. > Here is my pf.conf =2E.. > # Tables: similar to macros, but more flexible for many addresses. > table persist =2E.. > # End > > Am I missing something? You probably want a "block ... from " rule somewhere in order for the= =20 thing to take effect. > as su I type pfctl -t foo -Tl -f /etc/pf.conf but it returns nothing. > > I want to see the current IPs being blocked since I used overload Read the pfctl(8) manpage. You are reloading the table from the pf.conf=20 file - which causes it to be empty. In order to show the contents, you=20 need something like: pfctl -t foo -Tshow # a couple of "-v" gives nice statistics as well =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart10064744.S49oolbEj4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFlRpyXyyEoT62BG0RAgjqAJ0X7IQ0usfmxNXTtXyu2uvzEvYMXgCfXESN +vw9QOod6dIMYQyaqxIv6z0= =XYFI -----END PGP SIGNATURE----- --nextPart10064744.S49oolbEj4-- From owner-freebsd-pf@FreeBSD.ORG Fri Dec 29 13:57:39 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 115FB16A407 for ; Fri, 29 Dec 2006 13:57:39 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id 9465113C458 for ; Fri, 29 Dec 2006 13:57:38 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.182.75] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1H0IEq3fwa-0003pu; Fri, 29 Dec 2006 14:57:37 +0100 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Fri, 29 Dec 2006 14:57:30 +0100 User-Agent: KMail/1.9.4 References: <604f76120612281907l42a02640ia7806d452618109a@mail.gmail.com> In-Reply-To: <604f76120612281907l42a02640ia7806d452618109a@mail.gmail.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2912178.dCDbgQJ07W"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612291457.35933.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Subject: Re: cleanup_pf_zone() 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, 29 Dec 2006 13:57:39 -0000 --nextPart2912178.dCDbgQJ07W Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 29 December 2006 04:07, Earl Lapus wrote: > Just a small query about cleanup_pf_zone() in pf_ioctl.c > > All of the allocated structures using UMA_CREATE() in pfattach() > were detroyed using UMA_DESTROY() in cleanup_pf_zone() except > for pfr_kentry_pl2. > > Is there a particular reason why pfr_kentry_pl2 is being left out? Oops, seems I just forgot that one. Will take a closer look and fix it -=20 thanks for the report. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2912178.dCDbgQJ07W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFlR7PXyyEoT62BG0RAhpbAJ9woHsmnrDPaafrIqV6/yR+3rifwwCdE8+I cSoCZk3P4SiHiTljDQ0OFik= =whLy -----END PGP SIGNATURE----- --nextPart2912178.dCDbgQJ07W-- From owner-freebsd-pf@FreeBSD.ORG Fri Dec 29 14:18:45 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 762A616A412 for ; Fri, 29 Dec 2006 14:18:45 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id DBFA913C455 for ; Fri, 29 Dec 2006 14:18:44 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.182.75] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1H0IZD441y-0007uW; Fri, 29 Dec 2006 15:18:43 +0100 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Fri, 29 Dec 2006 15:18:33 +0100 User-Agent: KMail/1.9.4 References: <200612161335.kBGDZkMj012022@freefall.freebsd.org> <200612161709.48875.max@love2party.net> <061229091759A.42827@www.mmlab.cse.yzu.edu.tw> In-Reply-To: <061229091759A.42827@www.mmlab.cse.yzu.edu.tw> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4615191.fWbHb7xN1E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612291518.39222.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Tai-hwa Liang , csjp@freebsd.org Subject: Re: debug.mpsafenet=1 vs. user/group rules [Re: kern/106805: ...] 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, 29 Dec 2006 14:18:45 -0000 --nextPart4615191.fWbHb7xN1E Content-Type: multipart/mixed; boundary="Boundary-01=_7OSlF3KQwzAfXmE" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_7OSlF3KQwzAfXmE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Everybody, I just put this in HEAD, a diff to RELENG_6 is attached. Please follow=20 avatar's example and test and report back! Just apply and put "options PF_MPSAFE_UGID" in your kernconf or=20 append "-DPF_MPSAFE_UGID" to your CFLAGS in make.conf. The latter works=20 for the module build as well. Don't forgot to turn debug.mpsafenet back=20 on. I'd also be interested in the output of "pfctl -si", in particular the=20 match counter and the State searches in order to get a picture of your=20 traffic pattern and how the patch might impact on it. On Friday 29 December 2006 02:21, Tai-hwa Liang wrote: > On Sat, 16 Dec 2006, Max Laier wrote: > [...] > > > The attached diff circumvents the problem by **always** doing the > > credential lookup *before* walking the pf rules. This has the > > benefit, that it works (at least I think it should), but there is a > > price to pay. Now we have to pay for the socket lookup for *every* > > tcp and udp packet instead of just for those that really hit uid/gid > > rules. That's why I decided to make is a config option > > "PF_MPFSAFE_UGID" which you can turn on if you are running a setup > > that will benefit. The patch turns it on for the module-built by > > default. > > > > A possible scenario that should benefit is a big iron SMP box running > > lot of services that you want to filter using *stateful* uid/gid > > rules. For this setup where a huge percentage of the packets that > > are not captured by states eventually match a uid/gid rule, you will > > even get added parallelism with this patch. > > > > On every other typical setup, it should be better to avoid user/group > > rules or to disable mpsafenet. > > > > In order for this to hit the tree, I need tests confirming that it > > really helps and possibly benchmarks that qualify the impact of it.=20 > > Thanks. > > Your patch works great here. The box in question never ran into a > single lockup in the last 7 days. Great - Thanks for the report! =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_7OSlF3KQwzAfXmE Content-Type: text/x-diff; charset="iso-8859-1"; name="pf.ugid.RELENG_6.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pf.ugid.RELENG_6.diff" Index: conf/NOTES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/conf/NOTES,v retrieving revision 1.1325.2.24 diff -u -r1.1325.2.24 NOTES =2D-- conf/NOTES 21 Oct 2006 05:28:50 -0000 1.1325.2.24 +++ conf/NOTES 29 Dec 2006 14:08:48 -0000 @@ -626,6 +626,9 @@ # The `pflog' device provides the pflog0 interface which logs packets. # The `pfsync' device provides the pfsync0 interface used for # synchronization of firewall state tables (over the net). +# The PF_MPSAFE_UGID option enables a special workaround for a LOR with +# user/group rules that would otherwise lead to a deadlock. This has +# performance implications and should be used with care. # # The PPP_BSDCOMP option enables support for compress(1) style entire # packet compression, the PPP_DEFLATE is for zlib/gzip style compression. @@ -656,6 +659,7 @@ device pf #PF OpenBSD packet-filter firewall device pflog #logging support interface for PF device pfsync #synchronization interface for PF +options PF_MPSAFE_UGID #Workaround LOR with user/group rules device carp #Common Address Redundancy Protocol device ppp #Point-to-point protocol options PPP_BSDCOMP #PPP BSD-compress support Index: conf/options =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/conf/options,v retrieving revision 1.510.2.19 diff -u -r1.510.2.19 options =2D-- conf/options 2 Sep 2006 13:12:08 -0000 1.510.2.19 +++ conf/options 29 Dec 2006 14:09:29 -0000 @@ -342,6 +342,7 @@ DEV_PF opt_pf.h DEV_PFLOG opt_pf.h DEV_PFSYNC opt_pf.h +PF_MPSAFE_UGID opt_pf.h ETHER_II opt_ef.h ETHER_8023 opt_ef.h ETHER_8022 opt_ef.h Index: contrib/pf/net/pf.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf.c,v retrieving revision 1.34.2.4 diff -u -r1.34.2.4 pf.c =2D-- contrib/pf/net/pf.c 19 Sep 2006 15:45:20 -0000 1.34.2.4 +++ contrib/pf/net/pf.c 29 Dec 2006 14:09:52 -0000 @@ -3016,6 +3016,12 @@ return (PF_DROP); } =20 +#if defined(__FreeBSD__) && defined(PF_MPSAFE_UGID) + PF_UNLOCK(); + lookup =3D pf_socket_lookup(&uid, &gid, direction, pd, inp); + PF_LOCK(); +#endif + r =3D TAILQ_FIRST(pf_main_ruleset.rules[PF_RULESET_FILTER].active.ptr); =20 if (direction =3D=3D PF_OUT) { @@ -3412,6 +3418,12 @@ return (PF_DROP); } =20 +#if defined(__FreeBSD__) && defined(PF_MPSAFE_UGID) + PF_UNLOCK(); + lookup =3D pf_socket_lookup(&uid, &gid, direction, pd, inp); + PF_LOCK(); +#endif + r =3D TAILQ_FIRST(pf_main_ruleset.rules[PF_RULESET_FILTER].active.ptr); =20 if (direction =3D=3D PF_OUT) { --Boundary-01=_7OSlF3KQwzAfXmE-- --nextPart4615191.fWbHb7xN1E Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFlSO/XyyEoT62BG0RAkzzAJ9BySU+aI0LmplSweBLEUYAQV4QmgCeN6ri rw629AcquWT5EhsjCaLJ6Ic= =14FC -----END PGP SIGNATURE----- --nextPart4615191.fWbHb7xN1E-- From owner-freebsd-pf@FreeBSD.ORG Fri Dec 29 16:12:25 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4453E16A40F for ; Fri, 29 Dec 2006 16:12:25 +0000 (UTC) (envelope-from csjp@FreeBSD.ORG) Received: from ems01.seccuris.com (ems01.seccuris.com [204.112.0.35]) by mx1.freebsd.org (Postfix) with ESMTP id B820C13C455 for ; Fri, 29 Dec 2006 16:12:24 +0000 (UTC) (envelope-from csjp@FreeBSD.ORG) Received: from [192.168.11.124] (dhcp-ws-060.ws.seccuris.com [192.168.11.124]) by ems01.seccuris.com (Postfix) with ESMTP id D495A462EAD; Fri, 29 Dec 2006 10:46:41 -0600 (CST) Message-ID: <45953727.7020405@FreeBSD.ORG> Date: Fri, 29 Dec 2006 09:41:27 -0600 From: "Christian S.J. Peron" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Max Laier References: <200612161335.kBGDZkMj012022@freefall.freebsd.org> <200612161709.48875.max@love2party.net> In-Reply-To: <200612161709.48875.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: avatar@mmlab.cse.yzu.edu.tw, freebsd-pf@freebsd.org Subject: Re: debug.mpsafenet=1 vs. user/group rules [Re: kern/106805: ...] 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, 29 Dec 2006 16:12:25 -0000 Max, I have replied to this mail and I guess it has been lost, as I have had no response. Although this technically makes the problem harmless, all you are doing is moving the lock order reversal from pf+inpcb to pfil+inpcb. The only major difference is that we can have multiple readers of the pfil lock, making the LOR harmless, in this path. In IPFW, I changed the chain locks to use rw_lock(9), so we can get rid of the mpsafenet requirement for IPFW. I've thought about doing this in IPFW (looking up the ucred if there are any uid/gid/jail rules) prior to picking up the chain locks, but realized we could remove the lock ordering issue all together if we anihilated the pfil lock. One idea I had was introducing PFIL_STATIC which requires that modules wishing to register pfil hooks did so at boot-time only. Something similar was done for the MAC framework to avoid having to pickup policy list locks for each security decision. This would also have the nice side effect of eliminating a couple of atomic instructions per packet in the fast path. Taking this approach along with moving the inpcb lookup prior to the firewall chain locks allows us to actually eliminate the lock ordering issues. However, the layering violation still exists. But it's harmless. However, having said all that. This works, too. Max Laier wrote: > Okay, spoken too quick ... I just had an idea (enlightment you might say - > given the time of year), that might finally get us rid of this symptom > (not of the problem though). > > Short recap on why this is happening: Checking socket credentials on the > IP layer (where pf lives) is a layering violation. A useful one, you may > argue, but nontheless - it causes a lock order reversal: In order to > walk the pf rules we need to hold the pf lock, in order to walk the > socket hash we need to hold the "inp" lock. > > The attached diff circumvents the problem by **always** doing the > credential lookup *before* walking the pf rules. This has the benefit, > that it works (at least I think it should), but there is a price to pay. > Now we have to pay for the socket lookup for *every* tcp and udp packet > instead of just for those that really hit uid/gid rules. That's why I > decided to make is a config option "PF_MPFSAFE_UGID" which you can turn > on if you are running a setup that will benefit. The patch turns it on > for the module-built by default. > > A possible scenario that should benefit is a big iron SMP box running lot > of services that you want to filter using *stateful* uid/gid rules. For > this setup where a huge percentage of the packets that are not captured > by states eventually match a uid/gid rule, you will even get added > parallelism with this patch. > > On every other typical setup, it should be better to avoid user/group > rules or to disable mpsafenet. > > In order for this to hit the tree, I need tests confirming that it really > helps and possibly benchmarks that qualify the impact of it. Thanks. > > > ------------------------------------------------------------------------ > > Index: conf/options > =================================================================== > RCS file: /usr/store/mlaier/fcvs/src/sys/conf/options,v > retrieving revision 1.567 > diff -u -r1.567 options > --- conf/options 10 Dec 2006 04:23:23 -0000 1.567 > +++ conf/options 16 Dec 2006 15:36:08 -0000 > @@ -349,6 +349,7 @@ > DEV_PF opt_pf.h > DEV_PFLOG opt_pf.h > DEV_PFSYNC opt_pf.h > +PF_MPSAFE_UGID opt_pf.h > ETHER_II opt_ef.h > ETHER_8023 opt_ef.h > ETHER_8022 opt_ef.h > Index: contrib/pf/net/pf.c > =================================================================== > RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf.c,v > retrieving revision 1.42 > diff -u -r1.42 pf.c > --- contrib/pf/net/pf.c 22 Oct 2006 11:52:11 -0000 1.42 > +++ contrib/pf/net/pf.c 16 Dec 2006 15:34:52 -0000 > @@ -3032,6 +3032,12 @@ > return (PF_DROP); > } > > +#if defined(__FreeBSD__) && defined(PF_MPSAFE_UGID) > + PF_UNLOCK(); > + lookup = pf_socket_lookup(&uid, &gid, direction, pd, inp); > + PF_LOCK(); > +#endif > + > r = TAILQ_FIRST(pf_main_ruleset.rules[PF_RULESET_FILTER].active.ptr); > > if (direction == PF_OUT) { > @@ -3428,6 +3434,12 @@ > return (PF_DROP); > } > > +#if defined(__FreeBSD__) && defined(PF_MPSAFE_UGID) > + PF_UNLOCK(); > + lookup = pf_socket_lookup(&uid, &gid, direction, pd, inp); > + PF_LOCK(); > +#endif > + > r = TAILQ_FIRST(pf_main_ruleset.rules[PF_RULESET_FILTER].active.ptr); > > if (direction == PF_OUT) { > Index: modules/pf/Makefile > =================================================================== > RCS file: /usr/store/mlaier/fcvs/src/sys/modules/pf/Makefile,v > retrieving revision 1.12 > diff -u -r1.12 Makefile > --- modules/pf/Makefile 12 Sep 2006 04:25:12 -0000 1.12 > +++ modules/pf/Makefile 16 Dec 2006 15:41:00 -0000 > @@ -10,7 +10,7 @@ > in4_cksum.c \ > opt_pf.h opt_inet.h opt_inet6.h opt_bpf.h opt_mac.h > > -CFLAGS+= -I${.CURDIR}/../../contrib/pf > +CFLAGS+= -I${.CURDIR}/../../contrib/pf -DPF_MPSAFE_UGID > > .if !defined(KERNBUILDDIR) > opt_inet.h: > From owner-freebsd-pf@FreeBSD.ORG Fri Dec 29 16:38:35 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C77616A5A2; Fri, 29 Dec 2006 16:38:26 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id 57BF713C465; Fri, 29 Dec 2006 16:38:26 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.182.75] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1H0KkK3aKv-0003l9; Fri, 29 Dec 2006 17:38:18 +0100 From: Max Laier Organization: FreeBSD To: "Christian S.J. Peron" Date: Fri, 29 Dec 2006 17:38:09 +0100 User-Agent: KMail/1.9.4 References: <200612161335.kBGDZkMj012022@freefall.freebsd.org> <200612161709.48875.max@love2party.net> <45953727.7020405@FreeBSD.ORG> In-Reply-To: <45953727.7020405@FreeBSD.ORG> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2555463.v5q0yGz9D8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612291738.15541.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: avatar@mmlab.cse.yzu.edu.tw, Robert Nicholas Maxwell Watson , freebsd-pf@freebsd.org Subject: Re: debug.mpsafenet=1 vs. user/group rules [Re: kern/106805: ...] 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, 29 Dec 2006 16:38:35 -0000 --nextPart2555463.v5q0yGz9D8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 29 December 2006 16:41, Christian S.J. Peron wrote: > I have replied to this mail and I guess it has been lost, as I have had > no response. Although this technically makes > the problem harmless, all you are doing is moving the lock order > reversal from pf+inpcb to pfil+inpcb. The > only major difference is that we can have multiple readers of the pfil > lock, making the LOR harmless, in this path. I don't necessarily agree that you can have a LOR with non-exclusive=20 locks. As you rightly point out, it will never result in a deadlock=20 situation - as long as there isn't a code path that obtains the exclusive=20 version of the rw_lock and the inpcb lock. > In IPFW, I changed the chain locks to use rw_lock(9), so we can get rid > of the mpsafenet requirement for IPFW. I'm not 100% sure IPFW is safe yet. As we configure via raw sockets there= =20 might be some common locks that are held when we enter ip_fw_ctl, which=20 then picks up the exclusive version of the chain lock. I'm not sure what=20 kind of locks are in play really, though - CC'ing Robert. > I've thought about doing this in IPFW (looking up the ucred if there > are any uid/gid/jail rules) prior to picking up the > chain locks, but realized we could remove the lock ordering issue all > together if we anihilated the pfil lock. As long as you are holding the IPFW rw_lock over the lookup there is a=20 potential problem as described above. The pfil rw_lock doesn't have any=20 exclusive interaction with any of the inpcb locks, so there is no=20 problem - as far as I understand at least. > One idea I had was introducing PFIL_STATIC which requires that modules > wishing to register pfil hooks did so at > boot-time only. Something similar was done for the MAC framework to > avoid having to pickup policy list locks > for each security decision. Hmmm ... how would we implement something like this? Can we easily keep=20 the non-static version? I'd like to be able to develop using modules ;) > This would also have the nice side effect of eliminating a couple of > atomic instructions per packet in the fast path. > Taking this approach along with moving the inpcb lookup prior to the > firewall chain locks allows us to actually > eliminate the lock ordering issues. However, the layering violation > still exists. But it's harmless. =46rom the point of view of the locks the layering violation would be gone,= =20 that's why it is harmless. > However, having said all that. This works, too. > > Max Laier wrote: > > Okay, spoken too quick ... I just had an idea (enlightment you might > > say - given the time of year), that might finally get us rid of this > > symptom (not of the problem though). > > > > Short recap on why this is happening: Checking socket credentials on > > the IP layer (where pf lives) is a layering violation. A useful one, > > you may argue, but nontheless - it causes a lock order reversal: In > > order to walk the pf rules we need to hold the pf lock, in order to > > walk the socket hash we need to hold the "inp" lock. > > > > The attached diff circumvents the problem by **always** doing the > > credential lookup *before* walking the pf rules. This has the > > benefit, that it works (at least I think it should), but there is a > > price to pay. Now we have to pay for the socket lookup for *every* > > tcp and udp packet instead of just for those that really hit uid/gid > > rules. That's why I decided to make is a config option > > "PF_MPFSAFE_UGID" which you can turn on if you are running a setup > > that will benefit. The patch turns it on for the module-built by > > default. > > > > A possible scenario that should benefit is a big iron SMP box running > > lot of services that you want to filter using *stateful* uid/gid > > rules. For this setup where a huge percentage of the packets that > > are not captured by states eventually match a uid/gid rule, you will > > even get added parallelism with this patch. > > > > On every other typical setup, it should be better to avoid user/group > > rules or to disable mpsafenet. > > > > In order for this to hit the tree, I need tests confirming that it > > really helps and possibly benchmarks that qualify the impact of it.=20 > > Thanks. > > > > > > --------------------------------------------------------------------- > >--- > > > > Index: conf/options > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /usr/store/mlaier/fcvs/src/sys/conf/options,v > > retrieving revision 1.567 > > diff -u -r1.567 options > > --- conf/options 10 Dec 2006 04:23:23 -0000 1.567 > > +++ conf/options 16 Dec 2006 15:36:08 -0000 > > @@ -349,6 +349,7 @@ > > DEV_PF opt_pf.h > > DEV_PFLOG opt_pf.h > > DEV_PFSYNC opt_pf.h > > +PF_MPSAFE_UGID opt_pf.h > > ETHER_II opt_ef.h > > ETHER_8023 opt_ef.h > > ETHER_8022 opt_ef.h > > Index: contrib/pf/net/pf.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf.c,v > > retrieving revision 1.42 > > diff -u -r1.42 pf.c > > --- contrib/pf/net/pf.c 22 Oct 2006 11:52:11 -0000 1.42 > > +++ contrib/pf/net/pf.c 16 Dec 2006 15:34:52 -0000 > > @@ -3032,6 +3032,12 @@ > > return (PF_DROP); > > } > > > > +#if defined(__FreeBSD__) && defined(PF_MPSAFE_UGID) > > + PF_UNLOCK(); > > + lookup =3D pf_socket_lookup(&uid, &gid, direction, pd, inp); > > + PF_LOCK(); > > +#endif > > + > > r =3D > > TAILQ_FIRST(pf_main_ruleset.rules[PF_RULESET_FILTER].active.ptr); > > > > if (direction =3D=3D PF_OUT) { > > @@ -3428,6 +3434,12 @@ > > return (PF_DROP); > > } > > > > +#if defined(__FreeBSD__) && defined(PF_MPSAFE_UGID) > > + PF_UNLOCK(); > > + lookup =3D pf_socket_lookup(&uid, &gid, direction, pd, inp); > > + PF_LOCK(); > > +#endif > > + > > r =3D > > TAILQ_FIRST(pf_main_ruleset.rules[PF_RULESET_FILTER].active.ptr); > > > > if (direction =3D=3D PF_OUT) { > > Index: modules/pf/Makefile > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /usr/store/mlaier/fcvs/src/sys/modules/pf/Makefile,v > > retrieving revision 1.12 > > diff -u -r1.12 Makefile > > --- modules/pf/Makefile 12 Sep 2006 04:25:12 -0000 1.12 > > +++ modules/pf/Makefile 16 Dec 2006 15:41:00 -0000 > > @@ -10,7 +10,7 @@ > > in4_cksum.c \ > > opt_pf.h opt_inet.h opt_inet6.h opt_bpf.h opt_mac.h > > > > -CFLAGS+=3D -I${.CURDIR}/../../contrib/pf > > +CFLAGS+=3D -I${.CURDIR}/../../contrib/pf -DPF_MPSAFE_UGID > > > > .if !defined(KERNBUILDDIR) > > opt_inet.h: =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2555463.v5q0yGz9D8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFlUR3XyyEoT62BG0RAiA3AJ4qb0gqEIsb3AIj640qZRDMLi/oDgCfZdtc QIO//w7adUsYFgpiszzA5lM= =V0yt -----END PGP SIGNATURE----- --nextPart2555463.v5q0yGz9D8-- From owner-freebsd-pf@FreeBSD.ORG Fri Dec 29 17:38:06 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C7CE16A4D8 for ; Fri, 29 Dec 2006 17:38:06 +0000 (UTC) (envelope-from csjp@FreeBSD.ORG) Received: from ems01.seccuris.com (ems01.seccuris.com [204.112.0.35]) by mx1.freebsd.org (Postfix) with ESMTP id E321413C461 for ; Fri, 29 Dec 2006 17:38:04 +0000 (UTC) (envelope-from csjp@FreeBSD.ORG) Received: from [192.168.11.124] (dhcp-ws-060.ws.seccuris.com [192.168.11.124]) by ems01.seccuris.com (Postfix) with ESMTP id 8AFD3462EA5; Fri, 29 Dec 2006 12:43:29 -0600 (CST) Message-ID: <45955284.6000606@FreeBSD.ORG> Date: Fri, 29 Dec 2006 11:38:12 -0600 From: "Christian S.J. Peron" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Max Laier References: <200612161335.kBGDZkMj012022@freefall.freebsd.org> <200612161709.48875.max@love2party.net> <45953727.7020405@FreeBSD.ORG> <200612291738.15541.max@love2party.net> In-Reply-To: <200612291738.15541.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: avatar@mmlab.cse.yzu.edu.tw, Robert Nicholas Maxwell Watson , freebsd-pf@freebsd.org Subject: Re: debug.mpsafenet=1 vs. user/group rules [Re: kern/106805: ...] 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, 29 Dec 2006 17:38:06 -0000 Max Laier wrote: > On Friday 29 December 2006 16:41, Christian S.J. Peron wrote: > >> In IPFW, I changed the chain locks to use rw_lock(9), so we can get rid >> of the mpsafenet requirement for IPFW. >> > > I'm not 100% sure IPFW is safe yet. As we configure via raw sockets there > might be some common locks that are held when we enter ip_fw_ctl, which > then picks up the exclusive version of the chain lock. I'm not sure what > kind of locks are in play really, though - CC'ing Robert. > I agree, however, I am fairly sure that each protocol has it's own inpcb locks. Since we never lookup the pcb for a raw socket (I.E. we currently only support ucred based firewall rules for TCP/UDP packets). So, in the IPFW configuration path we have: ripcb lock (maybe?) -> rw_wlock() -> firewall modification -> rw_wunlock -> ripcb unlock (maybe?) In the firewall in/outbound paths we have: {tcp|udp}pcb lock -> rw_rlock() -> process firewall chains -> rw_runlock() -> {tcp|udp}pcblock There is also the inp lock itself, but thats associated with the sockets themselves... and again, the raw socket associated with configuring the firewall should never be sending or receiving IP data. >> I've thought about doing this in IPFW (looking up the ucred if there >> are any uid/gid/jail rules) prior to picking up the >> chain locks, but realized we could remove the lock ordering issue all >> together if we anihilated the pfil lock. >> > > As long as you are holding the IPFW rw_lock over the lookup there is a > potential problem as described above. The pfil rw_lock doesn't have any > exclusive interaction with any of the inpcb locks, so there is no > problem - as far as I understand at least > What I was thinking was this: if (ucred_rule_count > 0) { ucred = lookup_ucred(..); } rw_rlock(&chain_lock); . . . rw_runlock(&chain_lock); So we would not be picking up any chain locks while the inp lock as held, and vice versa. It should be noted that this also allows us to cleanup the ucred stack based caching code. >> One idea I had was introducing PFIL_STATIC which requires that modules >> wishing to register pfil hooks did so at >> boot-time only. Something similar was done for the MAC framework to >> avoid having to pickup policy list locks >> for each security decision. >> > > Hmmm ... how would we implement something like this? Can we easily keep > the non-static version? I'd like to be able to develop using modules ;) > Take a look at kern_mac.c and specifically how the MAC_STATIC kernel option is handled. My production firewalls never load/unload firewalls at run-time, I would personally be using PFIL_STATIC, just not on my development machines. Again, I am proposing we do both: (1) Implement ucred lookup PRIOR to picking up firewall chain locks (2) Implement PFIL_STATIC to eliminate any WITNESS warnings between pfil and inpcb locks even though these warnings should be completely harmless imho. We can also pickup the PFIL locks conditionally based on whether or not PFIL_STATIC has been specified, eliminating a couple more atomic instructions per packet in the fast path. >> This would also have the nice side effect of eliminating a couple of >> atomic instructions per packet in the fast path. >> Taking this approach along with moving the inpcb lookup prior to the >> firewall chain locks allows us to actually >> eliminate the lock ordering issues. However, the layering violation >> still exists. But it's harmless. >> > > From the point of view of the locks the layering violation would be gone, > that's why it is harmless. > The layering violation occurs when we pickup layer 4 locks from layer 3, however, with the changes it's just bad programming practice instead of being fatal :) From owner-freebsd-pf@FreeBSD.ORG Sat Dec 30 05:23:00 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29A4916A40F for ; Sat, 30 Dec 2006 05:23:00 +0000 (UTC) (envelope-from earl.lapus@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id B87FC13C458 for ; Sat, 30 Dec 2006 05:22:59 +0000 (UTC) (envelope-from earl.lapus@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so5708721nfc for ; Fri, 29 Dec 2006 21:22:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kRYlKdszF0aRu8ECrgf72Wmk/xMQU3Tl9LJHfZCbgFrgdb8SZvi5ilUY9xKvEVzxuv706zqcooJnXKOf4lobL698Zi3D7BvaoMUuHGcYm9XRGYpd5EXGI1OYJ1rQ+MxQ1GFSO3FwChvQicO7hftvnZpkyUkIfheD9LycA1L18xA= Received: by 10.78.203.13 with SMTP id a13mr1274873hug.1167456178512; Fri, 29 Dec 2006 21:22:58 -0800 (PST) Received: by 10.78.137.13 with HTTP; Fri, 29 Dec 2006 21:22:58 -0800 (PST) Message-ID: <604f76120612292122g698c594o4b73055813796407@mail.gmail.com> Date: Sat, 30 Dec 2006 13:22:58 +0800 From: "Earl Lapus" To: "Max Laier" In-Reply-To: <200612291457.35933.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <604f76120612281907l42a02640ia7806d452618109a@mail.gmail.com> <200612291457.35933.max@love2party.net> Cc: freebsd-pf@freebsd.org Subject: Re: cleanup_pf_zone() 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, 30 Dec 2006 05:23:00 -0000 Some additional info... The undestroyed strucure, pfr_kentry_pl2, seems to be the reason why my box crashed when I did the following: 1) kldlaod pf 2) kldunload pf 3) sysctl -a or sysctl vm <-- crash I'm running FreeBSD6.1 Release on AMD64. In my case, the crash happens all the time. Sorry for not giving all the details in my first post. I just wasn't sure what was really going on. F.Y.I. On 12/29/06, Max Laier wrote: > On Friday 29 December 2006 04:07, Earl Lapus wrote: > > Just a small query about cleanup_pf_zone() in pf_ioctl.c > > > > All of the allocated structures using UMA_CREATE() in pfattach() > > were detroyed using UMA_DESTROY() in cleanup_pf_zone() except > > for pfr_kentry_pl2. > > > > Is there a particular reason why pfr_kentry_pl2 is being left out? > > Oops, seems I just forgot that one. Will take a closer look and fix it - > thanks for the report. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > > -- There are seven words in this sentence. From owner-freebsd-pf@FreeBSD.ORG Sat Dec 30 11:57:14 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A115D16A412 for ; Sat, 30 Dec 2006 11:57:14 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 372A313C428 for ; Sat, 30 Dec 2006 11:57:14 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.187.186] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1H0cps1ee3-0001L7; Sat, 30 Dec 2006 12:57:13 +0100 From: Max Laier Organization: FreeBSD To: "Earl Lapus" Date: Sat, 30 Dec 2006 12:56:59 +0100 User-Agent: KMail/1.9.4 References: <604f76120612281907l42a02640ia7806d452618109a@mail.gmail.com> <200612291457.35933.max@love2party.net> <604f76120612292122g698c594o4b73055813796407@mail.gmail.com> In-Reply-To: <604f76120612292122g698c594o4b73055813796407@mail.gmail.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1589362.K9xjy8nvKO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612301257.06771.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-pf@freebsd.org Subject: Re: cleanup_pf_zone() 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, 30 Dec 2006 11:57:14 -0000 --nextPart1589362.K9xjy8nvKO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 30 December 2006 06:22, Earl Lapus wrote: > Some additional info... > > The undestroyed strucure, pfr_kentry_pl2, seems to be the reason why So you are saying that you added the UMA_DESTORY for pfr_kentry_pl2 and=20 the panic went away? > my box crashed when I did the following: > > 1) kldlaod pf > 2) kldunload pf > 3) sysctl -a or sysctl vm <-- crash > > I'm running FreeBSD6.1 Release on AMD64. > In my case, the crash happens all the time. > > Sorry for not giving all the details in my first post. > I just wasn't sure what was really going on. > > F.Y.I. > > On 12/29/06, Max Laier wrote: > > On Friday 29 December 2006 04:07, Earl Lapus wrote: > > > Just a small query about cleanup_pf_zone() in pf_ioctl.c > > > > > > All of the allocated structures using UMA_CREATE() in pfattach() > > > were detroyed using UMA_DESTROY() in cleanup_pf_zone() except > > > for pfr_kentry_pl2. > > > > > > Is there a particular reason why pfr_kentry_pl2 is being left out? > > > > Oops, seems I just forgot that one. Will take a closer look and fix > > it - thanks for the report. > > > > -- > > /"\ Best regards, | mlaier@freebsd.org > > \ / Max Laier | ICQ #67774661 > > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > > / \ ASCII Ribbon Campaign | Against HTML Mail and News =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1589362.K9xjy8nvKO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFllQSXyyEoT62BG0RAkyZAJ4mFceO+IwsAlJVaaEs+Lty80t+8ACfRGtR uiSQz7Hys6F3ghvJltHhe9Q= =jzKB -----END PGP SIGNATURE----- --nextPart1589362.K9xjy8nvKO-- From owner-freebsd-pf@FreeBSD.ORG Sat Dec 30 17:00:02 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A05C116A407 for ; Sat, 30 Dec 2006 17:00:02 +0000 (UTC) (envelope-from peter@bsdly.net) Received: from skapet.datadok.no (skapet.datadok.no [194.54.107.19]) by mx1.freebsd.org (Postfix) with ESMTP id 4C72213C441 for ; Sat, 30 Dec 2006 17:00:02 +0000 (UTC) (envelope-from peter@bsdly.net) Received: from thingy.bsdly.net ([10.168.103.11] helo=thingy.datadok.no.bsdly.net ident=peter) by skapet.datadok.no with esmtp (Exim 4.62) (envelope-from ) id 1H0hAn-0005Kc-MH for freebsd-pf@freebsd.org; Sat, 30 Dec 2006 17:35:05 +0100 To: freebsd-pf@freebsd.org References: <499c70c0612290305w11eee312ma02e482b69e77f01@mail.gmail.com> From: peter@bsdly.net (Peter N. M. Hansteen) Date: Sat, 30 Dec 2006 17:35:03 +0100 In-Reply-To: <499c70c0612290305w11eee312ma02e482b69e77f01@mail.gmail.com> (Abdullah Al-Marrie's message of "Fri, 29 Dec 2006 14:05:36 +0300") Message-ID: <87vejtuytk.fsf@thingy.datadok.no> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: rate limit with pf instead of IPFW 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, 30 Dec 2006 17:00:02 -0000 "Abdullah Al-Marrie" writes: > I checked http://home.nuug.no/~peter/pf/en/bruteforce.html > > I still didn't find something in the faq covers table > persist , do I need to create a file like /etc/bruteforce or no need > for that and will be stored in kernel until they expire or I reboot > the box? You can load data into a table from a file (or for that matter dump table contents to a file) if you like. If it's important to keep the table contents across reboots, you probably want to do something like $ sudo pfctl -t foo -T show >/etc/tables/foo or perhaps at regular intervals from cron, and declare your table something like table persist file /etc/tables/foo > as su I type pfctl -t foo -Tl -f /etc/pf.conf but it returns nothing. If you want to show table contents, a $ sudo pfctl -t foo -T show should be sufficient. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds From owner-freebsd-pf@FreeBSD.ORG Sat Dec 30 18:23:25 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 410D816A403 for ; Sat, 30 Dec 2006 18:23:25 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id BC01C13C458 for ; Sat, 30 Dec 2006 18:23:24 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so4045458uge for ; Sat, 30 Dec 2006 10:23:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K//cqP1xC0oaAZu1/piqHfTAAKKPKERytRL92lX0hL+B7lQgeoCOW3kCxFb6Ly9Se8BtQiOBDNFdZfmGKQNmGQE+OW9RDOOhG9/JWUNeJ834jowESfrzZGFlLDBp7KqNUvT6bRVKym+WBfw4VYmOww8VtXWjVDuAahDZacEuGtU= Received: by 10.66.244.10 with SMTP id r10mr24115610ugh.1167503003282; Sat, 30 Dec 2006 10:23:23 -0800 (PST) Received: by 10.67.27.15 with HTTP; Sat, 30 Dec 2006 10:23:22 -0800 (PST) Message-ID: <499c70c0612301023k25a801d4h8ef13ff1bebd5dbe@mail.gmail.com> Date: Sat, 30 Dec 2006 21:23:22 +0300 From: "Abdullah Al-Marrie" To: "Peter N. M. Hansteen" In-Reply-To: <87vejtuytk.fsf@thingy.datadok.no> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <499c70c0612290305w11eee312ma02e482b69e77f01@mail.gmail.com> <87vejtuytk.fsf@thingy.datadok.no> Cc: freebsd-pf@freebsd.org Subject: Re: rate limit with pf instead of IPFW 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, 30 Dec 2006 18:23:25 -0000 On 12/30/06, Peter N. M. Hansteen wrote: > "Abdullah Al-Marrie" writes: > > > I checked http://home.nuug.no/~peter/pf/en/bruteforce.html > > > > I still didn't find something in the faq covers table > > persist , do I need to create a file like /etc/bruteforce or no need > > for that and will be stored in kernel until they expire or I reboot > > the box? > > You can load data into a table from a file (or for that matter dump > table contents to a file) if you like. If it's important to keep the > table contents across reboots, you probably want to do something like > > $ sudo pfctl -t foo -T show >/etc/tables/foo > > or perhaps at regular intervals from cron, and declare your table > something like > > table persist file /etc/tables/foo > > > as su I type pfctl -t foo -Tl -f /etc/pf.conf but it returns nothing. > > If you want to show table contents, a > > $ sudo pfctl -t foo -T show > > should be sufficient. > > -- > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ > "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" > 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds > _______________________________________________ > 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" > Ok, I think it works now, but I'm sure I missed something, since it doesn't block the flooder. # Normalization: reassemble fragments and resolve or reduce traffic ambiguities. #scrub in all scrub in on $ext_if all fragment reassemble min-ttl 15 max-mss 1400 scrub in on $ext_if all no-df scrub on $ext_if all reassemble tcp # Filtering: the implicit first two rules are pass in all pass out all # Pass all 'quick' on localhost loopback device pass quick on lo0 all ## Default DENY & Log filter rules block in log all block out log all # Drop our 'badguys' 'quick' with no reply or logging. block in quick on $ext_if from to any # Pass in rules for Various services defined above. Using 'synproxy-state' for # basic dDoS mitigation on TCP services. pass in on $ext_if proto tcp from any to $ext_if port $tcp_services flags S/SA synproxy state pass quick proto tcp from any to port 80 \ flags S/SA keep state \ (max-src-conn-rate 3/3, \ overload flush global) # Pass UDP keeping state pass in on $ext_if proto udp from any to $ext_if port $udp_services keep state # Pass ICMP Type 8 (echo-reply) only with state pass in on $ext_if inet proto icmp all icmp-type $icmp_types keep state # Pass FTP pass in quick on $ext_if proto tcp from any to any port 21 flags S/SA keep state pass in quick on $ext_if proto tcp from any to any port > 49151 keep state # Pass out rule allowing all with modulate state pass out on $ext_if proto tcp all modulate state flags S/SA # Pass out rules for UDP, ICMP pass out on $ext_if proto { udp, icmp } all keep state # End ---- Here is the pfctl -s a output: self tcp 66.90.105.115:80 <- 86.142.37.237:1086 TIME_WAIT:TIME_WAIT self tcp 66.90.105.115:80 <- 211.213.208.237:3698 TIME_WAIT:TIME_WAIT self tcp 66.90.105.115:80 <- 88.72.57.238:1345 TIME_WAIT:TIME_WAIT self tcp 66.90.105.115:80 <- 88.72.57.238:1150 TIME_WAIT:TIME_WAIT self tcp 66.90.105.115:80 <- 82.253.27.239:3079 TIME_WAIT:TIME_WAIT self tcp 66.90.105.115:80 <- 85.24.126.240:1063 TIME_WAIT:TIME_WAIT self tcp 66.90.105.115:80 <- 200.227.72.245:40219 TIME_WAIT:TIME_WAIT self tcp 66.90.105.115:80 <- 84.61.12.247:1537 TIME_WAIT:TIME_WAIT self tcp 66.90.105.115:80 <- 62.21.114.254:27475 TIME_WAIT:TIME_WAIT self tcp 66.90.105.115:80 <- 62.21.114.254:27476 TIME_WAIT:TIME_WAIT SOURCE TRACKING NODES: 83.26.19.2 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 84.57.19.6 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 83.100.235.6 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 125.191.104.7 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 212.51.52.8 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 213.63.67.8 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 81.245.169.9 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 89.129.142.13 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 89.252.21.14 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 85.226.46.14 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 89.19.164.14 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 86.107.53.15 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 85.69.215.16 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 82.197.246.17 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 86.214.188.19 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 88.118.233.20 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 212.116.219.21 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 83.31.175.22 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 83.209.10.24 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 87.20.97.26 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 200.92.206.26 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 84.183.16.29 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 193.189.116.29 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 84.248.32.32 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 87.217.145.32 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 87.110.165.33 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 80.228.202.36 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 89.252.13.37 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 85.168.152.39 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 58.141.35.42 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 81.64.49.42 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 82.155.36.47 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 68.116.187.47 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 83.26.240.49 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 89.38.29.52 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 86.1.54.52 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 62.241.71.52 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 195.96.124.52 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 87.160.206.52 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 81.45.251.54 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 88.118.183.55 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 80.228.183.56 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 84.77.56.57 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 195.161.7.61 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 83.22.187.61 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 218.172.158.64 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 83.6.223.74 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 85.24.124.75 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 213.246.243.78 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 84.175.28.79 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 200.162.227.80 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 89.104.6.81 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 85.186.130.81 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 62.205.75.83 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 83.25.232.84 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 84.59.45.85 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 80.109.76.87 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 211.124.236.87 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 195.229.242.90 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 80.102.187.92 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 213.145.113.93 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 217.23.253.94 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 84.139.217.97 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 82.83.17.100 -> 0.0.0.0 ( states 2, connections 0, rate 0.0/3s ) 88.72.50.102 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 84.114.143.102 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 85.108.202.103 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 84.193.175.104 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 89.29.13.106 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 85.24.122.106 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 24.144.23.109 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 62.178.102.109 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 86.55.14.110 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 83.128.33.112 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 86.138.228.113 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 70.83.87.118 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 62.117.2.119 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 219.248.23.125 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 87.103.90.126 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 81.193.178.127 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 201.250.230.128 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 86.128.204.129 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 85.186.140.132 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 166.87.255.132 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 219.241.253.133 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 83.181.87.134 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 81.185.151.135 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 86.106.122.137 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 86.55.94.139 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 81.68.72.143 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 80.142.233.144 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 83.25.212.147 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 81.182.101.149 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 86.106.250.150 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 85.179.198.151 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 82.247.63.152 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 84.73.75.152 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 210.64.230.153 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 87.166.211.155 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 24.37.213.158 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 81.182.183.159 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 83.26.225.161 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 83.221.70.166 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 86.217.158.166 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 83.26.241.166 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 81.53.206.168 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 85.168.112.172 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 88.154.113.173 -> 0.0.0.0 ( states 2, connections 0, rate 0.0/3s ) 85.61.10.174 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 62.234.60.176 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 80.217.177.176 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 195.3.113.178 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 81.56.180.178 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 84.147.210.179 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 62.39.229.180 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 212.183.222.181 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 88.77.15.182 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 82.142.157.182 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 83.61.148.184 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 84.190.253.184 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 82.217.97.185 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 84.165.218.185 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 88.64.8.187 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 195.20.106.191 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 88.107.186.195 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 83.13.15.202 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 194.78.199.202 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 86.105.44.210 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 60.237.217.211 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 88.65.173.222 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 84.61.224.224 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 81.152.208.225 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 62.45.15.226 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 89.132.25.228 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 80.224.245.229 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 88.73.137.230 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 81.131.52.233 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 217.151.136.233 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 62.178.227.233 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 86.142.37.237 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 211.213.208.237 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 88.72.57.238 -> 0.0.0.0 ( states 2, connections 0, rate 0.0/3s ) 82.253.27.239 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 85.24.126.240 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 84.61.40.244 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 200.227.72.245 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 201.21.132.246 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 217.23.182.246 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 84.61.12.247 -> 0.0.0.0 ( states 1, connections 0, rate 0.0/3s ) 87.19.245.252 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 81.40.16.254 -> 0.0.0.0 ( states 0, connections 0, rate 0.0/3s ) 62.21.114.254 -> 0.0.0.0 ( states 2, connections 0, rate 0.0/3s ) INFO: Status: Enabled for 0 days 00:02:57 Debug: Urgent Hostid: 0x4a67045a State Table Total Rate current entries 112 searches 34551 195.2/s inserts 3658 20.7/s removals 3546 20.0/s Counters match 15284 86.4/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 350 2.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s TIMEOUTS: tcp.first 120s tcp.opening 30s tcp.established 86400s tcp.closing 900s tcp.finwait 45s tcp.closed 90s tcp.tsdiff 30s udp.first 60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 10s adaptive.start 0 states adaptive.end 0 states src.track 0s LIMITS: states hard limit 10000 src-nodes hard limit 10000 frags hard limit 5000 TABLES: foo OS FINGERPRINTS: 293 fingerprints loaded Could you suggest what shall I do with this case? -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/