Date: Mon, 13 Oct 2014 15:03:44 -0700 From: Laszlo Danielisz <laszlo_danielisz@yahoo.com> To: Daniel Hartmeier <daniel@benzedrine.cx> Cc: "freebsd-pf@freebsd.org" <freebsd-pf@freebsd.org> Subject: Re: referer filtering Message-ID: <1413237824.91751.YahooMailNeo@web160702.mail.bf1.yahoo.com> In-Reply-To: <20140926112213.GA18108@insomnia.benzedrine.cx> References: <1411669441.95769.YahooMailNeo@web160705.mail.bf1.yahoo.com> <20140926112213.GA18108@insomnia.benzedrine.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Thank you Daniel! On Friday, September 26, 2014 1:51 PM, Daniel Hartmeier <daniel@benzedrine.cx> wrote: On Thu, Sep 25, 2014 at 11:24:01AM -0700, Laszlo Danielisz via freebsd-pf wrote: > I was wondering how is possible to accept a connection, lets say on port 80 only if it comes from a specified referer. > Let's say there is a link on server A (IP 1.1.1.1) pointing to server B (IP 2.2.2.2). And server B will only accept the connection if it was sent by A. You mean filtering based on a HTTP Referer: header? pf doesn't work on that layer at all. Technically, B has to accept the client's connection and read the HTTP request (for the Referer: header) to make its decision. It can produce an error (or redirect) or close the connection, but "not accepting the connection" is impossible. You'd have to do this at the application layer, e.g. Apache has modules that allow access control based on HTTP headers[1], or use a HTTP proxy like squid (pf can assist redirecting to it). Also note that the referer header isn't always reliable, as it can be faked easily[2]. HTH, Daniel [1] http://www.uiowa.edu/server/manual/mod/mod_access_referer.html#motivation [2] http://www.stardrifter.org/refcontrol/ _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Tue Oct 14 09:40:38 2014 Return-Path: <owner-freebsd-pf@FreeBSD.ORG> Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FA8310C for <freebsd-pf@freebsd.org>; Tue, 14 Oct 2014 09:40:38 +0000 (UTC) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.105]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail1.bemta14.messagelabs.com", Issuer "VeriSign Class 3 International Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE7D182 for <freebsd-pf@freebsd.org>; Tue, 14 Oct 2014 09:40:37 +0000 (UTC) Received: from [85.158.140.211:50505] by server-1.bemta-14.messagelabs.com id 80/AE-24760-AFDEC345; Tue, 14 Oct 2014 09:33:46 +0000 X-Env-Sender: Aleksej.Spenst@harman.com X-Msg-Ref: server-4.tower-194.messagelabs.com!1413279225!20262222!1 X-Originating-IP: [194.121.90.173] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2559 invoked from network); 14 Oct 2014 09:33:45 -0000 Received: from unassigned (HELO HIKAWSEXHC04.ad.harman.com) (194.121.90.173) by server-4.tower-194.messagelabs.com with AES128-SHA encrypted SMTP; 14 Oct 2014 09:33:45 -0000 Received: from HIKAWSEXMB02.ad.harman.com ([169.254.2.176]) by HIKAWSEXHC04.ad.harman.com ([172.16.1.114]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 11:33:45 +0200 From: "Spenst, Aleksej" <Aleksej.Spenst@harman.com> To: "freebsd-pf@freebsd.org" <freebsd-pf@freebsd.org> Subject: Fragmented packets are not redirected Thread-Topic: Fragmented packets are not redirected Thread-Index: Ac/nkfAvIWGsjtOvSuyBBqYZc4mz4g== Date: Tue, 14 Oct 2014 09:33:44 +0000 Message-ID: <CBA35483CE5B4D4B804BF128A77A61650E99EC6B@HIKAWSEXMB02.ad.harman.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.102.147] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" <freebsd-pf.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-pf>, <mailto:freebsd-pf-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-pf/>; List-Post: <mailto:freebsd-pf@freebsd.org> List-Help: <mailto:freebsd-pf-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-pf>, <mailto:freebsd-pf-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 14 Oct 2014 09:40:38 -0000 Hi All, I have one problem with redirection of the fragmented packets. My use case: A mobile phone sends the RTP video stream to my server. The server has the = pf installed. All RTP packets are redirected from the server to my PC: |Mobile|------>---RTP---->-----|Server|------->---RTP--->-----|PC| The small RTP packets are redirected to my PC without any problems. The problem is with the large RTP packets that are fragmented and transmitt= ed in several IP fragments. These IP fragments are not redirected to PC. Th= e redirection rule at the server: rdr on wlan0 proto udp from any to (self) port 9870 -> 192.168.0.1 port 987= 0 | S e r v e r | ->--|wlan0 eth0|-->-------|PC 192.168.0.1| It is clear that if the IP fragments are not reassembled at the server they= cannot be redirected since the redirection rule is written for UDP packets= . That is why I have this scrub rule at the very beginning of my pf.conf: scrub in on wlan0 all I thought that this rule should reassemble all the incoming fragments. The = reassembled UDP packets should be then correctly passed through the rdr rul= e and redirected to my PC. But this does not happen. Do you have any ideas/tips? Thanks a lot! Aleksej.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1413237824.91751.YahooMailNeo>