Slashdot Mirror

It happened for the same reason it happened in 2015:

https://www.theverge.com/2015/...

In short, activists inside and outside of China are using GitHub to write and share code for software to circumvent the government's "Great Firewall" in one way or another...they did not succeed in taking GitHub offline, so they decided to show their technical prowess and their sheer (if amplified) bandwidth abuse potential by conducting a second attack. They're still trying to take GitHub offline, badly, people need to be made more aware this is happening...the last time was only three years ago and it was a shocking attempt at China to try and impose censorship of the Internet, as they see fit, inside the firewall AND out. This isn't a conspiracy theory or conjecture, China are very definitely waging an online "war" of sorts and this is more or less a demonstration of their capabilities.

This doesn't shock me in the least because 90% of brute force attempts on my tiny VPS that hosts my blog come from Chinese IP addresses. It's gotten so bad that I just block the whole country. I download the zone file from http://www.ipdeny.com/

blacklist teamviewer connections from india?

blacklist India, period.

Back when I looked after a fairly large network, and after a month of fruitlessly sending f.tons of emails to abuse@addresses, I basically decided one morning, fsck it, blocked all known Indian net ranges (and Chinese, Pakistani and Indonesian ones as well into the bargain), then worked on letting individual IP numbers through on a case-by-base basis. It was amazing how very few (7, ISTR) were finally allowed.

I'm out of the IT game as a profession nowadays, but guess which country's net ranges had just recently been added to my home firewall's shitlist thanks to incessant VNC probings and attempts to relay BS through my mail server?

