Re: ipfw divert filter for IPv4 geo-blocking

2016-07-28 Thread Dr. Rolf Jansen 

> Am 27.07.2016 um 12:31 schrieb Julian Elischer :
> On 27/07/2016 9:36 PM, Dr. Rolf Jansen wrote:
>>> Am 26.07.2016 um 23:03 schrieb Julian Elischer :
>>> On 27/07/2016 3:06 AM, Dr. Rolf Jansen wrote:
 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
 
 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?
>>> The format for using tables directly is the same as that used for routing 
>>> tables.
>>> …
>>> table 5 add 1.1.1.0/32 1000
>>> …
>>> your application becomes an application for configuring the firewall.
>>> (which you do by feeding commands down a pipe to ipfw, which is started as 
>>> 'ipfw -q /dev/stdin')
>> I finished adding a second usage form for the geoip tool, namely generation 
>> of ipfw table construction directives filtered by country codes.
> wow, wonderful!
> 
> with that tool, and ipfw tables we have a fully functional geo 
> blocking/munging solution in about 4 lines of shell script.

Unfortunately, I finally discovered that ipfw tables as they are, are 
unsuitable for the given purpose, because for some reason ipfw mangles about 20 
% of the passed IP address/masklen pairs.

For example:

# ipfw table 1 add 201.222.20.0/20
# ipfw table 1 list
-->  201.222.16.0/20 0

$ geoip 201.222.20.1
--> 201.222.20.1 in 201.222.20.0-201.222.31.255 in BR

$ geoip 201.222.16.1
--> 201.222.16.1 in 201.222.16.0-201.222.19.255 in AR

Effectively, I asked ipfw to add an IP-range of Brazil to table 1, but it 
actually added another one which belongs to Argentina. This doesn't make too 
much sense, does it?

For the time being I switched my servers back to geo-blocking with the divert 
filter daemon.

Best regards

Rolf

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: ipfw divert filter for IPv4 geo-blocking

2016-07-28 Thread Lee Brown 
That makes sense to me.  Your /20 range encompasses 201.222.16.0 -
201.222.31.255.
If you want 201.222.20.0-201.222.31.255, you'll need 3 ranges:

201.222.20.0/22 (201.222.20.0-201.222.23.255)
201.222.24.0/22 (201.222.24.0-201.222.27.255)
201.222.28.0/22 (201.222.28.0-201.222.31.255)

this  helps :)

On Thu, Jul 28, 2016 at 7:21 PM, Dr. Rolf Jansen  wrote:

>
> > Am 27.07.2016 um 12:31 schrieb Julian Elischer :
> > On 27/07/2016 9:36 PM, Dr. Rolf Jansen wrote:
> >>> Am 26.07.2016 um 23:03 schrieb Julian Elischer :
> >>> On 27/07/2016 3:06 AM, Dr. Rolf Jansen wrote:
>  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
> 
>  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?
> >>> The format for using tables directly is the same as that used for
> routing tables.
> >>> …
> >>> table 5 add 1.1.1.0/32 1000
> >>> …
> >>> your application becomes an application for configuring the firewall.
> >>> (which you do by feeding commands down a pipe to ipfw, which is
> started as 'ipfw -q /dev/stdin')
> >> I finished adding a second usage form for the geoip tool, namely
> generation of ipfw table construction directives filtered by country codes.
> > wow, wonderful!
> >
> > with that tool, and ipfw tables we have a fully functional geo
> blocking/munging solution in about 4 lines of shell script.
>
> Unfortunately, I finally discovered that ipfw tables as they are, are
> unsuitable for the given purpose, because for some reason ipfw mangles
> about 20 % of the passed IP address/masklen pairs.
>
> For example:
>
> # ipfw table 1 add 201.222.20.0/20
> # ipfw table 1 list
> -->  201.222.16.0/20 0
>
> $ geoip 201.222.20.1
> --> 201.222.20.1 in 201.222.20.0-201.222.31.255 in BR
>
> $ geoip 201.222.16.1
> --> 201.222.16.1 in 201.222.16.0-201.222.19.255 in AR
>
> Effectively, I asked ipfw to add an IP-range of Brazil to table 1, but it
> actually added another one which belongs to Argentina. This doesn't make
> too much sense, does it?
>
> For the time being I switched my servers back to geo-blocking with the
> divert filter daemon.
>
> Best regards
>
> Rolf
>
> ___
> freebsd-ipfw@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: ipfw divert filter for IPv4 geo-blocking

2016-07-28 Thread Julian Elischer 

On 29/07/2016 10:48 AM, Lee Brown wrote:

That makes sense to me.  Your /20 range encompasses 201.222.16.0 -
201.222.31.255.
If you want 201.222.20.0-201.222.31.255, you'll need 3 ranges:
whether it makes sense depends on whether you add the other ranges as 
well with  the default result.
Your daemon has the entire set loaded so it can exclude other internal 
ranges, however it looks like you have only provided

ipfw with partial information.


you'd need to add:

201.222.20.0/20  1
201.222.16.0/22  0

or more correctly what Lee showed above

either the imput data is incorrect, or your cidr aggregation  code has a bug.
because 201.222.20.0/20 (well more correctly "misleading") cidr description).
It implies 201.222.16.0/20  because if you mask 201.222.20.0 with 255.255.240.0 
 (/20) that's what you get.

