Stop Leaving Your Door Open: Essential Linux Hardening
It is 2010. The internet is not a friendly neighborhood; it is a war zone. If you deploy a default installation of CentOS 5.4 or Debian Lenny and leave it connected to the public internet for ten minutes without a firewall, you are already compromised. I have seen /var/log/secure files balloon to 4GB overnight simply because a lazy sysadmin thought "security through obscurity" would save them.
Whether you are running a high-traffic e-commerce setup or a critical database backend, the physics of security remain the same. You need isolation, you need strict access control, and you need to stop trusting default configurations.
1. The SSH Lockdown
The first thing a bot does is hammer port 22. If you are still logging in as root with a password, you might as well hand over your keys. Here is the standard procedure we enforce on every CoolVDS managed hosting environment:
Open your config:
vi /etc/ssh/sshd_config
Change these lines immediately:
PermitRootLogin no
PasswordAuthentication no
Protocol 2
Port 4422 # Or any non-standard high port
Moving SSH off port 22 does not stop a determined hacker, but it keeps the logs clean of script-kiddie noise, saving your I/O for actual work. Always create a sudo-user with an RSA key pair before you restart the service.
2. Iptables: The First Line of Defense
We don't have fancy GUI firewalls on serious servers. We use iptables. It is robust, it is inside the kernel, and it works. The strategy is simple: Drop everything, allow only what is necessary.
Here is a baseline script for a web server:
# Flush existing rules
iptables -F
# Default policies: DROP everything
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow localhost (vital for local database connections)
iptables -A INPUT -i lo -j ACCEPT
# Allow established connections (so you don't lock yourself out)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (New Port), HTTP, HTTPS
iptables -A INPUT -p tcp --dport 4422 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Save this. On RedHat/CentOS systems, use service iptables save to ensure it persists after a reboot.
3. Banning the Brute Force: Fail2Ban
Even with a non-standard port, you will eventually be found. You need active intrusion detection. Fail2Ban is the tool of choice here. It parses your log files (like /var/log/auth.log or /var/log/secure) and updates iptables rules dynamically to ban IP addresses that show malicious signs.
Pro Tip: Don't just ban them for 10 minutes. Set the bantime to 3600 seconds or more. If an IP fails to log in 3 times in 60 seconds, they are not a user; they are a script.
4. The Norway Factor: Latency and Law
Hardware is only half the battle. Geography is the other. If your customers are in Oslo or Bergen, hosting in a US data center is negligence. The latency alone will kill your application's responsiveness. We engineered the CoolVDS network to peer directly at NIX (Norwegian Internet Exchange), ensuring milliseconds of ping times within the Nordics.
Furthermore, we must talk about the Personal Data Act (Personopplysningsloven) and the Datatilsynet requirements. Keeping data within Norwegian borders is often a legal necessity, not just a preference. Unlike budget providers overselling resources on OpenVZ containers, CoolVDS uses Xen-based virtualization. This provides true memory and disk isolation, ensuring that a "noisy neighbor" or a compromised VPS on the same physical node cannot bleed into your environment.
5. Filesystem and Services
Finally, disable what you do not use. A default installation often enables services like sendmail, cups (printing), or rpcbind. If you are not printing from your server (and why would you be?), kill it.
chkconfig cups off
chkconfig rpcbind off
chkconfig sendmail off
For storage, disk I/O is usually the bottleneck. While standard SATA drives are cheap, for database-heavy workloads, you should be looking at our high-performance RAID-10 SSD (Solid State Drive) setups. They are cutting-edge and expensive compared to spinning rust, but the performance gain for MySQL queries is astronomical.
Conclusion
Security is not a product; it is a process. By securing SSH, configuring strict iptables rules, and choosing a provider that understands the importance of hardware isolation and local Norwegian compliance, you build a fortress, not just a server.
Do not let your infrastructure be the low-hanging fruit for botnets. Deploy a hardened, compliant VPS Norway instance on CoolVDS today and sleep better tonight.