Some countries are not being blocked about blockcountries

[tlhackque]

I've responded to each of your questions below:

status -v shows 'blocking' when -permitonly specified on start

When you execute a status command, BlockCountries doesn't know that you applied -permitonly to the start command.

To get the expected status display, put -permitonly in the configuration file (by default /etc/sysconfig/BlockCountries) rather than on the command line. This has the additional benefit of documenting the configuration file. (Or use status -v -permitonly.)

Note that the status command displays the configuration, not the actual blocking rules. These can differ if you edit the configuration file without doing a start. (Or if I have a bug.)

some servers handled incorrectly

This is probably not a bug, but I need specifics to investigate.

The country data is obtained from the IP address registries. The data is saved in the working directory (default /root/blockips) as received in <cc>.zone. E.g. it.zone for Italy.

You'd need to check the specific IP address against the current .zone files. If it is in the file (since you're using -permitonly), It should not be blocked. If you have a case where it is, then I need your config file, all your .zone files, the output of iptables -nL and the output of ip6tables -nL to debug your issue. This is a lot of data - so post as an attachment. I think you can post a .tar file...

But it's more likely that the the IP address is in the wrong zone, or that your location source is incorrect. There are several ways this can happen.

• An address can be assigned in one country, and moved by several means. IP routing doesn't respect borders.
• Some IP addresses are 'anycast', which means that multiple servers respond - routing ensures that the closest one (usually) satisfies your request.
• Or your location information could be wrong: whois may indicate where system administrators are located - but the system could be elsewhere.
• The system's web page could be wrong.

BlockCountries can't do anything about any of these, but an accurate diagnosis requires specifics: what's the address? How are you determining the server location?

For a specific server, you can use -aip or -dip to allow or deny access to that address (or block of addresses or hostname). These rules supersede the zone data. The priority is:
(port rules), otherwise -aip (allowed), otherwise -dip (denied), otherwise zone database.

ping

Outbound ping should not be an issue -- you're initiating it. I don't recommend -blockout, but yes, you can prevent outbound communication. Note that -blockout MUST be in the config file - not on the command line - for proper operation. And it's expensive. (see the help)

Inbound is a bit more complicated.

BlockCountries blocks all protocols, including icmp (ping).

However, it's rules follow whatever IPTABLES rules are in effect at the time it is started.

The default (and recommended) IPTABLES rules permit icmp. Look for something like this in /etc/iptables (and /etc/ip6tables):
:INPUT ACCEPT [0:0]
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT

So it's likely that icmp is being permitted before BlockCountries gets involved.

ping is important for network management, and although many people block icmp, this is a bad practice. Note that ICMP messages are used for MTU discovery and other important functions.

If you really want BlockCountries to prevent icmp, insert (or move)
:INPUT-HOOK - [0:0]
-A INPUT -j INPUT-HOOK
above the -p icmp line.

This will cause the BlockCountries rules to execute first. (INPUT-HOOK does not appear in default IPTABLES rules, so the BlockCountries rules are appended to the INPUT chain by default.)

If you are using a GUI to generate the other IPTABLES rules, you would have to persuade it to create and call INPUT-HOOK in the proper place. Or get it to accept the manual edit.

Also note that the -ctstate RELATED will allow replies to your outbound pings without allowing inbound pings or spurious replies. So you need to be careful about how you interpret 'ping works'.

You can see the logic in the first screenful (or two) of
iptables -nL | less

Conclusion

Please confirm that this answers all your questions, or provide additional data so that I can close this issue.

I'm glad that the BlockCountries is useful to you. (Hopefully at some point you'll want to experience more of the world!)

[tlhackque]

I have improved the documentation in the HELP (and README) to reflect my reply to your questions.

This is in V2.4 (just released). There are no functional changes, but hopefully this will prevent the next person from being confused.

Thanks for pointing out the missing documentation.

[av00va]

Thanks for your help. I spent some time reviewing the blocked IP log and couldn't find what I was looking for. Once I run into this problem again, I'll let you know. I just have one question; with the permitonly param, does it explicitly allow the aforementioned IPs? In essence, if an IP were in the US, but not in the listed IP block, would it be dropped? I'm worried that if some legitimate addresses aren't updated, they'll be denied. Is there a way to set the iptables so that it explicitly denies all countries but the ones I add in the config file?

[tlhackque]

I counted three questions. But I'll try to answer them all.

What you are asking for isn't feasible - because software can't fix a data quality issue. The blocking accuracy is only as good as the data in the zone files from the registries. As I point out in the help, it isn't perfect. That can be due to errors in the data, or the technical considerations that I noted in my previous reply. The imperfections may block communications that are important to you. You have to decide, in the context of your operations, whether the risk of those errors is greater or less than the benefit of blocking other communications.

It really doesn't matter what kind of rule is generated if the data is wrong.

For IPv4, the database is now pretty stable due to address space exhaustion.

Suppose an address is physically in the US, but the zone data file for the US doesn't list it.

