E
Eric Hansen
Guest
Everyone has their own ways, protocols and methods to securing systems. By no means are these de-facto points, heck maybe not even usable by you, but they have treated me well over the years.
Remove root Login Ability
While SSH provides the ability to disallow root logins (“PermitRootLogins no”) its always safe to enforce it whenever possible. As root (ironic? just use sudo su
) edit “/etc/shadow” and where you see “root:...” replace the text (if any) between the first and second “:” with “:!:” which will essentially lock the account. So in the end your line should look like this:
Change Network Programs’ Default Ports
Another one of my favorites, and this does have good value for most networks. For example, you have SSH that normally listens on port 22. Just change the SSH config file to listen on a different port (maybe even one higher than 1023 so it doesn’t have to be run as root ). This will combat most port scanners since they will only attempt the most common ports.
Bind Network Programs to Specific IPs
I like this when I have more than one IP to a machine, otherwise its kind of pointless (but still has use for programs like database servers). Basically the idea behind this is that instead of being able to scan 10.0.8.1 or 10.0.8.2 (assuming those two are assigned to the same server) and get a response because MySQL is listening on 0.0.0.0 (all interfaces/IPs), it would only be detectable on one specific IP which reduces the ability to map out a network.
Make Network Programs Use Unix Sockets
I don’t know if all server programs (i.e.: MySQL server) can, but I know MySQL server can along with some others. Basically this allows a bit of anonymity on the network stack. The idea is that everything (sockets, files, devices) are nothing but files in Linux. So while Linux does have access to your network adapters themselves, they are represented by files. This also goes for sockets, they are nothing more than file descriptors, similar to stdin and stdout (input and output).
For example, with MySQL server, if you enable “skip-networking” MySQL server doesn’t bind to an adapter but it still works just fine. The way Linux handles sockets as described above is the reason why. Now, there’s more to it but its irrelevant to this post.
The benefit to this is that if someone does gain access to the server they won’t immediately tell by running netstat or ss what is listening where. I haven’t noticed any real performance difference but your mileage may vary.
Reduce A Server’s Purpose
This one is not possible for all, but if it is then its highly advisable.
Little scenario: you have a network of 2 servers. You need a database, email and web server. You decide that one should be dedicated to email and the other will handle both the web and database tasks.
Now, lets say that the email server program gets a vulnerability. You can remove it from the network temporarily, apply the patch, and bring it back up. No conflict with anything else. However, the web server also has a vulnerability. The email system relies on the database for user authentication and other tasks (MySQL vhost), and the web server needs to stay live otherwise you’ll lose $1 billion in revenue. So it’s not easy to bring down just part of the server without interrupting another part.
At this point, you’re risking two servers and three services at once because you didn’t isolate each service to its own machine. While there are solutions to this (some easier than others) its still an easily avoidable issue all together.
I learned this hard way that this is a necessity.
What you can do, however, that I’ve found to be beneficial as well, is to use LXC (or any other virtualization solution, LXC is just usually found in every kernel) to create different virtual instances for each use. They’re still segregated from the network of sorts and can be brought down easily without intervening with another.
Remove root Login Ability
While SSH provides the ability to disallow root logins (“PermitRootLogins no”) its always safe to enforce it whenever possible. As root (ironic? just use sudo su
) edit “/etc/shadow” and where you see “root:...” replace the text (if any) between the first and second “:” with “:!:” which will essentially lock the account. So in the end your line should look like this:
Code:
root:!:15936:0:99999:7:::Another one of my favorites, and this does have good value for most networks. For example, you have SSH that normally listens on port 22. Just change the SSH config file to listen on a different port (maybe even one higher than 1023 so it doesn’t have to be run as root
). This will combat most port scanners since they will only attempt the most common ports.Bind Network Programs to Specific IPs
I like this when I have more than one IP to a machine, otherwise its kind of pointless (but still has use for programs like database servers). Basically the idea behind this is that instead of being able to scan 10.0.8.1 or 10.0.8.2 (assuming those two are assigned to the same server) and get a response because MySQL is listening on 0.0.0.0 (all interfaces/IPs), it would only be detectable on one specific IP which reduces the ability to map out a network.
Make Network Programs Use Unix Sockets
I don’t know if all server programs (i.e.: MySQL server) can, but I know MySQL server can along with some others. Basically this allows a bit of anonymity on the network stack. The idea is that everything (sockets, files, devices) are nothing but files in Linux. So while Linux does have access to your network adapters themselves, they are represented by files. This also goes for sockets, they are nothing more than file descriptors, similar to stdin and stdout (input and output).
For example, with MySQL server, if you enable “skip-networking” MySQL server doesn’t bind to an adapter but it still works just fine. The way Linux handles sockets as described above is the reason why. Now, there’s more to it but its irrelevant to this post.
The benefit to this is that if someone does gain access to the server they won’t immediately tell by running netstat or ss what is listening where. I haven’t noticed any real performance difference but your mileage may vary.
Reduce A Server’s Purpose
This one is not possible for all, but if it is then its highly advisable.
Little scenario: you have a network of 2 servers. You need a database, email and web server. You decide that one should be dedicated to email and the other will handle both the web and database tasks.
Now, lets say that the email server program gets a vulnerability. You can remove it from the network temporarily, apply the patch, and bring it back up. No conflict with anything else. However, the web server also has a vulnerability. The email system relies on the database for user authentication and other tasks (MySQL vhost
), and the web server needs to stay live otherwise you’ll lose $1 billion in revenue. So it’s not easy to bring down just part of the server without interrupting another part.At this point, you’re risking two servers and three services at once because you didn’t isolate each service to its own machine. While there are solutions to this (some easier than others) its still an easily avoidable issue all together.
I learned this hard way that this is a necessity.
What you can do, however, that I’ve found to be beneficial as well, is to use LXC (or any other virtualization solution, LXC is just usually found in every kernel) to create different virtual instances for each use. They’re still segregated from the network of sorts and can be brought down easily without intervening with another.
