I would like to hear real stories, how your linux box/server was hacked and what you do not to fall in to the same hole again.
About 2 years ago one of my co-located web servers was hacked. I tracked down the vulnerability to be in a php script I was running, an old version of PHPBB. The hacker basically used a hole to place a script on my server and execute it, which gave him full access to the server.
Luckily, he didn't do any damage, he simply installed a new website to be served off my box.
I was going through the logs one day, as I had seen my bandwidth usage skyrocket, and I found that he had installed a spoofed copy of another website on my server. Essentially it was an easy misspelling of an online store for watches, and I believe he was selling watches, collecting money, and obviously never sending anyone anything.
After I discovered this, I made a copy of everything he did - logs, scripts, the entire website, and archived it as well as sent it to my hosting provider.
I cleaned up his tracks, and began to secure my server.
As a result, I learned a lot about Linux security, and did several things:
- Tightened up my SSH security including running it on a non-standard port.
- chrooted apache
- Installed and configured apache mod_security (which is amazing)
- Started running some log monitoring/intrusion detection scripts
- Killed any processes running on ports which I was not actively using
As a result, I have not been hacked since, and whenever anyone tries, I am alerted.
Some of the easiest ways your server can be hacked, if it is a standard web/email server are through common script vulnerabilities. You also should take extra steps if you are running an email server to ensure you are not an open relay of any kind, the spammers will find you and suddenly all email coming from your server will get blacklisted.
Couple of years ago I've created a user with a name consisted of two symbols. I haven't thought though that well experienced hacker that this account is was for could use his login as a password. Of course that machine was hacked in a week and when I asked the guy, what he was thinking, he told me that he wasn't aware that someone can check every possible short user name on the server and he knew for sure no one could get the list of users so he thought he was safe enough.
Hackers installed some kind of back door and probably used this machine to send spam. Luckily it wasn't such an important server so we just reinstalled OS on it.
The hosting solution (unsupported dedicated server) was cheap and sounded cool, I didn't really know what I was doing, didn't keep the system up to date and I probably had done something bad with iptables/ipchains configuration. One day when backpacking around Western Europe I fired up the site and nothing was there.
My solution was to abandon everything and trust someone else until such a time that I'd gained more server admin experience; that was about 7 years ago and I still trust the other guy!
~5 years ago I was working as a system administrator at our university and our workstations that ran an outdated version of suse (it wasn't my fault!) had been hacked with the ssh exploit that was also used in matrix btw.
As result our boss removed the route to the gateway to "shield" our workstations, because they couldn't connect to the outside world. There was only one server that was in both networks and was used as login server from the outside...
Many years ago, I was somewhat responsible for a clients system. The system was not being patched and it had somehow gotten removed from my list of systems to maintained.
A security flaw in bind allowed someone to get into the system and get root. They used the system to send out spam and they setup a web server. While bind was installed on the system it actually wasn't being used for anything
The results of the intrusion
- pulled the hd in-case the police wanted to see it
- reinstalled the OS on a new hard drive
- restored the data from an older backup
- remove un-needed package (bind) which was the vector for the attack.
- applied security patches, and setup a system to notify the system's owner when a patch needed to be installed
- setup better activity logging for all our systems
- tweaked our backup selections because a couple things where overlooked.
Last December, my main Linux server got many complaints via selinux's tool
setroubleshooter. The two categories were
- SELinux is preventing the sh from using potentially mislabeled files (./x).
- SELinux is preventing the http daemon from connecting to the itself or the relay ports
Looking in my HTTP access logs, I saw lines like
18.104.22.168 - - [05/Dec/2008:04:32:11 -0600] "POST /wordtrans/wordtrans.php HTTP/1.1" 200 1348 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
Looking in the HTTP error log, I also saw complaints. I then used wordtrans myself to compare a true use vs what I had in my logs; I had wordtrans installed as a toy that I didn't truly need. True use of wordtrans had many GETs along a few POSTs. The attack only had POSTs.
I Googled for "http attack wordtrans" and found the version I had installed was attackable, so I immediately uninstalled the
Had I not been running selinux, the attack certainly would have been successful, and I wouldn't have known.
This is yet another lesson to not run any service (that is exposed to the public internet) that you don't truly need. Each service installed, however small, including PHP packages, web services, etc, is a potential attack vector. Also, my decision to enable selinux with that install months earlier had been a good one.