Imagine you’ve just built a beautiful, high-performance shop in Dhaka’s busiest commercial area. You’ve got the best inventory, perfect lighting, and a prime location. Now, on opening day, you leave every door wide open, the cash register unlocked, and a sign that says, ‘Welcome, anyone can take whatever they want.’ This is exactly what you’ve done if you deploy a new Linux VPS and start using it without a mandatory security hardening process. In Bangladesh’s rapidly digitizing economy, where cyber threats are as common as rickshaw traffic during rush hour, this negligence isn’t just risky—it’s a guarantee of compromise.
Why Your Fresh VPS is a Target from Minute One
You might think, “Who would attack my small project/business?” The truth is, automated bots scan the entire IPv4 address space 24/7. They don’t care if your VPS hosts a personal portfolio, a startup’s MVP, or a small e-commerce store. They are looking for the low-hanging fruit: default passwords, open SSH ports, outdated software. For a Bangladeshi business, a breach can mean more than downtime; it can mean stolen customer data (a massive issue under the new Digital Security Act), a defaced website that destroys trust, or your server being used to launch attacks on others, landing you in legal hot water. The first hour after deployment is your only golden window to build a fortress before the bots come knocking.
The Core Mindset: Assume You Are Already Being Scanned
Your security strategy must start from a position of paranoid vigilance. Do not trust the default configuration. The pristine, out-of-the-box Linux installation is designed for convenience and compatibility, not security. Every single service running by default is a potential vulnerability. Your mission is to reduce the attack surface to the absolute minimum required for your application to function.
The First-Hour Security Protocol: 10 Non-Negotiable Steps
Forget complex, advanced setups for now. Master this foundational checklist. Execute these in order via SSH as the root user or using sudo.
1. Create a Non-Root Sudo User & Lock Down Root SSH
This is your single most important step. The ‘root’ user is the master key to your entire server. Never allow direct root login over SSH.
- Create a new user:
adduser yourname(Choose a name not easily guessable; avoid ‘admin’, ‘test’). - Grant sudo privileges:
usermod -aG sudo yourname(On CentOS/RHEL, usewheelgroup). - Switch to the new user:
su - yourname. All subsequent work should be done from this account. - Disable root SSH login: Edit
/etc/ssh/sshd_configand setPermitRootLogin no.
Analogy: This is like giving your trusted shop manager (sudo user) the keys, but you, the owner (root), keep your master key in a vault and never use the front door. Intruders can’t target the vault directly.
2. Enforce SSH Key-Based Authentication (Kill Password Logins)
Password brute-forcing is the #1 method of VPS compromise. Stop it dead.
- On your local machine (your laptop/desktop), generate a key pair if you don’t have one:
ssh-keygen -t ed25519(orrsa -b 4096). - Copy the public key to your server:
ssh-copy-id yourname@your_server_ip. - Test the login:
ssh yourname@your_server_ip. It should work without a password. - Now, disable password authentication in
/etc/ssh/sshd_config: setPasswordAuthentication noandChallengeResponseAuthentication no. - Reload SSH:
sudo systemctl reload sshd.
CRITICAL: Keep your SSH session open while you test the new key login! Do not close it until you’ve confirmed you can log back in with the key. Locking yourself out is a real risk, especially if you’re connecting from a dynamic IP. If you need an exception, use a temporary password for a specific user just for recovery, but disable it immediately after.
3. Change the Default SSH Port (Security Through Obscurity)
While not a true security control, changing from port 22 stops 99% of automated bots that only scan the default port. It’s a simple, effective first filter.
- In
/etc/ssh/sshd_config, change#Port 22to something likePort 2222(or a random high port, e.g., 45678). - Reload SSH:
sudo systemctl reload sshd. - When connecting, specify the port:
ssh -p 2222 yourname@your_server_ip. - Update your firewall (next step) to allow this new port and remove the old one.
4. Configure a Host-Based Firewall (UFW or firewalld)
Your server should have a “default deny” policy. Only explicitly allow traffic your application needs.
- For Ubuntu/Debian (UFW):
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp(your new SSH port)
sudo ufw allow 80/tcp(HTTP)
sudo ufw allow 443/tcp(HTTPS)
sudo ufw enable - For CentOS/RHEL (firewalld):
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
Think of this firewall as your premium security guard at the main gate of your office building in Banani. He checks every single person trying to enter. If it’s not on the approved list (ports 2222, 80, 443), they get turned away immediately.
5. Install and Configure Fail2Ban
This is your intelligent CCTV system with facial recognition. Fail2Ban scans log files (like SSH auth logs) and bans IPs that show malicious signs—too many failed login attempts.
- Install:
sudo apt install fail2ban(Ubuntu/Debian) orsudo yum install fail2ban(CentOS/RHEL). - Configure: Copy the default config:
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local. - Edit the local file. Find the
[sshd]section and ensure:
enabled = true
port = 2222(your custom port!)
filter = sshd
logpath = /var/log/auth.log(or/var/log/secureon RHEL)
maxretry = 3(ban after 3 failures) - Restart:
sudo systemctl restart fail2ban.
Now, an IP that fails to log in 3 times will be blocked by your firewall for 10 minutes (default).
6. Update the Entire System Immediately
An unpatched system is a broken lock. The moment your VPS is online, apply all security updates.
sudo apt update && sudo apt upgrade -y (Ubuntu/Debian)
sudo yum update -y (CentOS/RHEL)
This fixes known vulnerabilities in the core OS and libraries. Schedule regular, automatic security updates if possible.
7. Set Up a Basic Intrusion Detection System (Lynis)
Lynis is like an automated security auditor. It performs a comprehensive, quick health check and tells you exactly what’s wrong.
sudo apt install lynis (or download from lynis.io)
sudo lynis audit system
Follow its suggestions. It will point out misconfigurations in SSH, password policies, kernel parameters, and more. This is an invaluable learning tool.
8. Harden the Kernel with sysctl
We need to tell the Linux kernel itself to be tougher against network attacks like SYN floods and IP spoofing.
Create a config file: sudo nano /etc/sysctl.d/99-hardening.conf and paste:
net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.ip_forward = 0 net.ipv4.conf.all.log_martians = 1 net.ipv4.tcp_syncookies = 1
Then apply: sudo sysctl --system.
9. Set Up Log Monitoring
You must know what’s happening. At a minimum, set up logwatch or logrotate (usually installed) and ensure logs are rotated and stored. Consider shipping critical logs (auth.log, secure) to a separate, secure log server or a service like Papertrail. Your /var/log/auth.log is the single most important file on your server—it tells you who tried to get in.
10. Install a Web Application Firewall (WAF) for Your Web Stack
If you’re running a website (Apache/Nginx), you need protection at the application layer. ModSecurity with the OWASP Core Rule Set is the open-source standard. It blocks SQL injection, XSS, and other OWASP Top 10 attacks before they hit your PHP/Python/Node.js code. This is non-negotiable for any public-facing web application.
Beyond the First Hour: The Continuous Security Mindset
Security is not a one-time checklist; it’s a process. You must now:
- Automate Updates: Use unattended-upgrades (Ubuntu) or yum-cron (RHEL) for security patches.
- Implement a Backup Strategy: Follow the 3-2-1 rule. 3 copies of data, on 2 different media, 1 offsite. Test your restores!
- Use a Web Hosting Control Panel Wisely: If you use cPanel, ensure it’s updated, use its built-in security features (cPHulk, Host Access Manager), and never use its default ports without a firewall.
- Consider a BDIX-Optimized Host: For Bangladeshi audiences, latency matters. But ensure your host, like HostOrient, provides the foundational security controls—a premium firewall at the network edge, DDoS mitigation, and owned physical infrastructure in Bangladesh with power backup—so your VPS isn’t the first and only line of defense. Their infrastructure acts as your first moat, while you build the walls on your VPS.
Conclusion: Your VPS is Your Digital Asset—Guard It
Deploying a VPS without this hardening sequence is professional negligence. These steps take less than an hour but save you from days, weeks, or months of recovery from a breach. For Bangladeshi developers and businesses, this is the cost of entry into the digital economy. Your data, your customer’s trust, and your business reputation depend on it. Start with this checklist, embed it in your deployment scripts (Ansible, Terraform), and make security your default mode of operation, not an afterthought.
