Dear all, I have a question about security:/netfilter/openSUSE_Leap_42.2/noarch/xtables-geoip-2016.09-71.2.noarch.rpm In my firewall I examine all unexpected traffic, there for I end added lines for all existing countries, like: iptables -A CC -m geoip --src-cc AD -j LOG --log-prefix " CC=Andorra " iptables -A CC -m geoip --src-cc AD -j DROP I have likewise 250 lines, but still I've got some uncaught lines. Does that mean there are "other countries", or that there are subnets not defined within the package xtables-geoip-2016.09-71.2.noarch.rpm In twelve hours, I got 232 different IPv4 adresses, that xtables-geoip does not recognize. How can I correct this? Kind regards, Hans -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
suse@a-domani.nl wrote:
Dear all,
I have a question about
security:/netfilter/openSUSE_Leap_42.2/noarch/xtables-geoip-2016.09-71.2.noarch.rpm
In my firewall I examine all unexpected traffic, there for I end added lines for all existing countries, like: iptables -A CC -m geoip --src-cc AD -j LOG --log-prefix " CC=Andorra " iptables -A CC -m geoip --src-cc AD -j DROP
I have likewise 250 lines, but still I've got some uncaught lines. Does that mean there are "other countries", or that there are subnets not defined within the package xtables-geoip-2016.09-71.2.noarch.rpm
In twelve hours, I got 232 different IPv4 adresses, that xtables-geoip does not recognize.
Yes, that is due to incorrect or missing whois information for the subnets involved. Or that wherever xtables gets the information is flawed or outdated. -- Per Jessen, Zürich (20.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-12 18:34, Per Jessen wrote:
suse@a-domani.nl wrote:
Dear all,
I have a question about
security:/netfilter/openSUSE_Leap_42.2/noarch/xtables-geoip-2016.09-71.2.noarch.rpm
In my firewall I examine all unexpected traffic, there for I end added lines for all existing countries, like: iptables -A CC -m geoip --src-cc AD -j LOG --log-prefix " CC=Andorra " iptables -A CC -m geoip --src-cc AD -j DROP
I have likewise 250 lines, but still I've got some uncaught lines. Does that mean there are "other countries", or that there are subnets not defined within the package xtables-geoip-2016.09-71.2.noarch.rpm
In twelve hours, I got 232 different IPv4 adresses, that xtables-geoip does not recognize.
Yes, that is due to incorrect or missing whois information for the subnets involved. Or that wherever xtables gets the information is flawed or outdated.
Hi Per, As no-one else responded, it seems that this knowledge is not wide spread (one way of looking at it :-) But is this something that (end-)users could/should take care of? Or, as it resides under "security", is this restricted to a few people upstream? Kind regards, Hans -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
suse@a-domani.nl wrote:
On 2017-04-12 18:34, Per Jessen wrote:
suse@a-domani.nl wrote:
Dear all,
I have a question about
security:/netfilter/openSUSE_Leap_42.2/noarch/xtables-geoip-2016.09-71.2.noarch.rpm
In my firewall I examine all unexpected traffic, there for I end added lines for all existing countries, like: iptables -A CC -m geoip --src-cc AD -j LOG --log-prefix " CC=Andorra " iptables -A CC -m geoip --src-cc AD -j DROP
I have likewise 250 lines, but still I've got some uncaught lines. Does that mean there are "other countries", or that there are subnets not defined within the package xtables-geoip-2016.09-71.2.noarch.rpm
In twelve hours, I got 232 different IPv4 adresses, that xtables-geoip does not recognize.
Yes, that is due to incorrect or missing whois information for the subnets involved. Or that wherever xtables gets the information is flawed or outdated.
Hi Per,
As no-one else responded, it seems that this knowledge is not wide spread (one way of looking at it :-)
Hi Hans xtables-geoip is a collection of tables mapping IP addresses to country codes. They will always be incomplete, there are for instance some legacy IP ranges that simply don't have countrycodes. Others have missing information, and others change. Free IP-ranges are distributed back to the RIRs who can allocate them again. In Leap422, xtables-geoip is dated 30 Sep 2016, it's just too old. It needs a monthly update at least.
But is this something that (end-)users could/should take care of?
I would expect xtables-geoip to have some sort of regular update mechanism and maybe a way for the end user to add local modifications.
Or, as it resides under "security", is this restricted to a few people upstream?
Looking at OBS: https://build.opensuse.org/package/show/security:netfilter/xtables-geoip everything is quite old. According to the spec file, the geo data is from Maxmind: http://dev.maxmind.com/geoip/legacy/geolite/ and it's updated every month. There is even an update script: http://dev.maxmind.com/geoip/geoipupdate/ To fix your problem locally, grab the latest database and rebuild your local files or update the package with a newer database and get it published as an update. -- Per Jessen, Zürich (8.9°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/17/2017 10:18 AM, Per Jessen wrote:
suse@a-domani.nl wrote:
On 2017-04-12 18:34, Per Jessen wrote:
suse@a-domani.nl wrote:
Dear all,
I have a question about
security:/netfilter/openSUSE_Leap_42.2/noarch/xtables-geoip-2016.09-71.2.noarch.rpm
In my firewall I examine all unexpected traffic, there for I end added lines for all existing countries, like: iptables -A CC -m geoip --src-cc AD -j LOG --log-prefix " CC=Andorra " iptables -A CC -m geoip --src-cc AD -j DROP
I have likewise 250 lines, but still I've got some uncaught lines. Does that mean there are "other countries", or that there are subnets not defined within the package xtables-geoip-2016.09-71.2.noarch.rpm
In twelve hours, I got 232 different IPv4 adresses, that xtables-geoip does not recognize.
Yes, that is due to incorrect or missing whois information for the subnets involved. Or that wherever xtables gets the information is flawed or outdated.
Hi Per,
As no-one else responded, it seems that this knowledge is not wide spread (one way of looking at it :-)
Hi Hans
xtables-geoip is a collection of tables mapping IP addresses to country codes. They will always be incomplete, there are for instance some legacy IP ranges that simply don't have countrycodes. Others have missing information, and others change. Free IP-ranges are distributed back to the RIRs who can allocate them again. In Leap422, xtables-geoip is dated 30 Sep 2016, it's just too old. It needs a monthly update at least.
But is this something that (end-)users could/should take care of?
I would expect xtables-geoip to have some sort of regular update mechanism and maybe a way for the end user to add local modifications.
Or, as it resides under "security", is this restricted to a few people upstream?
Looking at OBS:
https://build.opensuse.org/package/show/security:netfilter/xtables-geoip
everything is quite old. According to the spec file, the geo data is from Maxmind:
http://dev.maxmind.com/geoip/legacy/geolite/
and it's updated every month. There is even an update script:
http://dev.maxmind.com/geoip/geoipupdate/
To fix your problem locally, grab the latest database and rebuild your local files or update the package with a newer database and get it published as an update.
BTW there is a nice README, explainig how to keep it up-to-date /usr/share/doc/packages/GeoIP/README.SUSE cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Rc3bcdiger Meier wrote:
BTW there is a nice README, explainig how to keep it up-to-date /usr/share/doc/packages/GeoIP/README.SUSE
Where is that one from? It's not in the xtables-geoip package. -- Per Jessen, Zürich (9.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/17/2017 10:49 AM, Per Jessen wrote:
Rc3bcdiger Meier wrote:
BTW there is a nice README, explainig how to keep it up-to-date /usr/share/doc/packages/GeoIP/README.SUSE
Where is that one from? It's not in the xtables-geoip package.
It's in the "GeoIP" package and also contains the generic command line tools geoiplookup/geoiplookup6. $ geoiplookup 212.227.126.134 GeoIP Country Edition: DE, Germany Sorry I've never used xtables-geoip, thought they are using the same database. BTW AFAIR there was also a commercial GeoIP subscription, providing faster or better updates. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-17 10:49, Per Jessen wrote:
Rc3bcdiger Meier wrote:
BTW there is a nice README, explainig how to keep it up-to-date /usr/share/doc/packages/GeoIP/README.SUSE
Where is that one from? It's not in the xtables-geoip package.
<initial blush> If my college's will ever find out that I didn't read the manual/howto :-( Did the geoip-fetch -a, but the files in the directory /usr/share/xt_geoip/BE are dated at October last year.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-17 22:20, suse@a-domani.nl wrote:
On 2017-04-17 10:49, Per Jessen wrote:
Rc3bcdiger Meier wrote:
BTW there is a nice README, explainig how to keep it up-to-date /usr/share/doc/packages/GeoIP/README.SUSE
Where is that one from? It's not in the xtables-geoip package.
<initial blush> If my college's will ever find out that I didn't read the manual/howto :-( Did the geoip-fetch -a, but the files in the directory /usr/share/xt_geoip/BE are dated at October last year....
Oh, and this script is for updating geoiplookup... Data for this tool looks very different, and resides in: /var/lib/GeoIP So both tools use a different data-set. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 17 Apr 2017, suse@a-domani.nl wrote:
suse@a-domani.nl wrote:
In my firewall I examine all unexpected traffic, there for I end added lines for all existing countries, like:
Hi Hans, Wouldn't it be simpler to specify the countries you are willing to accept and block all other traffic without specifying the country.
Does that mean there are "other countries", or that there are subnets not defined within the package xtables-geoip-2016.09-71.2.noarch.rpm
...
On 2017-04-12 18:34, Per Jessen wrote:
Yes, that is due to incorrect or missing whois information for the subnets involved. Or that wherever xtables gets the information is flawed or outdated.
The subnets change all the time. To get up-to-date data you need to go to a subscription service. A 2016 rpm which may have been using 6 month old data is way out of date.
As no-one else responded, it seems that this knowledge is not wide spread (one way of looking at it :-) But is this something that (end-)users could/should take care of?
It seems to me that geoip is re-inventing the wheel. Blocking country CC by subnet is best done by taking country subnet specifications from say ipverse.net/ipblocks/data/countries/CC.zone and loading them into hash:net ipsets. Performance is O(1). Can geoip do better? Note that if you modify SuSEfirewall2 you are going outside what opensuse supports. You are on your own. Roger -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/17/2017 11:01 AM, Roger Price wrote:
On Mon, 17 Apr 2017, suse@a-domani.nl wrote:
suse@a-domani.nl wrote:
In my firewall I examine all unexpected traffic, there for I end added lines for all existing countries, like:
Hi Hans,
Wouldn't it be simpler to specify the countries you are willing to accept and block all other traffic without specifying the country.
BTW I've simply configured all our internal used services (like ssh, internal mail, dns, ntp etc.) to listen on ipv6 only. This seem to avoid a lot more noise in the logs than these complicated and unsafe solutions like xtables-geoip or Fail2ban. I have only one single machine left as an ipv4 ssh gateway for the rare case that will sit on an ipv4-only network. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am Montag, 17. April 2017, 12:14:04 CEST schrieb Rüdiger Meier:
complicated and unsafe solutions like xtables-geoip or Fail2ban.
"needs citation". or in other words, where did you get that from, especially the "unsafe"? Cheers MH -- gpg key fingerprint: 5F64 4C92 9B77 DE37 D184 C5F9 B013 44E7 27BD 763C -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/17/2017 12:26 PM, Mathias Homann wrote:
Am Montag, 17. April 2017, 12:14:04 CEST schrieb Rüdiger Meier:
complicated and unsafe solutions like xtables-geoip or Fail2ban.
"needs citation".
or in other words, where did you get that from, especially the "unsafe"?
It's obvious that externally maintained IP blacklists or whitelists make theses third party maintainers able to change your iptables rules to whatever they want. Or think about serious attackers like NSA who are surely able to use IPs which are not listed in any geoip database. And geoip can't be 100% correct at all. There is always a risk that you will block yourself although you only wanted to blacklist Chinese IPs. Fail2ban allows DoS. For example an arbitrary user on an ssh-client (or within your single-IP NAT’d network) machine may cause all other users to be banned from the ssh server. Moreover in general IP based security is never really secure. This is also true for my ipv6-only approach. All this blacklisting or hiding is IMO only worth to get rid of some ugly logs. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Rc3bcdiger Meier wrote:
On 04/17/2017 11:01 AM, Roger Price wrote:
On Mon, 17 Apr 2017, suse@a-domani.nl wrote:
suse@a-domani.nl wrote:
In my firewall I examine all unexpected traffic, there for I end added lines for all existing countries, like:
Hi Hans,
Wouldn't it be simpler to specify the countries you are willing to accept and block all other traffic without specifying the country.
BTW I've simply configured all our internal used services (like ssh, internal mail, dns, ntp etc.) to listen on ipv6 only. This seem to avoid a lot more noise in the logs than these complicated and unsafe solutions like xtables-geoip or Fail2ban.
Why would you have any such noise on internal-only services? -- Per Jessen, Zürich (10.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/17/2017 07:34 PM, Per Jessen wrote:
Rc3bcdiger Meier wrote:
On 04/17/2017 11:01 AM, Roger Price wrote:
On Mon, 17 Apr 2017, suse@a-domani.nl wrote:
suse@a-domani.nl wrote:
In my firewall I examine all unexpected traffic, there for I end added lines for all existing countries, like:
Hi Hans,
Wouldn't it be simpler to specify the countries you are willing to accept and block all other traffic without specifying the country.
BTW I've simply configured all our internal used services (like ssh, internal mail, dns, ntp etc.) to listen on ipv6 only. This seem to avoid a lot more noise in the logs than these complicated and unsafe solutions like xtables-geoip or Fail2ban.
Why would you have any such noise on internal-only services?
I mean "internal" in terms of "only used by our staff". Still usable from everywhere. For example our public company web server is listening on port 80/443 via ipv4 and ipv6. Any other communication to that server (maintenance, monitoring), e.g. ssh, nrpe is done via ipv6 only. I have never seen any botnet login attempt via IPv6 so far. When I enable ssh via ipv4 I see thousands login attempts per day. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-17 19:57, Rüdiger Meier wrote:
I have never seen any botnet login attempt via IPv6 so far. When I enable ssh via ipv4 I see thousands login attempts per day.
I have mine (at home) on a different port. I haven't noticed any attempt yet. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Roger Price wrote:
On 2017-04-12 18:34, Per Jessen wrote:
Yes, that is due to incorrect or missing whois information for the subnets involved. Or that wherever xtables gets the information is flawed or outdated.
The subnets change all the time. To get up-to-date data you need to go to a subscription service.
Well, the data is out there and available for free. At maxmind for instance. It isn't overly complicated retrieving the data from router tables and whois information, it's all publicly available.
It seems to me that geoip is re-inventing the wheel. Blocking country CC by subnet is best done by taking country subnet specifications from say ipverse.net/ipblocks/data/countries/CC.zone and loading them into hash:net ipsets. Performance is O(1). Can geoip do better?
The tables for xtables-geopi are split by some criteria, the loading into kernel space and the lookups are apparently very efficient. -- Per Jessen, Zürich (11.2°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Carlos E. R. -
Mathias Homann -
Per Jessen -
Roger Price -
Rüdiger Meier -
suse＠a-domani.nl