I run a number of Linux servers, across multiple public IP ranges, so the chances of one of my servers appearing in a script kiddies network range port scan is quite high.
About 12 years ago, when I first got my hands on a physical server (an old Fore Systems box)I ran Redhat 7 with a multitude of services enabled, most I didn’t use but what the heck.
After a few months of experimenting with all of the common Web services, I was sat working and heard both HDD on the server whirring away with both disk access lights showing red.
I wasn’t using the server, but something was hammering the disks I soon discovered somebody had got in via the anonymous FTP service and managed to root the server, soon after I pulled the network cable and tried to salvage anything I could.
I learnt a valuable lesson, only make services public that you want the public to access!
Server security seems to be a bit of a grey area, quite a lot of companies rely on simply employing a firewall in front of their servers.
Security server rack (Photo credit: rgsproductions2005)
That’s all well and good but as part of server security you have patching and maintenance, which should be carried out periodically to plug any vulnerabilities.
Recently I spun up a test instance with a popular VPS (cloud) provider, within a week I had numerous brute force attempts; all of which where stopped in their tracks quite quickly.
I managed to track one particular attempt, it appeared the attacker had compromised a web server and launched their brute force attack from there. The website hosted on that particular server had very lack security, and considering they operate an online store security should be number one priority.
Quite worrying that on the face of it a website gives the impression to a user they are secure, they handle transactions over secure HTTP and have the numerous ‘Secured by’ buttons neatly stacked on their payment page, yet the underlying OS stack lacks basic security.
Basic server security can be achieved quite easily and with zero cost (if the work is carried out in-house), when building any server these days I always apply these principles:-
Keep it simple, base package install, disable or remove unnecessary services, remove unnecessary modules / config from running services
Keep it locked, lock down access using IPTables, TCP wrappers & only bind a service on the public IP if its really necessary, use SSH keys with a passphrase
Keep it logged, log auth requests in a seperate file, use a log analyser to block brute force e.g. denyhosts
Keep them guessing, don’t run SSH on port 22 script kiddies will always scan port 22, don’t allow external SSH if possible; run on a higher port if really required
Keep it clean, remove / disable any user accounts not in user, ensure all active accounts have strong passwords, remove any sensitive data
It really isn’t that difficult and just requires a bit of time.
If you run your own server and aren’t sure if it’s secure, then please get in touch as I offer a free consultation and a recommendation report.
Contact details can be found at the top of the page.