Date: Wed, 27 Jul 2016 00:26:37 +0800 From: Julian Elischer <julian@freebsd.org> To: freebsd-ipfw@freebsd.org Subject: Re: ipfw divert filter for IPv4 geo-blocking Message-ID: <ffaad855-2a2e-6034-e9fe-5b685276a2b9@freebsd.org> In-Reply-To: <9d0a3ad8-a66a-c527-3906-3290b8d58476@rlwinm.de> References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <9d0a3ad8-a66a-c527-3906-3290b8d58476@rlwinm.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26/07/2016 1:01 AM, Jan Bramkamp wrote: > > > On 25/07/16 16:28, Dr. Rolf Jansen wrote: >> I have written a ipfw divert filter daemon for IPv4 geo-blocking. >> It is working flawlessly on two server installations since a week. >> >> Anyway, I am still in doubt whether I do the blocking in the >> correct way. Once the filter receives a packet from the respective >> divert socket it looks up the country code of the source IP in the >> IP-Ranges database, and if the country code shall be allowed then >> it returns the unaltered packet via said socket, otherwise, the >> filter does no further processing, so the packet is effectively >> gone, lost, dropped, discarded, or whatever would be the correct >> terminology. Is this the really the correct way of denying a >> packet, or is it necessary to inform ipfw somehow about the >> circumstances, so it can run a proper dropping procedure? >> >> I uploaded the filter + accompanying tools to GitHub >> >> https://github.com/cyclaero/ipdb >> >> Many thnaks for any advices in advance. > > I would use a set of IPFW tables with skipto/call tablearg rules > instead. > Use the daemon to maintain the IPFW tables. I assume your database > is a list of of (CIDR, country code) pairs. In that case the daemon > config should probably map from sets of country codes to table > values e.g. > > table 1 { DE, NL } -> 10000, > { US, UK } -> 10100 > table 2 { CN, KO, TR } -> 20000 why multiple tables? if you load the table at once you can assign a country code as the tablearg for every run of addresses. all in one table. > > Next the daemon would calculate the minimal set of table entries to > match these policies exactly and patch the kernel table contents if > the database changes. > > This design avoids the userspace<->kernel copies without losing > flexibility. > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ffaad855-2a2e-6034-e9fe-5b685276a2b9>