(If anyone's interested, I started with files from here as a a basis for my lists.)

If spam has made it far enough that it's actually reached your personal instance of procmail, then there's been a problem earlier in the chain. Procmail rulesets should be a last resort, and they should only be asked to deal with minor issues that aren't dealt with via earlier rulesets.

The first line of defense are your perimeter routers. They should implement BCP 38, they should block bogons, and they should bidirectionally deny all traffic to/from the Spamhaus DROP list. In addition, they should block inbound port 25 traffic from everywhere on the planet that you don't need email from. In other words; the fact that someone in country X wants to email you is unimportant unless you actually wish to receive mail from them. Yes, this is a reversal of default-permit, for a simple reason: default-permit for SMTP stopped being reasonable around 2000. Use http://www.ipdeny.com/ to pick up the ranges per-country and only permit what you need. (Obviously a major research university can't do this. But Joe's Furniture, which does not have customers in Peru or Pakistan or Greece, can.)

Then use blacklists, the best defense against spam we've ever developed. (Source: 30+ years of email experience) Spamhaus's Zen blacklist is a good one with a low FP rate and a tolerable FN rate. Augment these with local blacklists based on domains and network allocations. Augment those with as much blocking of generic hostnames and dynamic IP space as possible: real mail servers have real hostnames and are on static addresses.

Then enforce RFC requirements: sending host must have rDNS, that PTR must resolve, what it resolves to should be the sending host's IP. Sending host must HELO as FQDN or bracketed dotted-quad; if FQDN, must resolve. Sending host must not send traffic pre-greeting. And so on. Enforcing these DOES mean occasionally you block mail sent by non-spamming entities: but since they are incompetent non-spamming entities, why would you want mail from them?

Add greylisting. It'll handle a lot of annoying hosts that haven't learned to retry yet.

Rate-limit based on normative values for your site. For example: if analysis of a year's worth of mail logs shows that during that time you never received more than 10 messages a day from ANY host, then rate-limit at 30 or 40. You'll never hit in normal practice; but if you get hammered by a fast-sending host, you'll blunt the attack. Note that these don't have to be perfect to work: provided you send deferrals (SMTP response codes 4xx) instead of refusals (5xx) the worst that happens is that you will mistakenly impose a delay.

There's more -- it's possible to get quite crafty about this. But note that NONE of these measures pay any attention to content. There's a reason for that: spammers can defeat content-based measures at will. They won't have it so easy with these.

Deployed in production in various setups ranging from a dozen to eight million users, these steps yield a FP rate of about 10e-6 to 10e-7 and a FN rate around 10e-5 to 10e-6. Tuning helps, of course: initial rates can be higher but log analysis (which all sensible postmasters do) readily brings them down. If you have the luxury of running your own mail server just for yourself, then you can REALLY tune this setup: you should be able to get the FN rate down to 10e-7 after a few months.

http://www.nirsoft.net/countryip/

Done!

I prefer to use: http://www.ipdeny.com/ - YMMV...

IPDeny sounds right up your alley!

Word. I use the IP blocks from http://ipdeny.com/ to configure ip-filter to stop systems in the top ten malicious countries (http://www.countryipblocks.net/malicious-internet-traffic/malicious-internet-activity-the-top-10-countries/) from getting SSH and SMTP access to my servers. This dropped the amount of relay-attempted e-mail to practically nothing (by three orders of magnitude, from 10Ks of attempts to 10s of attempts), and unknown user attempts to less than a quarter of what they had been.

Yeah, I might miss a little bit of legit e-mail, but if they really need me, we can work out a specific allowance or they can use an otherwise accepted (and content-filtered) server.

Proactively? Not really. The systems used for this are typically overseas, in countries that more or less don't care.

However, you -can- configure your server to disregard even initial connection attempts from specific ranges of IP addresses. I solved a lot of this on my own home FTP server by (sorry comrads) telling my server to ignore connection attempts from Russia and China.

Upon doing so, it went from a daily occurrence, to maybe one attempt a month. Usually less.

And, if a friend ever needs to FTP in from one of these countries, it's a simple enough rule change.

That's a pretty good idea. I take it you use the ip blocks given in http://www.ipdeny.com/ipblocks/

The only slight snag is that the IP I'm on at work in the UK doesn't seem to be listed, so I'm not sure how reliable this list is, although I guess a false negative is better than a false positive.

I also like http://www.ipdeny.com/

Perhaps its time to just firewall off Eastern Europe, Russia, and China and call it a day. Whitelist them when needed.

Been there, done that: At least on our email servers. In addition, I have blocked every country other than the US with an iptables deny rule ("they" can't even ping the mailserver). Before you start complaining, please be aware that I work for a small (approx 60 email accounts) US-based management company that only deals with other US companies. In the past 6-7 months that my iptables rules have been in place on the mail server, incoming spam has dropped 80-90%. In addition to blocking everything but the US IP space, we are running postfix/amavis/spamassassin/clamav/postgrey and have configured a few RBLs. Very little spam gets through these days.

I am using ipdeny.com for the lists of IP space sorted by country: http://www.ipdeny.com/ipblocks/data/countries/all-zones.tar.gz

If you would like my script, post a reply to this message, and I will either post the script directly in the comments or email you privately.

The solution to simply block off non-US IP space is an ugly vile hack to how the Internet was originally designed. Meanwhile back in modern-day reality, the hack works well.

-JL

Yeah, that's what I was banking on - that most ranges would be "LEGACY". Hmm. This looks quite promising. http://www.ipdeny.com/ipblocks/data/countries/au.zone

Could you have a look in there, and see if netblocks you know are in there?

$testip = $_SERVER['REMOTE_ADDR'];
function ipCheck ($IP, $CIDR) {
  list ($net, $mask) = split ("/", $CIDR);
  $ip_net = ip2long ($net);
  $ip_mask = ~((1 << (32 - $mask)) - 1);
  $ip_ip = ip2long ($IP);
  $ip_ip_net = $ip_ip & $ip_mask;
  return ($ip_ip_net == $ip_net);
}
$CIDRs = file ("/path/to/ru.zone.file");
foreach ($CIDRs as $CIDR) {
  if (ipCheck ($testip, $CIDR)) {
    $act = "view"; // switches to viewing old comments rather than posting new one
    break;
  }
}