From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: [PATCH] display rDNS and GeoIP information for used nameservers Date: Wed, 08 Nov 2017 22:58:53 +0100 Message-ID: <20171108225853.1bf0e979.peter.mueller@link38.eu> In-Reply-To: <1510095816.2768.16.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9208563395414401412==" List-Id: --===============9208563395414401412== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, > Hi, >=20 > On Tue, 2017-11-07 at 20:25 +0100, Peter M=C3=BCller wrote: > > Hello Michael, > > =20 > > > Hi, > > >=20 > > > this quite a nice idea, but I have one small problem here which I think= could > > > potentially confuse the users more than it helps. > > >=20 > > > And that is anycast DNS servers. =20 > >=20 > > Oh, yes. *sigh* =20 > > >=20 > > > So for example for the famous Google DNS 8.8.8.8 the GeoIP location wou= ld be US > > > which technically is correct, but I know for a fact that I am using an = instance > > > that is located in the Telehouse which just a few miles away from me an= d not on > > > the other side of the big pond. > > >=20 > > > So can we do anything to make this better and should we? =20 > >=20 > > The answer is simple and gives absolutely no satisfaction: No, we can't. > >=20 > > The (free) GeoIP database IPFire uses is somewhat ugly when it comes to a= nycast > > networks, or even the networks of big DSL companies (see below): By looki= ng at > > the output of "geoiplookup [anycast IP]", there is no chance to see that = something > > is wrong. > >=20 > > Further, there are two problems with these networks: > > (a) Only the company operating an anycast system knows where a certain IP= is > > actually located - as far as I am concerned, there is no (reliable) way t= o guess > > this from outside. Some companies set informative PTR records such as "mu= c-x.y.z.anycast.company.com" > > [muc =3D Munich], but even that does not mean anything in technical terms= . =20 >=20 > Not even they know where you are being routed to in some cases. >=20 > > (b) There is a huge difference between the accuracy of multinational comp= any's > > networks in the free and non-free edition of the GeoIP database. For exam= ple, AOL > > also owns subnets for their customers in Brazil and other countries outsi= de US, > > but the free database returns "US" for any AOL network queried. > > Same goes for special categories such as "A1" (anonymous proxies): Even b= ig Tor > > nodes with static IPs or some huge VPN providers are mostly not listed th= ere. :-| =20 >=20 > Well, the accuracy isn't really there. There is no guarantee the > information is correct or precise and basically this is completely > messy. True. Sometimes I am thinking about building my own country GeoIP database, m= aybe as a holiday project initially... >=20 > There are other things like LOC records in DNS, but unfortunately > nobody seems to be using that. I understand this. As a server operator, I do not want people to know in which city (or building) my devices are located. >=20 > There is an option c) Sometimes it says it in the whois, but that again > is not at all a reliable source of information. Location information on city base is never quite accurate, but at country lev= el, it should be possible for most cases. Well, at the moment, we do not have anything better (see above). Apart from t= hese issues, was the patch okay? Best regards, Peter M=C3=BCller >=20 > > To sum it up: I am aware of these - let's say - inaccuracies. However, I = think we > > need to stay consistent here: If we use GeoIP for firewall rules, which I= consider > > a great feature, we should work with the same information that iptables p= rocesses > > if a user queries an IP address. > >=20 > > This is especially true for the connection tracking table (will send a wo= rking patch > > for this later on), but otherwise, debugging of GeoIP firewall rules beco= mes very > > hard. =20 >=20 > Very true. >=20 > > Just as a remark: It is interesting that the Cloudflare networks are not = listed in > > the GeoIP database anymore (perhaps because they are anycast, too). But a= ccording > > to bug #11482, this is not a good idea. =20 >=20 > I have heard bad things from them that they are not a very nice player. > It is rumored that they are a pain in the rear end... >=20 > -Michael >=20 > > Best regards, > > Peter M=C3=BCller =20 > > >=20 > > > -Michael > > >=20 > > > On Mon, 2017-11-06 at 19:09 +0100, Peter M=C3=BCller wrote: =20 > > > > Display rDNS/PTR record and GeoIP information for used nameservers > > > > on the netexternal.cgi WebUI page. These information might be useful > > > > for debugging. > > > >=20 > > > > Thanks to Matthias Fischer for style improvements. > > > >=20 > > > > Signed-off-by: Peter M=C3=BCller > > > > --- > > > > html/cgi-bin/netexternal.cgi | 25 +++++++++++++++++++++++++ > > > > langs/de/cgi-bin/de.pl | 1 + > > > > langs/en/cgi-bin/en.pl | 1 + > > > > 3 files changed, 27 insertions(+) > > > >=20 > > > > diff --git a/html/cgi-bin/netexternal.cgi b/html/cgi-bin/netexternal.= cgi > > > > index 299612d4c..cd2223ac6 100644 > > > > --- a/html/cgi-bin/netexternal.cgi > > > > +++ b/html/cgi-bin/netexternal.cgi > > > > @@ -25,9 +25,13 @@ use strict; > > > > #use warnings; > > > > #use CGI::Carp 'fatalsToBrowser'; > > > > =20 > > > > +use IO::Socket; > > > > +use Geo::IP::PurePerl; > > > > + > > > > require '/var/ipfire/general-functions.pl'; > > > > require "${General::swroot}/lang.pl"; > > > > require "${General::swroot}/header.pl"; > > > > +require "${General::swroot}/geoip-functions.pl"; > > > > require "${General::swroot}/graphs.pl"; > > > > =20 > > > > my %color =3D (); > > > > @@ -99,6 +103,12 @@ if ( $querry[0] ne~ ""){ > > > > $Lang::tr{'nameserver > > > > '} > > > > > > > > > > > > + $Lang::tr{'flag'} > > > rong> =20 > > > > + > > > > + > > > > + $Lang::tr{'rdns'} > > > rong> =20 > > > > + > > > > + > > > > $Lang::tr{'status'} > > > strong> =20 > > > > > > > > > > > > @@ -138,10 +148,25 @@ END > > > > } > > > > =20 > > > > my $table_colour =3D ($id++ % 2) ? $color{'color22'} : > > > > $color{'color20'}; > > > > + =09 > > > > + my $iaddr =3D inet_aton($nameserver); > > > > + my $rdns =3D gethostbyaddr($iaddr, AF_INET); > > > > + if (!$rdns) { $rdns =3D $Lang::tr{'lookup failed'}; } > > > > + > > > > + my $gi =3D Geo::IP::PurePerl->new(); > > > > + my $ccode =3D $gi->country_code_by_name($nameserver); > > > > + my $fcode =3D lc($ccode); > > > > + my $flag_icon =3D &GeoIP::get_flag_icon($fcode); > > > > =20 > > > > print < > > > > > > > $nameserver > > > > + > > > > + > > > src=3D"$flag_icon" border=3D"0" align=3D"absmiddle" alt=3D"$ccode" =20 > > > > title=3Drumoured"$ccode"> =20 > > > > + > > > > + rumoured > > > > + $rdns > > > > + > > > > > > > > > > > color=3D"$colour">$message =20 > > > > > > > > diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl > > > > index af96a6445..4cf866a3a 100644 > > > > --- a/langs/de/cgi-bin/de.pl > > > > +++ b/langs/de/cgi-bin/de.pl > > > > @@ -1951,6 +1951,7 @@ > > > > 'quick playlist' =3D> 'Quick Playlist', > > > > 'ram' =3D> 'RAM-Speicher', > > > > 'random number generator daemon' =3D> 'Random Number Generator Daemo= n', > > > > +'rdns' =3D> 'rDNS', > > > > 'read bytes' =3D> 'Gelesene Bytes', > > > > 'read list' =3D> 'Liste der Leseberechtigten', > > > > 'real address' =3D> 'Reale Addresse', > > > > diff --git a/langs/en/cgi-bin/en.pl b/langs/en/cgi-bin/en.pl > > > > index 7e4f95ccf..946aba873 100644 > > > > --- a/langs/en/cgi-bin/en.pl > > > > +++ b/langs/en/cgi-bin/en.pl > > > > @@ -1989,6 +1989,7 @@ > > > > 'quick playlist' =3D> 'Quick Playlist', > > > > 'ram' =3D> 'RAM', > > > > 'random number generator daemon' =3D> 'Random Number Generator Daemo= n', > > > > +'rdns' =3D> 'rDNS', > > > > 'read bytes' =3D> 'Read Bytes', > > > > 'read list' =3D> 'list with readonly hosts', > > > > 'real address' =3D> 'Real Address', =20 > >=20 > > =20 --===============9208563395414401412==--