Don’t Think “If” You Will Get Hacked, Or Even “When” – Think In Terms Of “How Often”

The following “guest post” was a comment left on “How To Completely Clean Your WordPress Installation” by a gentleman named Daniel J. Dick. He makes some excellent points, and due to it’s length I decided to feature the comment in it’s own post, rather than approve it in place. Enjoy.

I think Nick sums up how most of us feel about malicious hackers, script kiddies, and spambots that wreck other people’s stuff.

My apologies to everyone that reads this that are searching out how to fix your blog. It is obviously meant for the little, no good, no life having, soulless human maggot out there that creates viruses, malicious scripts and hacks other peoples stuff. YOU SUCK BIG MOOSE C#&@!!

– Nick

Most of my sites have been on C-panel setups just because of cheapness and laziness on my part. But, I’ve been a Unix / Linux hack for about 30 years, so I grabbed up a VPS, set up Centos 5, Apache, PHP, MySql, Exim, and all the way I like it with a little Perl script to throw anyone who tramples on various triggers into the firewall straight away, and before I even had the thing known to any DNS servers anywhere, it already had trapped about 60 or 70 IP addresses, and they were not false alarms. Now if that many are blocked trying to break into SSH alone, imagine how many would be flooding into the applications that have ports open on any given system, especially AFTER it was known to the world by name!

If you have a website, don’t think in terms of “if” it will be attacked by hackers and spambots, and don’t think in terms of “when” either. Think in terms of enlarging the gaps between times hacking attempts are successful and recoveries are necessary. Think in terms of how many hackers you can trap and report and how many hacking attempts you can block, and how well you can isolate them from the false alarms. If you block them by IP, you’ll find most of your users are on IP addresses shared throughout the comcast and AT&T community, and you cannot block those ranges without blocking out most of your users. So, you may want to block them temporarily, say 2-4 days and release them just to make sure they don’t hit you with a denial of service attack or a brute force attack. This will at least keep your system from being hammered and help reserve your bandwidth and computing resources for constructive work.

Cut back the number of ports you have open. If you put a million door lock onto the front door of your house but the door is made of balsa wood, a 3 year old might kick it in by accident. If you secure your front door and leave your back door open, you’re still out of luck. What are the points of entry? What protections are there on those? If they get in, what can they compromise? Can they use one service to plant a mine for another service?

At one time, everyone laughed at the thought that opening an email could cause a problem. “Email is just a text file.” “You’re just reading it, silly!” True, but what does the email reader do with what it reads? Does it process mime types or any kinds of files? A kidnapper may be unable to unlock the front door of your house, but if he can tell your 3 year old child you won a million dollars and need to open the door to get it, you may end up getting a call with a demand to pay a million dollars in ransom.

So often we think if someone is really competent in security, it will be impossible for any hacker to break in without getting caught. One would like to think that security is a terminal project–one with a beginning and an end, that you can sign off on completion and your work is done forever. It isn’t. No more than ending all war and establishing permanent world peace is a terminal project unless you’re God.

You can set policies, brainstorm, gather ideas, organize them, let them spawn ideas, and let the creative juices flow, and then organize them again until you have a full set of projects, policies and procedures and methodologies for implementing them. You can weigh risks calculating potential losses against costs of prevention and come to an idea of what is most important. You can set up disaster recovery strategies, and in them beware of the fact that when you take backups, there will be times you will be backing up viruses and corruption as well, and many times corruption and viruses may be intertwined into the ongoing collection of data and you’ll need methods for weeding things out whether you like it or not. But, it has to be part of the plan.

But, in the end, it may almost seem like security is about good backups and disaster recovery first and then the rest of the prevention is about performance, reliability, reduction of downtime, protection of reputation, and overall efficiency.

There will be times when there are conflicts between progress and safety. There may be times people feel they cannot get any work done because security is too tight, too insulting, too bothersome, too pedantic, too whatever. And sometimes there will be folks whose die-hard commitment to security is in ignorance hindering progress while providing no real security at all.

It’s a pain, really. And yet every pain has its joy and satisfaction and opportunity to do excellently where others have failed. Without a battle there can be no victory. Without something to overcome, nobody can become an overcomer. It’s a curse and a blessing.

Whew…that was longwinded!
Dan