IP's from Ukraine not working

[tlearyus]

Your script is wonderful and has saved my VPS from countless hackers etc.

However for some reason IP's from the country code ua (Ukraine) are not being stopped

I have added ua to the conifg file the same as any other country I am blocking and run and have updated the iptables using BlockCountries start -update

Any idea's? My config file is below

Configuration for BlockCountries service

Countries

This lists both ISO code and name for documentation (and as insurance against changes in the name)

However, either would do.

ru ch in pk ir br de fr jp pl lt ua tr kr ca ph

Allow https and inbound mail, which requires DNS

-atport https -atport smtp -atport submission -atport smtps -atport domain -auport domain

Enable logging

-log

regards - glen

[tlhackque]

Thank you for the kind words. I'm glad to hear that BlockCountries has been helpful.

You haven't provided enough information to diagnose your issue. So here are some questions and general remarks that may help.

How do you know that the IP addresses that are troubling you are from UA?

Please provide one of the addresses. What protocols are they using?

You do realize that your configuration allows mail, https (secure web) and DNS traffic, even from blocked countries, right? That's my default, since most of the attacks are http, ssh, smb, etc and allowing mail, https & DNS through allows business to be conducted. But if you're seeing denial of service attacks via those protocols, adjust the -atport and -auport directives to shut those off too. If you don't run one of these - most people don't run their own DNS, for example - it won't help much since the ports are closed.

Are ANY IP addresses from UA being blocked? Or is the problem just with some?

What does BlockCountries intercepts -days 30 say?

Also, BlockCountries status -v should show that the active configuration includes UA. If not, perhaps the config file $CFGFILE, usually /etc/sysconfig/BlockCountries' is not being read due to permissions, selinux, or a typo in the name. Note that with selinux, permissions may be different for a cron job or init script than when you run from the command line. (You are running BlockCountries as an init script & cron job, right?)

The IP address assignments come from the Regional Registries and are stored in $ZONEDIR/.(usually /root/blockips). UA is serviced by the RIPE registry.

The registries assign IP blocks, but this is not 100% foolproof. Hackers can use various techniques to appear to be elsewhere. And there have been known to be errors in the data.

You can watch the update process in detail with BlockCountries start -update -d -v

To check the data yourself, two files are of interest: ripe.rdb - this is the data from the regional registry. Source is ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-latest UA data will look like: ripencc|UA|ipv4|95.69.128.0|32768|20081119|allocated ripencc|UA|ipv6|2001:4130::|32|20091021|allocated Where the two fields after ipv4 are the base address and the number of addresses (in decimal) For ipv6, they are base address and length (bits) If you delete ripe.rdb and re-run the update, it will be re-downloaded. This shouldn't be necessary unless the file has been corrupted.

ua.cdb (This is a binary file containing a compressed form of just the UA records). I've never seen one corrupted, but you can delete it & do the update again to force it to be recreated from ripe.rdb.

If the addresses that are troubling you are not in the registry data for UA, you can either block them manually (-dips address/mask), or use the country code that they are assigned to.

It is possible that the iptables rules are incorrect - but that seems unlikely. To see them, use iptables -nvL* (ip6tables -nvL for ipv6). These aren't light reading, and they can be quite large. However, if there's a bug, I'll certainly need them to fix it.

[tlearyus]

Hi Timothe

Thanks for the awesome detailed reply. Much appreciated.

They are mostly coming via SSH (brute force attempts) and some have been via http (attempted wordpress admin logins)

I suspect the ripe database might be out of date so I will check that.

I have included a link to download my secure log so you can see some of the IP's (1.8Mb) http://northcoastinternet.com.au/downloads/secure-log.txt

I checked a few that got through like this one 93.79.72.103 against the ua.zone file in /root/blockips and that network is not included. I then checked the ripe allocations database you suggested and it does not exist it that either.

So obviously these are new networks setup in the Ukraine that are not included in the ripe database. I have manually added them into my iptables for now but any other suggestions are more than welcome?

PS: Everything else is working fine on my server end and I am running the the perl version of blockcountries.

[tlhackque]

Why do you think that UA is the source? Whois?

I checked the address that you cited; whois says it's assigned to a UA entity. However, it's possible that this is where the contact is, not where the machines are...

Checking the database at ripe.net (use -L), we can see that there was a change to this allocation last month. So it may appear in the allocation database in the next update. BlockCountries checks for updates whenever start -update is run; there's no point in running it more often than about weekly. It's anti-social and the data doesn't change that often.

I don't block unallocated blocks of addresses -- they could be allocated to desired countries or to undesired. I err on the side of allowing business. I hesitate to make this an option as it could block something important.

You don't need to add addresses directly to iptables. As I said, just use -dip 93.79.0.0/17 in your config file to disable the entire block. This is easier than an iptables rule - and BlockCountries will merge it with other data if it can.

I did find the post of your intercepts list; it does look as though BlockCountries has been effective. The ?? country codes can be caused by the merging/optimization of the iptables rules; that can make it impossible to backtrack.

In any case, BlockCountries can only act on what's in the database, so I'm going to close this issue.

Feel free to re-open if a new issue arises.