Hacker News Reader

Comment by jawn | Hacker News Reader

I like to SSH in from all over the place, and so a default deny iptables policy would be a disaster for me. After some research, I went ahead and blocked all of China and Korea using iptables.

For anyone curious I put my modified iptables rules up at http://pastebin.com/UPL3w6FQ

Backstory:

I wrote a quick django app that watches fail2ban logs and plots a heatmap of where in the world the attacks are coming from. After watching this for a bit I found that most of these attacks originate from Chinese and Korean IP space. So I set out to block all of China and Korea.

After some googling, I found that okean.com maintains a handy SMTP Chinese/Korean iptables ruleset at http://www.okean.com/antispam/iptables/rc.firewall.sinokorea. I took their rules and modified it to drop all traffic from these IPs instead of just port 25.

View on HN

Those Asian addresses are only banging away at your server with weak u/p combinations, so if you've implemented PKA then they're already nothing to worry about. Blocking those IP addresses does little more than filters them out of one log (sshd) and into another (netfilter, assuming you're logging). The same goes for moving it to a non-standard port. You're only protecting yourself from the unsophisticated attackers looking for low-hanging fruit, which you've presumably mitigated with PKA already.

The author of the article advocates filtering to trusted sources because it's so much more effective. Ask yourself just how often you access your sshd from a new-to-you location. I'd be willing to bet that it isn't so often that you can't anticipate it. This effectively becomes a third factor in your authentication schema. It requires any attacker to have your private key, know it's passkey, and be at a pre-approved location. Gaining access to your sshd then necessitates attack vectors for your sshd, your private key or the encryption algorithm you used to generate it, and netfilter or whatever runs your firewall.

This ignores vectors like say, ubuntu/debian having an insecure keygen due to their own crappy custom patch to ssh, which was actually the case for quite a while.

I was glad that I was using openbsd with pf as my firewall when that came down.

I don't imagine there are too many Ubuntu installations in environments where this kind of SSH security is desirable. I could be wrong though, and you'd be right that this doesn't excuse them from shipping broken software. Yet broken software doesn't legitimize these frivolous measures. It only delegitimizes distributions like Ubuntu for settings like these.

Incidentally, access to my server from China has proven indispensable. I was trying to read a bunch of blogs that were blocked by the great firewall while I was waiting for my plane at PVG, so I had to ssh in to my server and read them from there.

Consider using ipset. Your ruleset is very huge and slows down your netfilter...

Thank you so much for the tip, I'll look at doing this.

FWIW though I have almost no traffic to these boxes, so I've never noticed any sort of performance issues.

Care to share the Django app? I'd like to explore doing this as well.

Couldn't they use a vpn and tunnel in from any origin?

Reply on news.ycombinator.com