• Since all IPv4 addresses have been allocated to regional registries, that address is probably listed in some other country's zone.
• You suggest that I block all countries except the US with explicit rules
• Therefore that address will probably be blocked

IPv6 is in greater flux, but the issues are the same.

What can you do about errors?

• Wait and hope that the registry will be updated
• Watch the log files & explicitly allow (or block) addresses that are mis-classified
  • Blocked connections are listed in syslog - you can use the intercepts command or parse the logs yourself
  • Note that (by default) logging is rate-limited to prevent denial of service attacks; you can miss events
• Provide some communications channel that isn't blocked for your users to report problems. Depending on your operation, you might consider:
  • permitting SMTP (TCP port 25) & using a good anti-spam filter (SpamAssassin is well regarded).
  • allowing HTTPS (TCP port 443) as it's less frequently used for exploits.
  • a dedicated VM with a very limited webserver for problem reports and account requests.
• Live with them

IP address blocking has risks.

• It will both block communication that you want and permit communication that you don't.
• As discussed, the data mapping IP to country code is imperfect
• You may not realize that there is demand for your product in a blocked country.
• Or that your customer (or staff) travels to a blocked country.

It has benefits:

• to the extent that it is accurate, it can prevent a lot of malicious communications.
• it is relatively easy to set up & can considerably reduce the attack surface of your site
• it can be deployed quickly & tuned to your site's requirements
• it usually doesn't require a lot of maintenance once it's set up

The balance has to be determined by each site. It's one tool that can be part of a solution - but it's not a magic bullet.

So, what does -permitonly actually do?

Normally (without -permitonly) connections from IP addresses in the blocks listed in the zone databases for the specified countries are blocked and connections from all other addresses are permitted. The rules are "If address is in this file, block connection" "If not in any file, pass."

You can explicitly block as many countries as you want by listing them in the configuration.
BlockCountries list will list the known country codes. Put them in the configuration file, then delete the countries that you don't want to block. Don't use -permitonly.

-permitonly allows connections from IP addresses in the blocks listed in the zone databases for the specified countries and drops connections from all other addresses. The rules are "If address is in this file, pass connection". "If not in any file, block."

The differences between the two are:

• What happens with unlisted addresses (think addresses not in any zone file)
• Convenience in setting up the configuration (and maintaining it as countries come and go)
• How many rules are generated, which impacts memory and CPU usage by iptables
  • This is hard to predict because BlockCountries optimizes the number and depth of rules by combining address blocks and by creating subchains. start -v and iptables -nL | wc -l can provide a rough idea. But it's rarely worthwhile to investigate. (It was a serious issue before the optimizer was added.)

In both cases, a connection passed by BlockCountries can still be blocked by other rules in your IPTABLES.

[av00va]

I haven't had the ability to decipher the source of the problem, because I get this error:

"addrinfo" is not defined in %Socket::EXPORT_TAGS at ./BlockCountries line 103
        main::BEGIN() called at ./BlockCountries line 103
        eval {...} called at ./BlockCountries line 103
Can't continue after import errors at ./BlockCountries line 103
BEGIN failed--compilation aborted at ./BlockCountries line 103.

I tried reinstalling Socket using cpanm and it errors saying
version 0.87 required--this is only version 0.77 at /usr/local/share/perl5/Module/Metadata.pm line 261

I ended up fixing it by reinstalling perl-core. Now, when I run `./BlockCountries', I get this odd message:

./BlockCountries
Use of uninitialized value $cmd in string eq at ./BlockCountries line 1466.
Use of uninitialized value $cmd in string eq at ./BlockCountries line 1469.
Use of uninitialized value $cmd in string eq at ./BlockCountries line 1472.
Use of uninitialized value $cmd in string eq at ./BlockCountries line 1475.
Use of uninitialized value $cmd in string eq at ./BlockCountries line 1478.
Use of uninitialized value $cmd in string eq at ./BlockCountries line 1481.
Use of uninitialized value $cmd in string eq at ./BlockCountries line 1484.
Use of uninitialized value $cmd in string eq at ./BlockCountries line 1487.
Usage: BlockCountries (start|stop|restart|condrestart|status|list|intercepts|help)

Before, it didn't do that. It seems to be working however

[tlhackque]

• BlockCountries was the victim of your Socket issue, not the cause.
  • The first error indicates that 'Socket.pm' was corrupt (or very, very old). 'addrinfo' is a tag added in Socket 1.96. The current version is 2.021. I can't say how you regressed, corrupted or selected an old version of this file.
  • The error from CPAN was because you tried to install the latest Socket onto an older version of Perl. But the latest Socket has a dependency on a newer version of Perl. So your choices were to re-install an older version of Socket or to upgrade Perl.
• The uninitialized value error is fixed in V2.5. I'm surprised it wasn't noticed before.

Thanks for the report.

For future issues, please include the BlockCountries version (available via ./BlockCountries help | head -n 1) and perl version (from perl --version)