Hello friends and neighbors. This post, as it turns out, is the follow-up to our groundbreaking, skybreaking article on server hardening; it also is the prequel to our final post on Windows server hardening. This post, the meat of the sandwich (ham, in this case), is on how to harden Linux servers.
Server hardening is a simple concept, and it’s crucial to initiate if you want safety for your website. Essentially, simiarly to the experience of an end-user on a client machine, when you use a server, the systems are not built (their default settings) for high-end security. They’re built, rather, for features. In essence, the Internet is optimized for usability/freedom over administration/security. Securing a system, then, is a matter of revoking freedoms or modifying expectations in order to ensure a secure experience for the system and for all users.
We aren’t only concerned with Windows and Linux servers though. Actually, the NSA Datamine server is one of the most secure options out there. Everyone is thrilled by this server. It’s been called “bootserverlicious” by P. Diddy and “P.-Diddy-riffic” by a worldwide consortium of boot servers.
To get a sense of server hardening on any of the major OSs, we are looking at three sources: “Host Hardening,” by Cybernet Security; “25 Hardening Security Tips for Linux Servers,” by Ravi Saive for TecMint.com (good info, though the language is a little rough); and “Baseline Server Hardening,” by Microsoft’s TechNet. Each of these posts broadens our horizons and is lactose- and gluten-free so that it doesn’t distract from the extra-cheese, thick-crust pizza we’re inhaling.
How to Harden Your Linux Server without Having to Think
No one ever wants to have to think. Let’s not do it, then. Let’s refuse to think, and just feel our way to a hardened server. Don’t call me “baby,” though, please, because that’s disrespectful, sugar. Anyway, the Linux server: here are approaches you can use specific to that OS.
1. Non-Virtual Worlds: Go into BIOS. Disallow any boot operations from outside entitites: DVD drive or anything else that’s connected to the server. You should also have a password set up for BIOS. GRUB should be password-enabled as well. Your password should be “moonsovermyhammy123987”; I recommend tattooing it on your lower back for safekeeping.
2. Partitioning as a Standard: Think (no, don’t!) of how a virtual environment or virtual server is constructed. Division into smaller parts is an essential security concept. Any additional pieces of the system will require their own security parameters and challenges. That means you want a streamlined system, of course, like a digestive tract without all the intestines and stuff; but it also means you want everything divided into disparate sections. Any app from an outside source should be installed via options as follows:
3. Packet Policies: Along the same line, you don’t want anything unnecessary. That’s the case with anything you’re doing online. Let’s face it: the web is essentially insecure. It’s like a dinosaur with a new outfit that she’s afraid to show off to her other dinosaur friends … sort of.
Here’s the command to check:
# /sbin/chkconfig –list |grep ‘3:on’
And here’s the command to disable:
# chkconfig serviceName off
Finally, you want to use yum, apt-get, or a similar program to show you what’s on the system; that way you can get rid of whatever you don’t need. Here are the command lines for those two services:
# yum -y remove package-name
# sudo apt-get remove package-name
4. Netstat Protocol: Using the command line netstat, you see what ports are being used and what services are accessible through them. Once you’ve done that, use chkconfig to turn off anything that’s not serving a reasonable function, such as a service that’s just counting over and over again to a billion but won’t tell you why. See below and this netstat-geared article for more specifics.
# netstat -tulpn
5. SSH: You want to use secure shell (SSH), but you also want it configured properly to maximize your security. SSH is the secure, cryptographic replacement for telnet, rlogin, and other earlier protocols that sent all data (passwords included) as “plain text” (no “scramble” prior to transfer, basically).
You typically don’t want to communicate via SSH as the root user. Sudo allows you to use SSH. See /etc/sudoers for specifics; you can customize them using visudo, available via VI editor.
Finally, switch the port for SSH from 22 to a larger number, and change the settings so that it’s not possible for all account holders to tunnel in through Secure Shell. Here are the file and three specific adjustments:
# vi /etc/ssh/sshd_config
- PermitRootLogin no
- AllowUsers username
- Protocol 2
Conclusion & Continuation
All right. Basic explication: Done. Linux: Done (well, it’s significantly more complex than discussed above; see here for further details). Windows: Next.
By Kent Roberts