From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] Add GeoIP location to nameservers Date: Tue, 19 Jan 2016 01:30:39 +0000 Message-ID: <1453167039.5665.159.camel@ipfire.org> In-Reply-To: <56936382.1070008@web.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0170937223071320328==" List-Id: --===============0170937223071320328== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi, On Mon, 2016-01-11 at 09:10 +0100, IT Superhack wrote: > Hello Michael, > > Michael Tremer: > > Hi, > > > > On Sun, 2016-01-10 at 17:25 +0100, IT Superhack wrote: > > > Hello Michael, hello Matthias, > > > > > > Michael Tremer: > > > > Just out of curiosity, why do you find this information so > > > > helpful? > > > > > > As Matthias said already, is is more a "nice to have" than > > > something > > > which is seriously needed. > > > > This is not too much of an argument. My argument against this is > > that > > it brings down page load times because of a not too useful > > information. > > > > > I wrote this patch because a friend of mine in France discovered > > > that > > > his ISP assigns DNS servers from Australia and Great Britain, > > > which > > > was slowing down DNS resolving a lot. > > > > I get that and this is actually a pretty good one. > > > > That only leaves resolvers like 8.8.8.8 which will show "US" but > > actually are located at many places around the world. Let's hope > > that > > people don't get the wrong thing from the flag - or actually start > > changing their DNS servers to something else :) > > > > > Therefore I thougt it might be useful to see in which countries > > > your > > > DNS servers are located, just in case you didn't set some by your > > > own. > > > > It is sometimes. Although geographic location doesn't mean that it > > is > > close on the network. > > > > A system in GB is probably not an issue. Australia actually is a > > bit > > far away. > The problem here was something else: A couple of months ago, his ISP > assigned DNS servers in France, which worked quite well and belonged > to the ISP, according to whois information. > > The list of assigned DNS servers must have changed somewhere in the > meantime, and he still does not know why since the ISP does not > answer > related questions. > > So, if your ISP suddenly assigns you DNS servers in a very different > location > than it has done long before, you know that something might be wrong > here. > (The Quantumhand-program of the NSA lists "DNS injection" as a > possible > method to impersonate a server - why not even change the DNS server > to > one they own? Would be much easier...) > [http://securityaffairs.co/wordpress/23129/hacking/quantumhand-nsa-im > personates-facebook-inject-malware.html] Yeah, I get where you are coming from. The flag however won't change much here. A check if the IP address of the DNS servers are part of the AS of the ISP would be a better one to find fakes. A latency check would find name servers that are "too far" away on the network. The GeoIP information just very loosely corresponds to a few of these things. Nothing more in my opinion. > > > > > In general, adding geographic information to IP addresses is very > > > helpful in my point of view because anomalies can be detected > > > much > > > better and more precise firewall rules are possible. > > > > I don't get why. > For example, many active connections from an internal host to china, > korea or an african country might indicate that a host is infected. > If someone need to call ipinfo.cgi for every IP he/she/it does not > know, > it will end in a nightmare... Nobody will check this at the right time. Something like snort would help you more here. > > > > > However, some thing might still be improved: For example, the > > > ipinfo.cgi > > > file shows the IP address, the rDNS name, whois information, but > > > not > > > the appropriate flag. So, if someone scrolls through the > > > connection > > > tracking > > > page, he/she/it sees the source and destination IPs of any active > > > (and > > > recently closed) connection. At the moment, there is no way of > > > telling > > > which country an IP belongs to - without using additional web > > > services, of > > > course - since the flag is shown neither at the connection > > > tracking > > > page > > > nor at the ipinfo.cgi page. This isn't very helpful, is it? > > > > The ipinfo.cgi page shows the whois information for an IP address. > > That > > may contain the name and HQ location of a company this IP address > > belongs to, but that does *not* mean that the host is actually > > located > > in that country - and almost certainly not at that address. > That's right, GeoIP shows the location of the server and not those of > its owner. No, still wrong. Just check 8.8.8.8. GeoIP will show you US. It is actually an anycast with many hosts in the world. That is quite typical for name servers. This *must* be added to the documentation in the wiki and state very clearly that this information is never very accurate and especially with name servers less accurate than usually to expect. > But looking at this whois output: > > CariNet, Inc. NET-26 (NET-71-6-158-128-1) 71.6.158.128 - 71.6.158.191 > CariNet, Inc. CARINET-5 (NET-71-6-128-0-1) 71.6.128.0 - 71.6.255.255 > > Not very helpful in first place, is it? ;-) Why not? > > > > The GeoIP database is a completely different thing. > > > > Judging by the location of the host does make any sense if you care > > about security. > Basically, yes. As I mentioned above, GeoIP makes more sense to > detect > anomalies and to allow, e.g., only VPN access from countries which > are > necessary. You should know that IPFire downloads this GeoIP database from an untrusted source over an untrusted connection. > > > > > > > > That is basically the motivation behind the two patches I > > > submitted > > > recently. > > > > > > Best regards, > > > Timmothy Wilson > Best regards, > Timmothy Wilson > -Michael --===============0170937223071320328== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEKCmlRSWNCQUFC Q2dBR0JRSlduWkcvQUFvSkVJQjU4UDl2a0FrSGoyb1AvaU5CQ1h4dVV2M3NXZWJVRHJ3aDZWL2EK bjNpQWdIUkRZN0VzUXBjT1ozb1hlY3VNNGp5SnhlcXRCUmJmNTMzRDY4cGdKOUR0U1ZEZkpTLytN dG9YRFE3VwpicDc4Rmw5RHZtaHBTQ3A0YzA2N0thK2w1VzJGWnZpQlp6VFlKdHc3ZkRVNHdhbWth Sy9RM2wya3VtNzhubmM0Cm1PdzBqM2c0QTBXa0RXWVpjU2g3VTYxQ2lXWVdpejhjZ2kzSlBpMVdC STY0M3RMR0MwaFZHeHlNYWcxSkJOVmQKK1N6QUkzRjk5Y09hV3RqcE10ZUNCZmZaT1JMLzVEblZ1 TmxIKzk2MHZOdmdLY0VORHdvQzRVS3U5RDBHMS8rZQpicTlNaFBEbEN1blk0K1YzNjRkWm1VWjI1 azRwdVNZZmVSRmFxaTVubGFqYk9PenFETGZxREFJTURVSlpPYTRxCjBybDFJc0xsTmQyNGptSlV4 d0c2Yk01L3JWRGV1TC9nVVEzdUVmQW0yN3lHNjdxR1hyTUgwNmt3d1VXclBIdmUKQUg1bGhESllp cmNScUtzQU9QcUpya1djSVM3S0tGcXB0V2hNS1F0TFpJTWdEYlpMNVlCZ2tDcDQ5V0lscTI4Kwps Tk5VNzJNREttWDVmbW1MM1h4aUpCYVpvS1c5b1dzVllpd2ZUVWZZVTJnQTNxaG1HOTVkdmdhR09J cUlWdWhmCjVjeENSNlQzUWNqSmgzeGl2UWxaVWlLRDNDQjNwVG41QVVRT0c1TE1sSlhBVU5ENzlu cnE4cEZZcHZRVVBnK20KYXBxQy9pWk10L0U3Y3VWdUZNc0tkQnVOZm1LTjVma2JpbGxVWTNwb1BI dFYzdWdRaWxNdXRvV1Y5VHlGU3h5YQo1bnRVRzlkV0cxOUQ0ZzJtcHRKdgo9NllKcAotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============0170937223071320328==--