A Chinese IP address shows up in our logs as accessing one of our surveys but it stands out because the user tried adding a string to the end of the survey's URL (as if trying to perform a SQL injection attack).

Because the whois lookup for the IP address is from China it seems practical to block the entire IP range. We do have one client in Hong Kong but their surveys are aimed at business users from Singapore, Australasia and USA more than China itself.

Is it better to block the IP address or leave it open?


12 Answers 12


Depends, again.

If you block the IP, it's not hard to just change the IP.

If you block the range, you get a lot of collateral damage from people who can't get in but were innocent. Doesn't stop a lot of people from still blocking country ranges of IP.

If you have a select number of clients that are getting access to the site in question...it's a semi-private database, for subscribers only, etc...you can just block access to all but accepted whitelists to that portion of the site only.

Otherwise you would need to keep updated, updated, updated, and periodically have your code audited by outside contractors for injection attacks and other hazards, and probably have something like Tripwire installed on the server to watch for suspicious changes and alterations on the server (and keep good offline backups. More than a few sites have had "live" backups that suddenly get hacked or erased once entry has been gained to the network).

In my experience blocking specific sites and hack attempts is messy and doesn't necessarily stop the problem. If it's a repeated hit over and over you could look at a solution that sees problematic slamming of your site and have it automatically blocked for a period of time (kind of like denyhosts for SSH) so it's kind of a transient, "enough already" blocks that don't clutter your system forever. It's just too easy for scripted attacks to hit from the left one day then appear on the right the next, and you'll end up running in circles chasing your tail trying to stop these idiots.

Make sure your server is secured off your LAN, segmented to prevent a hack on that system from contaminating the rest of your network. Audit it. Watch the logs for suspicious activity. Block only really problematic IPs (like denial of service attacks) at the router. Otherwise...my vote is that it's a hassle to stop them unless you have some automated way to track it and a way to automatically remove it after a period of time.


If it appears not to be bot, you could take advantage of this. You could set up another server with dummy data, redirect to that based on the source IP, and watch them hack it. Companies pay for penetration testing, as Bart said with "Code Audits". So if the hacker manage to get through, you can submit that to the developers, and you just got free work from the hacker :-)

Never done this myself, but if you have the time / resources, might be fun...

  • 2
    Props to anyone who can tell me if that strategy is in the Art of War, and how is it expressed ;-) – Kyle Brandt Sep 4 '09 at 12:07
  • 1
    The Art of War has a chapter on "_h_ts and Giggles"? – Bart Silverstrim Sep 4 '09 at 12:15
  • 1
    This is called a honeypot - a server you put out there to look like a better, more vulnerable target to hackers to take their attention away from your prod servers. Could even "accidentally" leak an internal hostname like "FINANCESERV" or something that looks worth hacking while they are probing your IP range to get them to focus their attention on it. Be careful with this strategy though as you may end up drawing too much unwanted attention and use up bandwidth that should be taken by your regular customers. It is also VERY important to isolate the honeypot from the rest of your servers. – August Sep 4 '09 at 14:52
  • August: I thought a honeypot is a bit different, as it is an 'easy' target. I recommened that he use a copy of the actual server with different data to see if there are any holes, not setting up some sort of easy target. – Kyle Brandt Sep 4 '09 at 17:40
  • 1
    @Kyle: Straight: "Hold out baits to entice the enemy. Feign disorder, and crush him."; Cunning: "The enemy's spies who have come to spy on us must be sought out, tempted with bribes, led away and comfortably housed. Thus they will become converted spies and available for our service."; Humorous: "At first, then, exhibit the coyness of a maiden, until the enemy gives you an opening; afterwards emulate the rapidity of a running hare, and it will be too late for the enemy to oppose you."; classics.mit.edu/Tzu/artwar.html – ErikE Jan 1 '14 at 22:10

I wouldn't block the IPs manually. I might however, set up a fail2ban script to programatically block user's IPs for a short amount of time, based on the apache logs (I'm assuming you're using linux. Substitute your OS, and script of choice). It's not perfect security. It just makes life a tiny bit harder for the bad guys, at little cost to yourself.


