Everything about Web and Network Monitoring
Everything about Web and Network Monitoring
People who are familiar with me know that there are two things I’m not forgiving about. The first is backups, the second is security.
If backups interest you, perhaps we can discuss it some other time. This time we’re going to discuss security.
I’m going to outline in the following article some of the best practices I’ve learned along the years and help you “almost brick up, but not just yet” or “harden” your Linux server.
While reading this article, however, I suggest also reading this article as well. As we both try to tackle the same issues. I believe both articles eventually represent the same views in a different guise.
All of the ideas I’m coming up with are already implemented in shk. I suggest downloading shk, reviewing the code and using it.
Do you know what is secure? – a brick.
Yes, but a brick is not functional.
When I’m trying to build a secure system, I’m using the same concepts as if I’d like to secure my house.
Yes, a house is functional.
Is the front door of your house in a conventional place? – if it is it does make it easier not only for you, but also for everybody else to enter.
Imagine the door to your house would be placed 30 meters away from the house and you’d have to remove leaves and branches over a floor door, unlock it, open it, crawl 30 meters to your house, open and unlock the house’s main door, and only then you’ll be at home.
I bet such an entrance would surprise any potential burglar.
So what’s your door for accessing your machine?
Yes, it’s usually SSH. If it’s telnet, rsh, or any other unencrypted protocol, you live in the 1970s, please update yourself, together with your haircut.
SSH on port 22 would usually get knocked quite a lot, be it bots, or kiddies, trying to see what’s in.
Don’t believe me? – run:
# lastb It’ll list all the incorrect login attempts which would usually be via SSH attempts.
How do we dig the trench away from the house and install the neat floor door? – simply move SSH to a different port. It’ll fend off most of the scanning attempts.
Port knocking can add some extra security here, but I believe that port knocking also requires you to walk around with a crowbar on a daily basis – as port knocking more or less means you keep the floor door jammed – and only the correct crowbar would open it.
Since I’m not Gordon Freeman – I’m not wandering around with a crowbar and do not use port knocking.
With SSH moved to a different port, you should ask yourself if your door is really secure.
Is your root password strong? Honestly?
And other users on the system? Do they have a secure password? Does it matter?
After you’ve reset the root password to something which is really strong, it’s time to enforce SSH to allow only the root user.
This more or less means that even if you gave your neighbor the key to your house – in order to feed the cat – she wouldn’t be able to do it. Yes, your cat might get a bit hungry, but your house will stay in tact and the and cats usually tent to find a solution when it comes to food…
You’ve just installed a super-secure door, but what about your windows? Have you left any of these unbarred? Redundant?
A redundant window might be a NFS service which runs for no reason at all on your server.
On the other hand, an unbarred window might be a HTTP service which is supposed to be exposed only internally.
It is highly recommended to instantly remove services and packages you don’t use and brick these windows up.
You can use:
# netstat -pan | grep “\bLISTEN\b” This will list the services that are waiting for connections.
Install bars on the unbarred windows, in other words – use a firewall. If your HTTP service is supposed to be used only internally – seal it with a firewall.
Generally speaking, it should be easy for you – the SysAdmin – to easily know which ports of a system should be exposed externally. The rest of the ports you should lock down.
If someone got into your house, even if it’s dark – he can always use a headlamp and pick up whatever he wants to. If someone hacked into your system and got regular user privileges – usually it’ll be super easy for him to gain root access.
Hence, it doesn’t matter if you login as a regular user and than ‘su -‘ or ‘sudo’ to root, it’s all the same. I prefer to just login as root and no other user. It’ll also make you treat things more seriously.
I also don’t bother to remove useful utilities for day-to-day use. I want my systems to be comfortable for me to maintain. I can’t be bothered if comfortability for me means comfortability also for potential attackers. Once they got in they’ll be as comfortable whether there is a sofa in the living room or not.
And I do want the sofa in the living room.
Lock your house – then let your friends hack in.
Security audits are invaluable and should be carried out quite often. Whether by automatic tools such as Paid Monitoring or by colleagues.
If you never try to hack in – you’ll never know how hard it is for an attacker.
When a system is properly secure – it’s hard also for you to hack in. And if it’s hard for you – an attacker would usually find it at least twice as hard, even if he is experienced.. A random attacker has much less information and knowledge as to how your system is built, comparing to you.
Cracks in a wall can cause the whole wall to collapse, rendering your defenses useless.
A crack in the wall can come in the shape of an outdated apache server – with a recent exploit on the wild.
Another crack in the wall could be a 3rd party piece of software you can’t audit – but must expose to the outside world. Be extra cautious with these.
Sending your root password in plain text emails is highly discouraged just as well for the same reasons.
Got hacked?
In real life we will not burn a house that was broken into, but if you did get hacked, assess the situation. In 99% of the cases I would suggest to reinstall the machine freshly. The reason for that is that an attacker could install numerous back doors and it might take you ages to find them.
Reinstalling is a big headache if your system is not setup properly, or if you don’t have proper backups.
But do trust me – in the long run, it is highly recommended to avoid future problems.
If you have a house, people can break into it. Period.
Do trust me though, that usually, if you’ve decided to place your door in a non-trivial place, the casual attacker/burglar will just decide to bother the next server/house.
Carry out the rest of the defenses that are outlined here and you are more than good to go.
It sounds very simplistic, I know. But if there’s something ironic I’ve seen in life is an uber-extra-comprehensive firewall setup on an extremely secure system, and a login of admin/123456 that caused everything to collapse.
shk will help you do the tasks I’ve outlined through this article. Tasks such as:
shk is written purely in Bash and is supposed to work on most Redhat and Debian systems.
The default configuration is a bit forgiving, feel free to play with it as much as you need.
shk is free – I’d be more than happy to receive contributions and suggestions for improvement.
