From owner-freebsd-pf@FreeBSD.ORG Sat May 10 23:16:48 2014 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 453CA253 for ; Sat, 10 May 2014 23:16:48 +0000 (UTC) Received: from zoom.lafn.org (zoom.lafn.org [108.92.93.123]) by mx1.freebsd.org (Postfix) with ESMTP id 1C71B1A4E for ; Sat, 10 May 2014 23:16:47 +0000 (UTC) Received: from [10.0.1.3] (static-71-177-216-148.lsanca.fios.verizon.net [71.177.216.148]) (authenticated bits=0) by zoom.lafn.org (8.14.7/8.14.7) with ESMTP id s4ANGga0036913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 10 May 2014 16:16:43 -0700 (PDT) (envelope-from bc979@lafn.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Unexpected pf behavior From: Doug Hardie In-Reply-To: Date: Sat, 10 May 2014 16:16:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7782AB7B-59BC-4A31-95FA-3EDF408AA507@lafn.org> To: Brandon Vincent X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.98 at zoom.lafn.org X-Virus-Status: Clean Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18 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, 10 May 2014 23:16:48 -0000 On 10 May 2014, at 15:14, Brandon Vincent = wrote: > Doug, >=20 > As long as you are on the same LAN/broadcast domain, it would be = pretty easy to use a program like Nmap with the "-S, --source-ip" = parameter to spoof the source IP. >=20 > Would you mind sharing the rule that caused this problem? >=20 > Brandon Vincent >=20 >=20 > On Sat, May 10, 2014 at 2:34 PM, Doug Hardie wrote: > I have a pf rule (FreeBSD 9.2) that uses a table to block access from = specific networks. This morning I found the following situation: >=20 > 12 attempts from an address in one of the blocked network to access = the server. All were blocked and marked as such with the proper rule = number in pflog. >=20 > 10 succeeding connections that were passed through to the port. These = were logged by the process listening on that port. >=20 > There were no changes to the rules, reboots, etc. during that time. = This all transpired in about 10 minutes. A dump of the table shows the = proper address range. I am not logging the pass throughs so only the = original 12 blocks are in the logs. I have never seen anything like = this in the past. Is there some way I can test a specific IP address = and have pf tell me what it would do if it received a packet from that = address? >=20 nmap does a good test. Took awhile to figure out how to make it spoof = properly though. Unfortunately I can't make pf fail. It blocks = everything I send from that range. I guess I'll just have to monitor = this a lot closer.=