observe:
soekris# route add 201.222.20.0/20 127.0.0.1
add net 201.222.20.0: gateway 127.0.0.1
soekris# netstat -rn
Routing tables

Internet:
DestinationGatewayFlagsRefs  Use  Netif Expire
default192.168.0.1UGS 0  9082198vr2
[...]
201.222.16.0/20127.0.0.1  US  00lo0
[...]

to make this work correctly you'd either need lee's answer, or you 
need to give it more information:

201.222.16.0/20  {result for brazil}
201.222.16.0/22  {default result, to get subtracted from the above.
your program give s the correct result because it has all the 
information, including the AR information

but you didn't tell ipfw about that.
I suggest you need either input data sanitization, or to fix our 
output code to give the correct subranges.

becasue 201.222.16.0/20 is definately bad input to ipfw.



201.222.20.0/22 (201.222.20.0-201.222.23.255)
201.222.24.0/22 (201.222.24.0-201.222.27.255)
201.222.28.0/22 (201.222.28.0-201.222.31.255)

this  helps :)

On Thu, Jul 28, 2016 at 7:21 PM, Dr. Rolf Jansen  wrote:


Am 27.07.2016 um 12:31 schrieb Julian Elischer :
On 27/07/2016 9:36 PM, Dr. Rolf Jansen wrote:

Am 26.07.2016 um 23:03 schrieb Julian Elischer :
On 27/07/2016 3:06 AM, Dr. Rolf Jansen wrote:

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

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?

The format for using tables directly is the same as that used for

routing tables.

…
table 5 add 1.1.1.0/32 1000
…
your application becomes an application for configuring the firewall.
(which you do by feeding commands down a pipe to ipfw, which is

started as 'ipfw -q /dev/stdin')

I finished adding a second usage form for the geoip tool, namely

generation of ipfw table construction directives filtered by country codes.

wow, wonderful!

with that tool, and ipfw tables we have a fully functional geo

blocking/munging solution in about 4 lines of shell script.

Unfortunately, I finally discovered that ipfw tables as they are, are
unsuitable for the given purpose, because for some reason ipfw mangles
about 20 % of the passed IP address/masklen pairs.

For example:

# ipfw table 1 add 201.222.20.0/20
# ipfw table 1 list
-->  201.222.16.0/20 0

$ geoip 201.222.20.1
--> 201.222.20.1 in 201.222.20.0-201.222.31.255 in BR

$ geoip 201.222.16.1
--> 201.222.16.1 in 201.222.16.0-201.222.19.255 in AR

Effectively, I asked ipfw to add an IP-range of Brazil to table 1, but it
actually added another one which belongs to Argentina. This doesn't make
too much sense, does it?

For the time being I switched my servers back to geo-blocking with the
divert filter daemon.

Best regards

Rolf

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"




___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: ipfw divert filter for IPv4 geo-blocking

2016-07-28 Thread Ian Smith 
On Thu, 28 Jul 2016 23:21:01 -0300, Dr. Rolf Jansen wrote: > Am 
27.07.2016 um 12:31 schrieb Julian Elischer :
 [..]
 >> wow, wonderful!

 >> with that tool, and ipfw tables we have a fully functional geo
 >> blocking/munging solution in about 4 lines of shell script.

 > Unfortunately, I finally discovered that ipfw tables as they are, are 
 > unsuitable for the given purpose, because for some reason ipfw
 > mangles about 20 % of the passed IP address/masklen pairs.

 > For example:

 > # ipfw table 1 add 201.222.20.0/20
 > # ipfw table 1 list
 > -->  201.222.16.0/20 0

 > $ geoip 201.222.20.1
 > --> 201.222.20.1 in 201.222.20.0-201.222.31.255 in BR

 > $ geoip 201.222.16.1
 > --> 201.222.16.1 in 201.222.16.0-201.222.19.255 in AR

Just to add to what Julian and Lee observed, testing IPs at 

(sourced from LACNIC thence whois.registro.br)

inetnum: 201.222.20/22
aut-num: AS61902
abuse-c: CSJ45
owner: Bahialink - Technology
ownerid: 004.724.687/0001-69
country: BR

So the geoip result for 201.222.20.1 is just wrong - it should return

  201.222.20.0 - 201.222.23.255 (ie, /22)

and not

  201.222.16.0 - 201.222.31.255 (ie, /20)

While the range for 201.222.16.1 is in fact a /22:


[..]
inetnum: 201.222.16/22
status: allocated
aut-num: N/A
owner: G2KHosting S.A.
ownerid: AR-GKSA-LACNIC
responsible: Mauro Ferraro
address: Maipu, 33,
address: 2900 - San Nicolas de los Arroyos - BA
country: AR

 > Effectively, I asked ipfw to add an IP-range of Brazil to table 1, 
 > but it actually added another one which belongs to Argentina. This 
 > doesn't make too much sense, does it?

Not if geoip is returning the wrong address range for 201.222.20.1, no.

 > For the time being I switched my servers back to geo-blocking with 
 > the divert filter daemon.

I don't know what's wrong or where, just that it is ..

How are you getting from geoip's IP range to /maskbits?

cheers, Ian
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"