Help me keep Chinese hackers at bay
August 3, 2012 11:00 AM Subscribe
Help me block China
Our small company email server (and hence, our network) is hit regularly with Chinese hackers trying brute force attacks on accounts. In fact I would go so far as to say that 99% of attacks on our network originate in China.
Conceivably, I could create (or copy - I know there are sites that already list these) giant access lists for our Cisco ASA to block the entire nation of China but I'm not sure if this is the best approach. I assume our firewall will take a massive performance hit if I do this. Of course their regular, constant attacks are probably not helping performance or my time either.
Are there any other options besides ACL's or what do you do - or do you do nothing at all and rely on your users to create good passwords?
Our small company email server (and hence, our network) is hit regularly with Chinese hackers trying brute force attacks on accounts. In fact I would go so far as to say that 99% of attacks on our network originate in China.
Conceivably, I could create (or copy - I know there are sites that already list these) giant access lists for our Cisco ASA to block the entire nation of China but I'm not sure if this is the best approach. I assume our firewall will take a massive performance hit if I do this. Of course their regular, constant attacks are probably not helping performance or my time either.
Are there any other options besides ACL's or what do you do - or do you do nothing at all and rely on your users to create good passwords?
All access to my network is via ssh. I turned off password-only authentication and have my users use a passphrase-protected key pair.
You need a combination of "something you have" and "something you know" for any security at all. How you accomplish this depends on what kinds of access your users need, the platforms you use, etc.
Users are utterly terrible at picking passwords, and you saying "Be sure to pick a secure one!" (as we all stupidly do) doesn't help any. Now I spend exactly no time worrying about someone out there trying to guess passwords.
Passwords are really poor security. The trivial things people try to do to fix this (like force users to change the password frequently) just make it worse. You need to be using a better technology.
posted by fritley at 11:13 AM on August 3, 2012 [4 favorites]
You need a combination of "something you have" and "something you know" for any security at all. How you accomplish this depends on what kinds of access your users need, the platforms you use, etc.
Users are utterly terrible at picking passwords, and you saying "Be sure to pick a secure one!" (as we all stupidly do) doesn't help any. Now I spend exactly no time worrying about someone out there trying to guess passwords.
Passwords are really poor security. The trivial things people try to do to fix this (like force users to change the password frequently) just make it worse. You need to be using a better technology.
posted by fritley at 11:13 AM on August 3, 2012 [4 favorites]
Response by poster: Yes, it was certainly easier a few years ago when there was no email access via iThings, but now it's expected from the top down to be able to do that, so the "deny all" won't work here. We already do the minimum length and mixed case.
posted by bellastarr at 11:13 AM on August 3, 2012
posted by bellastarr at 11:13 AM on August 3, 2012
Lots of attacks originate from botnets, not necessarily in China itself. Unfortunately strong passwords and/or two-factor auth are the best controls. Maybe you could set up a deny-all script with selective IP allowance upon first login or via special web page, for example.
posted by RobotVoodooPower at 11:19 AM on August 3, 2012
posted by RobotVoodooPower at 11:19 AM on August 3, 2012
Strong passwords are great, but I have to say, I've been doing this stuff a long time, and I've virtually never seen a compromise due to brute force password guessing against an unknown victim (I have seen passwords guessed by people who know the owner of the account - like an ex-boyfriend, roommate, etc., but that's a different situation). The vast majority of compromises I've seen were due to (in no particular order):
1. Unpatched software vulnerabilities (that may not even have been reported yet)
2. Misconfiguration
3. Phishing and/or passwords stolen from other sites and re-used on your site
4. Malware
Strong passwords will not address any of these issues (except to the extent that they may make it less likely that someone would re-use a password from another service that doesn't have the same requirements).
posted by primethyme at 11:27 AM on August 3, 2012 [2 favorites]
1. Unpatched software vulnerabilities (that may not even have been reported yet)
2. Misconfiguration
3. Phishing and/or passwords stolen from other sites and re-used on your site
4. Malware
Strong passwords will not address any of these issues (except to the extent that they may make it less likely that someone would re-use a password from another service that doesn't have the same requirements).
posted by primethyme at 11:27 AM on August 3, 2012 [2 favorites]
Response by poster: Is it possible to implement two-factor auth for roaming users (and no regular IP address) who normally access via IMAP?
posted by bellastarr at 11:30 AM on August 3, 2012
posted by bellastarr at 11:30 AM on August 3, 2012
Welcome to the internet! This is so common as to be background noise. With good password and account policies, the risk of exploit by these drive-by style attacks are very low.
So, as long as you have no legitimate business need, I would block every IP issued by APNIC. Google for their current assignments. You could try to do all non-CONUS space, but that's overkill. This will not put too much load on your ASA, even the 5505 can handle hundreds of ACLs and this would just be one.
You can even create the rule in ADSM without enabling it, then enable it to check the load.
rely on your users to create good passwords?
Oh dear god no. please, no, Not ever. Pick a long minimum length - 10 or more, and from this info sec professional, please enforce expiration and reuse prevention.
Is it possible to implement two-factor auth for roaming users (and no regular IP address) who normally access via IMAP?
Yep. Tie the LDAP account into something like an RSA securID appliance, issue hard of soft tokens, then their password is changed every 60 seconds. I'm not familiar with other token options, but I know they're out there.
posted by anti social order at 11:36 AM on August 3, 2012 [3 favorites]
So, as long as you have no legitimate business need, I would block every IP issued by APNIC. Google for their current assignments. You could try to do all non-CONUS space, but that's overkill. This will not put too much load on your ASA, even the 5505 can handle hundreds of ACLs and this would just be one.
You can even create the rule in ADSM without enabling it, then enable it to check the load.
rely on your users to create good passwords?
Oh dear god no. please, no, Not ever. Pick a long minimum length - 10 or more, and from this info sec professional, please enforce expiration and reuse prevention.
Is it possible to implement two-factor auth for roaming users (and no regular IP address) who normally access via IMAP?
Yep. Tie the LDAP account into something like an RSA securID appliance, issue hard of soft tokens, then their password is changed every 60 seconds. I'm not familiar with other token options, but I know they're out there.
posted by anti social order at 11:36 AM on August 3, 2012 [3 favorites]
You could integrate something like fail2ban with whatever IMAP server you're using. (Example: Using Fail2ban with Dovecot.) This will block addresses that have repeated failed attempts at the linux kernel level. I doubt you have anything to worry about regarding CPU usage, as any linux system faster than a 486 should be able to run with thousands of iptables rules without breaking a sweat. It's very highly optimized code.
posted by Rhomboid at 12:01 PM on August 3, 2012
posted by Rhomboid at 12:01 PM on August 3, 2012
I've used DenyHosts on SSH servers, but I don't know if it will work for a mail server. But there might be a similar solution. Basically it looks for bruteforce attempts and when it sees one, blocks that IP address (via hosts.deny) for some amount of time.
The downside is this will do the blocking at the host level rather than at the gateway or firewall level, which might be where you want it.
Fail2Ban is a nice tool which reads Apache-style error logs and builds up firewall rules to ban the offending hosts. Of course, your MTA would need to create Apache-style logs, and it may not work for that Cisco firewall without a bunch of configuration.
If you're getting the impression that most of these tools are Linux-centric, you are right. In particular, they tend to be LAMP-stack specific, and assume that the firewall is on the same box as Apache, etc. I'm not sure if there are any more "enterprisey" solutions, although I suspect there are if you want to pay for them.
Honestly if you don't have any legitimate business traffic from China, it's fairly straightforward to build up firewall rules to just drop all traffic from the IP allocations assigned to them. You need to be really sure that you're never going to have any legitimate traffic from there (keeping in mind that settings like this have a tendency of being forgotten and living on forever). The common way to do it is to download a list of IP range allocations and then use scripts to mangle the text around into something that you can load into your firewall of choice. See the second answer in this thread. Note that it is using netfilter, not Cisco stuff.
N.B. though that a lot of what might appear to be "Chinese" traffic actually comes from Taiwanese subnets and allocations, so you might have to blackhole Taiwan to be effective as well. At some point you're going to have to decide what makes sense to block versus just deal with.
posted by Kadin2048 at 12:04 PM on August 3, 2012
The downside is this will do the blocking at the host level rather than at the gateway or firewall level, which might be where you want it.
Fail2Ban is a nice tool which reads Apache-style error logs and builds up firewall rules to ban the offending hosts. Of course, your MTA would need to create Apache-style logs, and it may not work for that Cisco firewall without a bunch of configuration.
If you're getting the impression that most of these tools are Linux-centric, you are right. In particular, they tend to be LAMP-stack specific, and assume that the firewall is on the same box as Apache, etc. I'm not sure if there are any more "enterprisey" solutions, although I suspect there are if you want to pay for them.
Honestly if you don't have any legitimate business traffic from China, it's fairly straightforward to build up firewall rules to just drop all traffic from the IP allocations assigned to them. You need to be really sure that you're never going to have any legitimate traffic from there (keeping in mind that settings like this have a tendency of being forgotten and living on forever). The common way to do it is to download a list of IP range allocations and then use scripts to mangle the text around into something that you can load into your firewall of choice. See the second answer in this thread. Note that it is using netfilter, not Cisco stuff.
N.B. though that a lot of what might appear to be "Chinese" traffic actually comes from Taiwanese subnets and allocations, so you might have to blackhole Taiwan to be effective as well. At some point you're going to have to decide what makes sense to block versus just deal with.
posted by Kadin2048 at 12:04 PM on August 3, 2012
Best answer: I could create (or copy - I know there are sites that already list these) giant access lists for our Cisco ASA to block the entire nation of China but I'm not sure if this is the best approach. I assume our firewall will take a massive performance hit if I do this.
It really is the best solution here if, as others are asking, you don't have any conceivable need for traffic from China. When you're seeing network probes and brute force attacks, it's more than passwords that you need to worry about. You have to start worrying about every piece of hardware and software on the network. Just block the traffic and move on. It only takes one breached email account to put the whole network at risk.
When we had this problem about six years ago at a biggish ad agency in New York, in the key outside-facing Cisco routers we simply blocked every Class C address that belonged to China. We put the filters on both of the redundant networks through which our traffic flowed. Stopped most of our spam and intrusion attempts. It caused no problems whatsoever and no slowdowns. (I don't remember which Cisco box it was, but it cost more than $100K.) We may have had had a Cisco consultant come in to do the work, just to make sure it was done right. We blocked a few other countries in Central Asia, as well. We explicitly allowed some ranges that we knew belonged to the Asian offices of our clients, considering those relationships too important to risk overzealous filtering.
This and this may be of some help.
We also, by the way, had a great deal of success with SpamAssassin when it came to filtering out emails with suspicious payloads, which is a common way to get into a network. That took a great deal of worry away from the notion that a trojan might arrive in an email and do some damage that way. SpamAssassin machines were the first to receive all incoming and outgoing mail. You couldn't send or receive mail without it being filtered if you used our servers, and then your mail client did its own thing on top of that. We contemplated blocking the common SMTP ports, or routing it all to those SpamAssassin machines, but that proved to be too much of a hassle. The idea was to filter your mail even if you were using someone else's email server to send or receive.
posted by Mo Nickels at 2:13 PM on August 3, 2012
It really is the best solution here if, as others are asking, you don't have any conceivable need for traffic from China. When you're seeing network probes and brute force attacks, it's more than passwords that you need to worry about. You have to start worrying about every piece of hardware and software on the network. Just block the traffic and move on. It only takes one breached email account to put the whole network at risk.
When we had this problem about six years ago at a biggish ad agency in New York, in the key outside-facing Cisco routers we simply blocked every Class C address that belonged to China. We put the filters on both of the redundant networks through which our traffic flowed. Stopped most of our spam and intrusion attempts. It caused no problems whatsoever and no slowdowns. (I don't remember which Cisco box it was, but it cost more than $100K.) We may have had had a Cisco consultant come in to do the work, just to make sure it was done right. We blocked a few other countries in Central Asia, as well. We explicitly allowed some ranges that we knew belonged to the Asian offices of our clients, considering those relationships too important to risk overzealous filtering.
This and this may be of some help.
We also, by the way, had a great deal of success with SpamAssassin when it came to filtering out emails with suspicious payloads, which is a common way to get into a network. That took a great deal of worry away from the notion that a trojan might arrive in an email and do some damage that way. SpamAssassin machines were the first to receive all incoming and outgoing mail. You couldn't send or receive mail without it being filtered if you used our servers, and then your mail client did its own thing on top of that. We contemplated blocking the common SMTP ports, or routing it all to those SpamAssassin machines, but that proved to be too much of a hassle. The idea was to filter your mail even if you were using someone else's email server to send or receive.
posted by Mo Nickels at 2:13 PM on August 3, 2012
> email access via iThings, but now it's expected from the top down
Use an On-Demand VPN and you won't have to expose IMAP or POP to the outside world.
posted by morganw at 4:01 PM on August 3, 2012
Use an On-Demand VPN and you won't have to expose IMAP or POP to the outside world.
posted by morganw at 4:01 PM on August 3, 2012
Best answer: Thirding blocking all traffic from APNIC IPs. This is a lot more common than you suspect, and not terribly computationally demanding—no more than a few hundred IP ranges. Just a couple of days ago I came across a list of APNIC IPs in CIDR format—I've just tossed it up on a Gist for you. You might just drop this list in to solve your immediate problem, but you'll really want to get a proper list from a trusted source (e.g., APNIC).
More than a decade ago, running a personal Sendmail box, I blocked all mail originating from China, after confirming that none of my users knew anybody in China. That eliminated a supermajority of spam. I never regretted it.
posted by waldo at 8:15 PM on August 3, 2012
More than a decade ago, running a personal Sendmail box, I blocked all mail originating from China, after confirming that none of my users knew anybody in China. That eliminated a supermajority of spam. I never regretted it.
posted by waldo at 8:15 PM on August 3, 2012
« Older Reason vs emotion: Can't afford baby. Want a baby... | How-much-is-this-worth-filter Newer »
This thread is closed to new comments.
You should be enforcing a password complexity policy at minimum. You don't have to go the "rotate every 90 days" "can't reuse any of your last 12 passwords" routes, but at least enforce a minimum length and use of mixed case. That will do wonders for you.
You may not see as much of a hit as you think. If you know what networks these are coming from, you can probably block single subnets that take out the majority of these.
Another option, if you know where your users will be accessing email from, is do the "deny all with exceptions" policy for accessing email. This gets tricky once you involve cell phone access and remote users. Enforcing VPN usage isn't something people like to do, but it certainly takes care of it.
posted by MysticMCJ at 11:10 AM on August 3, 2012 [1 favorite]