From owner-freebsd-ipfw@freebsd.org Tue Jul 26 19:06:25 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79FECBA519E for ; Tue, 26 Jul 2016 19:06:25 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E7EE61860; Tue, 26 Jul 2016 19:06:24 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1469559980; l=9980; s=domk; d=obsigna.com; h=To:References:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type; bh=MopXyfQZAiw7O+HFoWB+zO6uOE6C6jUWt3AnpgcngaM=; b=hY6HEqEs3B+SdqKNo7a1NWf6ZUR8Wtf/0sKE+vETL63LgMnrhfigL8YhujgFeKmr8uT iFlHnAspUyF47T25zL7RG8ePtQ8ldMl8hm+EX6MPshojqDAnp9SK8/x0F0B4Gu6vitcJy mcdT2pv0v9pRRJIvUmOFadCstsqhFYAZLMk= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhToX1IWHkW4X7v2ImaU2BqdKi+qzh/nYybNiUg== X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02a6dc.virtua.com.br [187.2.166.220]) by smtp.strato.de (RZmta 38.13 DYNA|AUTH) with ESMTPSA id L01561s6QJ6KVG1 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Tue, 26 Jul 2016 21:06:20 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 4FDE82298622; Tue, 26 Jul 2016 16:06:16 -0300 (BRT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: ipfw divert filter for IPv4 geo-blocking From: "Dr. Rolf Jansen" In-Reply-To: Date: Tue, 26 Jul 2016 16:06:14 -0300 Cc: Julian Elischer Message-Id: <9641D08A-0501-4AA2-9DF6-D5AFE6CB2975@obsigna.com> References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> To: freebsd-ipfw@freebsd.org X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 19:06:25 -0000 > Am 26.07.2016 um 13:23 schrieb Julian Elischer : > On 26/07/2016 1:41 AM, Dr. Rolf Jansen wrote: >> Once a week, the IP ranges are compiled from original sources into a = binary sorted table, containing as of today 83162 consolidated range/cc = pairs. On starting-up, the divert daemon reads the binary file in one = block and stores the ranges into a totally balanced binary search tree. = Looking-up a country code for a given IPv4 address in the BST takes on = average 20 nanoseconds on an AWS-EC2 micro instance. I don't know the = overhead of diverting, though. I guess this may be one or two orders of = magnitudes higher. Even though, I won't see any performance issues. >=20 > yes the diversion to user space is not a fast operation. When we wrote = it, fast was 10Mbits/sec. > The firewall tables use a radix tree (*) and might be slower than what = you have, but possibly it might be made up for by not having to do the = divert logic. it's not entorely clear from your description why you look = up a country rather than just a pass/block result, but maybe different = sources can access different countries?. The basic idea was to develop a facility for ipfw for filtering IPv4 = packets by country code - see: https://github.com/cyclaero/ipdb I simply put into /etc/rc.conf: geod_enable=3D"YES" geod_flags=3D"-a DE:BR:US" The -a flag tells, that source IP addresses only from these countries = are allowed (i.e. passed through the filter). I added also a -d flag, = which means deny (i.e. drop packets) from the given list of countries. With that in place, I need to add a respective divert rule to the ipfw = ruleset (the divert port of the geod daemon is 8669, remembering that = 8668 is the port of the natd daemon): ipfw -q add 70 divert 8669 tcp from any to any 80,443 in recv WAN_if = setup > I did similar once using ipfw tables but couldn't find a reliable = source of data. The IP/CC database is compiled from downloads of the daily published = delegation statistics files of the 5 RIR's. I consider the RIR's being = the authoritative source. Anyway, on my systems the IP/CC-database is = updated only weekly, although, daily updating would be possible. I wrote = a shell script for this, that can be executed by a cron job. https://github.com/cyclaero/ipdb/blob/master/ipdb-update.sh = There is another tool called geoip , that I uploaded to GitHub, and that = I use for looking up country codes by IP addresses on the command line. https://github.com/cyclaero/ipdb/blob/master/geoip.c This one could easily be extended to produce sorted IP ranges per CC = that could be fed into tables of ipfw. I am thinking of adding a command = line option for specifying CC's for which the IP ranges should be = exported, something like: geoip -e DE:BR:US:IT:FR:ES=20 And this could print sorted IP-Ranges belonging to the listed countries. = For this purpose, what would be the ideal format for directly feeding = the produced output into ipfw tables? >> Independent from the actual usage case (geo-blocking), let's talk = about divert filtering in general. The original question which is still = unanswered can be generalized to, whether "dropping/denying" a package = simply means 'forget about it' or whether the divert filter is required = to do something more involved, e.g. communicate the situation somehow to = ipfw. >=20 > there is no residual information about the packet in the kernel once = it has been passed to the user process. > so just "forgetting to hand it back" is sufficient to drop it. OK, many thanks, that just answers my original doubt. At least = technically, my daemon handles package dropping correctly, although, = more elegant ways can be imagined to do the same thing. Best regards Rolf=20=