Many of the alternative solutions given above on securing and monitoring your servers would be better use of time than simple bans, especially for IPs from China. All the major telecoms(there's really essentially two, but I digress) offer broadband service with dynamic IPs for just about all home and small to medium businesses. Unplugging and replugging a router is all it takes to switch over to an IP that's not blocked.

Also, in a country with such a restrictive policy on the internet, you can be pretty sure that anybody savvy enough to be trying to attack or hack a server is familiar with and most likely regularly makes use of proxies and other methods of tunneling or relays, and would barely be affected by a simple IP ban, even if they were operating from a static IP.

Also, having lived in China for the last X years, it's really annoying to try and load a page and be told the IP has been blocked for abuse because some douche-bag who had the IP earlier didn't have anything better to do. Blocking entire IP ranges without a strongly backed up reason always seemed a bit extreme to me.


I think its good practice to regularly audit your logs. Some people dont even do that.

I agree with all advice here. Blocking the IP probably wouldnt hurt, but you cant really block EVERY IP that some bot tries to connect from....I've tried that. I suppose if its not a bot, then block it. Maybe it will send a message. You cant really be sure what resources are at the other end.

I would say pay careful attention to your logs (obviously). Make sure your machine is updated. Also, make sure you have a backup in case something horrible happens.


My personal opinion? Blocking won't help!

Basically, when blocking IP's becomes company policy then you'd get a false sensation os security, because you think you're blocking the bad guys. Reality? Bad guys know how to switch to other systems and thus other IP addresses while the IP address they mis-used will just continue to be blocked. If that IP address happened to be linked to a legitimate user then that user would be blocked, while the hacker just uses another gate to get in your site.

No, if a hacker tried to hack your site, check if he succeeded in his attack. Try to replay his attack if possible. And if he was successful, you should patch the leak in your server, not block the hacker. To be honest, hacking attempts can be useful to your site to show how secure it is. If you get hacked then your security wasn't good enough and you should blame your own technical staff, not the hacker who attacked you.

You won't stop hackers by blocking their IP address. Sooner or later you end up blocking half the Internet...

  • Blocking does help, depending on your needs. A wiki I run occasionally gets spammed. I can either block the address and clean up the mess once, or leave things as-is and clean up the mess repeatedly over the next few days, weeks, or months. At any given time there are between 0 and 20 addresses in my blacklist. Certainly not half the Internet. (I'm using the "blacklist" utility from apachesecurity.net/tools so the entries time out after a while.) – Gerald Combs Sep 4 '09 at 16:32
  • Blocking for a short time is more effective than a permanent block. Then again, many forums won't allow a visitor to post new messages within a certain amount of time since their last message. Often just a matter of seconds. Other forums will also allow only a certain amount of posts per member, also to avoid spam. However, who is going to stop a spammer who will misuse a spambot network to DDOS a popular forum full with spam messages? Blocking won't even help in that case. A better design of the web page might be more effective since it has a flaw that allows misuse. – Wim ten Brink Sep 7 '09 at 8:27

My policy is that if the source is causing performance problems or has managed to actually find a hole (hosting other people's shoddy sites has it's disadvantages) then it gets blocked, otherwise let them beat their little brains out, fly style.


Here are some guidelines:

You should keep your internet facing servers up to date, audit your scripts, use security zones, jails, chroots where applicable, use an something like tripwire to audit changes and maybe a IDS on a spanning port (it 's up to you to make good correlation of what's happening there as an attacker may flood your IDS hiding the real attack.)

Blocking just an ip may be just a wasting time under a real attack scenario.

Hope this helps.


Do not block entire IP addresses from another country, just because they're from another country, and you don't care so much. That's potentially racist. At the very least, it's not in keeping with the open, peer-based, global community that is The Internet.

The best thing to do is:

  • Block them temporarily

  • Find out who's responsible for abuse on that network with:

    whois the.abusers.ip.addr | grep -i abuse
  • Email them, making it clear that you expect this to be dealt with quickly, or you'll be taking it to THEIR ISP, one tier up. Add that you'll be blocking their ENTIRE RIPE allocation too, if you own a network / customers big / important enough that it'll make a dent.

    • Assuming it gets sorted out, thank the OrgAbuseEmail guys, and remove the block. Otherwise, implement the threat, report the ip / network to spam filters, etc.

If permanently banning is what you want to do, then you may adopt a different strategy for permanently blocking an IP address by looking at your authentication log using grep -a sshd /var/log/auth.log to see who is trying to access your ssh. It is easy to see if someone is trying to use brute force as you can see they will try to use some commonly used user names and try to connect to your ssh over and over. If someone is trying to do that, at the very least, they are certainly up to no good and you may go ahead and ban them. That's what we do on our servers.


Blocking IPs works. Yes, IPs can be spoofed or theh can get a VPN but that’s not the reality. Hackers that can spoof an IP and get a response back or can use multiple VPNs don’t care about your web site.

The vast majority of hack attempts come from losers that don’t even know what to do when they get through. The best way to stop them is to block entire ranges (use online IP whois tools) and sometimes entire countries. It’s easy and it works.


Old thread, more subjective than desirable in most ways.

If you are only servicing a country or a well-known ip range, it's easier to allow traffic only from these sources, but if you want to block hacker's IP's, you'll fail, because proxies & zombies are there, and most of them keep unknown until it's too late (for you).

See Bart Silverstrim's response, it's quite complete, I'll add only one thing, ask yourself what made you visible for them, maybe old software or old OS running, no secure protocol, too much open ports... People are lazy, hackers are people too (there are a few talented ones, but the rest are "wannabes" & "in-pretending"), usually they'll attack the easier prey.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.