Closed av00va closed 8 years ago
I've responded to each of your questions below:
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.)
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.
whois
may indicate where system administrators are located - but the system could be elsewhere. 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.
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
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!)
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.
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?
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.
IPv6 is in greater flux, but the issues are the same.
What can you do about errors?
intercepts
command or parse the logs yourselfIP address blocking has risks.
It has benefits:
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:
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.
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
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
)
I'm having a problem where countries which should be blocked are not, and countries tthat are not blocked are being blocked. I took a look at the other thread, so I'll post my findings here: Syntax:
./etc/init.d/BlockCountries start -update -permitonly
Results from running
BlockCountries status -v
:This is a bit concerning since I've set it to only permit these countries. I'm assuming this is just a typo in the programming, and it doesn't affect functionality. As you will see, it does block the majority of IPs correctly:
I can't seem to find it now, but earlier I saw an Italian server from Milan added to the banlist. Conversely, a server from Signapore was not banned.
I'm led to believe this is not your fault, since it appears the program is working, it just uses incorrect IP address blocks. Could you tell me how to correct this?
Also, I can still ping these addresses. Does it only block incomming traffic? Is that what the
blockout
param is for? Kind of makes senseThanks for a wonderful script!