Date: Wed, 3 Aug 2016 18:53:38 -0300 From: "Dr. Rolf Jansen" <rj@obsigna.com> To: ipfw mailing list <ipfw@freebsd.org> Cc: Julian Elischer <julian@freebsd.org> Subject: Re: your thoughts on a particualar ipfw action. Message-ID: <DA5D1FAE-79D9-4A19-8EFB-951C926265A0@obsigna.com> In-Reply-To: <9fb7a057-aa02-9743-db9f-d4eef6df16f0@freebsd.org> References: <7f573fc4-2820-ebd3-7b15-d8a1cd023372@freebsd.org> <AE91DE1F-82B5-413C-826C-085231906C5F@obsigna.com> <9fb7a057-aa02-9743-db9f-d4eef6df16f0@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 03.08.2016 um 11:13 schrieb Julian Elischer <julian@freebsd.org>: >=20 > On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote: >>> Am 02.08.2016 um 05:08 schrieb Julian Elischer <julian@freebsd.org>: >>>=20 >>> looking for thoughts from people who know the new IPFW features = well.. >>>=20 >>>=20 >>> A recent addition to our armory is the geoip program that, given an = address can tell you what country it is in and given a country code, can = give an ipfw table that describes all the ip addresses in that country. >>>=20 >>> SO I was thinking how to use this, and the obvious way would be to = have a set of rules for each country, and use the "skipto tablearg" = facility to skip to the right rules for each country. But the trouble is = that a tablearg skipto is very inefficient. It's also a hard thing to = set up with a set of rules for each country (how many countries are = there in the internet allocation system?). >>=20 >> As of today a total of 236 country codes are in use for IPv4 = delegations. If this helps for anything, a command line switch to the = geoip tool could be added for letting it output the country code (as the = hex encoded CC taken as a plain decimal integer) as the value for the = given table entry. In the moment you can give one value for all entries = generated by geoip, with this switch set, the output of geoip could look = like: >>=20 >> $ geoip -t "DE:BR:US" -x >> ... >> table 0 add 93.157.48.0/21 4445 >> table 0 add 93.158.236.0/22 4252 >> table 0 add 93.159.96.0/19 4445 >> table 0 add 93.159.248.0/21 4445 >> table 0 add 93.180.72.0/21 4445 >> table 0 add 93.180.152.0/21 4445 >> table 0 add 93.181.0.0/18 4445 >> table 0 add 93.183.0.0/18 5553 >> ... >>=20 >> Given that ... >> 0x4445 =3D 'DE' >> 0x4252 =3D 'BR' >> 0x5553 =3D 'US' >=20 > well it would have to be the decimal value so DE would be 6869, as = while 4445 works 444F is a problem :-) Yes, you're right, I was taken away by the wave of enthusiasm, before = thinking about the subject up to the end. > 0x444F would work but we waste even more address space. You'd have to = multiply the numbers by some scaler, because adjacent numbers would not = be enough for one rule to do something and another rule to skip on to = somewhere else. (well, you could have multiple rules at the same number = but that has its limitations. > The idea would certainly work. it would mean setting aside all the = rules between 6565 and 9090 however. > A more compact encoding could be something like ((name[0]-'A') * = 32)+(name[1]-'A')) multiplied by some 'step' (maybe 10 by default) and = offset by a given offset. >=20 > so AF (Afghanistan) would be the first 0*32+5 * 10 would give an = offset of 50.. plus a user supplied offset turns it into say, 15050.. I understand the reasons, however, any complicated encoding will defeat = the idea of the value can be sort of numeric mnemonic for the country = code =E2=80=93 well, so it is. I elaborated on your idea and came-up = with the following formula: val =3D (C1-60)*1000 + C2*10 + offset. The = offset can be given as the parameter to the -x flag. $ geoip -t "DE:BR:US" -4 -x 30000 ... table 0 add 93.157.48.0/21 38690 table 0 add 93.158.236.0/22 36820 table 0 add 93.159.96.0/19 38690 table 0 add 93.159.248.0/21 38690 table 0 add 93.180.72.0/21 38690 table 0 add 93.180.152.0/21 38690 table 0 add 93.181.0.0/18 38690 table 0 add 93.183.0.0/18 55830 ... The limits (without offset) are: AA =3D 5650 -- actually AD =3D 5680 ZZ =3D 30900 With this formula, the offset must be less than 34735. Although, this = wastes a considerable amount of rule number space, the advantage is that = the numbers are still accessible by mental arithmetic, and the other = constraint of having a step > 1 is fulfilled as well. Anyway, this one = is not graved in stone, we can agree on another one. > or there could be a translation into iso3166 numeric codes where = Afghanistan is 004, but then you have the worry of keeping the data up = to date as they add new country codes, which in my opinion makes it a = bad solution. Agreed, too much dependencies, let's forget the numeric iso codes. BTW: The ipdb tools are now IPv6 aware. $ geoip 2001:1900:2254:206a::50:5 2001:1900:2254:206a::50:5 in 2001:1900:0:0:0:0:0:0 - = 2001:1900:ffff:ffff:ffff:ffff:ffff:ffff in US $ geoip -t "DE:BR:US" -p ... ... 217.194.64.0/20 217.194.224.0/20 217.195.0.0/20 217.195.32.0/20 217.197.80.0/20 217.198.128.0/20 217.198.240.0/20 217.199.64.0/20 217.199.192.0/20 217.224.0.0/11 2001:400:0:0:0:0:0:0/32 2001:408:0:0:0:0:0:0/32 2001:418:0:0:0:0:0:0/32 2001:420:0:0:0:0:0:0/32 2001:428:0:0:0:0:0:0/32 2001:430:0:0:0:0:0:0/32 2001:438:0:0:0:0:0:0/32 ... ... $ geoip -t "" -p | wc -l 137097 For processing only IPv4 addresses, add the -4 switch (this reproduces = the old behaviour) $ geoip -4 -t "" -p | wc -l 106637 For processing only IPv6 addresses, add the -6 switch $ geoip -6 -t "" -p | wc -l 30460 106637+30460 =3D 137097 After running 'make install' of the new version, the IP database needs = to be updated using the ipdb-update.sh script. This will now generate = two binary database files (*.v4 and *.v6). Best regards Rolf
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DA5D1FAE-79D9-4A19-8EFB-951C926265A0>