On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote:
Am 02.08.2016 um 05:08 schrieb Julian Elischer <[email protected]>:
looking for thoughts from people who know the new IPFW features well..
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.
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?).
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:
$ 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
...
Given that ...
0x4445 = 'DE'
0x4252 = 'BR'
0x5553 = 'US'
well it would have to be the decimal value so DE would be 6869, as
while 4445 works 444F is a problem :-)
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.
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..
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.
..., IT people who know by heart the low ASCII table like chemists (are
supposed to) know the periodic table of the elements, this should be not too
hard to remember.
true
Another way would be to just put 'action numbers' in the tablearg field and
have a few actions, shared by countries, but the trouble comes when you want to
change the action for a country, you need to rewrite potentially thousands of
entries (USA has over 15800 allocations).
Two or more geoip commands can be used for populating ipfw tables for different
utilization in ipfw directives:
# Europe
geoip -t "FR:IT:DE:NL:BE:GB:..." -n 1 -x | ipfw -q > /dev/stdin
# North America
geoip -t "US:CA" -n 2 -x | ipfw -q > /dev/stdin
# South America
geoip -t "AR:BR:UR:CL:PY:BO:PE..." -n 3 -x | ipfw -q > /dev/stdin
...
A second way woudl be to somehow map the tablearg of the country, into a table
of actions. effectively doing two levels of lookup.
The first table converting IP addresses to a country number and a second lookup
converting that to an action.
the only trouble is that I don't know of a way to do that. If the new changes
allow that, and anyone knows how, please let me know :-).
Looking-up a given IP in the totally balanced binary search tree takes on a
decent system on average about 10-20 nanoseconds. So in theory 50 to 100
million packets per second could be filtered by this algorithm. In order to
come more close to this performance in reality, it might be an option to move
the search algorithm into ipfw.
Best regards
Rolf
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[email protected]"
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[email protected]"
