The “Oops, I Left That Open” Server Moment

A few years back, I spun up a small VPS just to test a side project. Quick install, SSH in, push some code, done. I told myself, “I’ll lock it down later” and went back to parenting duty and video games.

A week later, the log files were full of random SSH login attempts from everywhere on the internet. Luckily nothing got in, but that was a good reminder: if your server is on the public internet, people are knocking on the door all the time.

This guide is for you if you’re running Linux servers (for WordPress, WooCommerce, or any web app) and you want practical, no-drama steps to secure them during provisioning. We’ll focus on: access, firewalls, private networking, service auditing, and staying patched.

---

Step 1: Secure SSH Access with Keys (Not Passwords)

If attackers can’t log in, a lot of your problems disappear. SSH is usually the first thing they hit.

The idea:
– Use SSH keys instead of passwords.
– Disable password login.
– Disable root SSH login.

This reduces brute-force attacks and makes access more traceable per user.

1.1 Generate and use SSH keys

On your local machine (laptop/PC):

1. Generate a key pair (if you don’t already have one).
2. This gives you a private key (keep safe) and a public key (put on the server).
3. Add the public key to your server user’s ~/.ssh/authorized_keys.
4. Test that you can log in with the key.

Why this matters: passwords can be guessed; keys are much harder to brute force.

1.2 Disable SSH password authentication

Once key-based login works reliably, harden SSH by turning off password access.

Steps overview:

1. Edit your SSH daemon config file (often /etc/ssh/sshd_config).
2. Set the options so password login is disabled.
3. Reload or restart the SSH service.

Do this only after you confirm key login works, or you’ll lock yourself out.

1.3 Disable direct root login via SSH

Root logins are a favorite target. Better to log in as a normal user and sudo when needed.

Steps overview:

1. In the same SSH config, disable root login.
2. Ensure your non-root user has the access it needs.
3. Reload/restart SSH.

Why this matters: removing root from SSH makes it harder to get full control in one shot.

---

Step 2: Use a Firewall with Default-Deny Rules

Next, let’s shrink the number of doors into your server.

You want a firewall that:
– Blocks everything by default.
– Only allows what you explicitly need (e.g. SSH, HTTP/HTTPS).

This is called least exposure or default-deny.

2.1 Decide what you actually need open

Before touching firewall rules, make a short list:

• SSH (usually port 22, or your custom SSH port).
• Web traffic: HTTP (80), HTTPS (443).
• Anything else that truly must be reachable from the public internet.

Everything not in that list should not be directly reachable.

2.2 Apply a default-deny firewall policy

At a high level, you want rules like:

1. Deny all incoming traffic by default.
2. Allow established/related connections (for proper replies).
3. Allow only the specific ports you need (e.g., SSH, HTTPS).

Why this matters: even if some service is listening on a port, the firewall can hide it from the internet.

2.3 Be careful not to lock yourself out

Whenever changing firewall rules:

• Keep an existing SSH session open while testing new rules.
• Test a new connection in another terminal.
• Only close the original session once you’re sure SSH still works.

One typo in your firewall can mean a trip into your VPS provider’s console to fix it.

---

Step 3: Use Private Networking for Internal Traffic

If you’re running multiple servers (web, DB, cache, etc.), not everything needs to be on the public internet.

The idea:
– Use private networking (like VPCs) so servers talk over internal IPs.
– Use VPNs for admin access instead of exposing internal services directly.

3.1 Keep internal services off the public internet

Some examples of internal-only services:

• Databases.
• Cache servers.
• Admin panels that don’t need public access.

By placing them on a private network, even if someone scans your public IP, they can’t reach those internal services directly.

3.2 Isolate backend components

You want something like this:

• Public internet → Reverse proxy / web server.
• Web server → talks to database and other internals via private network.

Why this matters: if your public-facing box gets compromised, it’s still harder for an attacker to reach everything else.

---

Step 4: Audit Running Services and Open Ports

Over time, servers drift. You install something “just to test,” forget about it, and six months later it’s still listening on a port.

Regular service auditing helps you spot:
– Ports you didn’t know were open.
– Services you no longer use.
– Things that changed since the last time you looked.

4.1 Regularly inspect listening ports

Make a habit of checking what ports are open and what’s bound to them.

For each listening port, ask:

• Do I actually use this?
• Should this be public or only internal?
• Is there a firewall rule that matches my intention?

If the answer is “I don’t know why that’s there,” that’s a red flag.

4.2 Disable or remove unnecessary services

When you find something unnecessary:

1. Stop the service.
2. Disable it from starting at boot.
3. If you’re sure you never need it, uninstall it.

Why this matters: the fewer services running, the smaller your attack surface. Fewer things to patch, fewer things that can go wrong.

4.3 Watch for configuration drift

Configuration drift is when your server slowly moves away from your original plan:

• Someone opens a port for “temporary” testing.
• A new package installs a service that starts automatically.
• An update changes defaults.

A quick, scheduled check of listening ports and services helps keep things tidy and predictable.

---

Step 5: Keep Systems Patched and Updated

Unpatched software is one of the easiest ways to get hacked. Attackers love known vulnerabilities.

You want automated patching for at least security updates, plus some process for handling reboots safely.

5.1 Automate security updates where possible

Instead of manually logging in and running updates when you remember, set things up so security updates are applied automatically.

Why this matters:
– Shortens the window between vulnerability disclosure and your server being fixed.
– Reduces the “I forgot to update that one old box” problem.

5.2 Plan for reboots and downtime

Updates (especially kernel or core system updates) may require a reboot.

Have a small routine:

• Pick low-traffic windows for reboots.
• Announce brief maintenance for production servers if needed.
• After reboot, check that critical services are back up and responding.

If you’re running multiple servers, rolling restarts help avoid full downtime.

5.3 Don’t ignore application-level updates

OS patches are only half the story.

You still need to keep:
– Application stacks (web servers, interpreters, etc.) updated.
– Your apps themselves updated (including WordPress and plugins).

The source here is about server fundamentals, but in real life, you treat app updates the same way: regular, scheduled, tested.

---

Step 6: Monitor and Detect Suspicious Activity Early

You can’t fix what you never see. Basic monitoring and detection helps you catch issues before they explode.

The goal:
– Notice unusual activity.
– Investigate before it becomes a full-blown breach.

6.1 Keep an eye on authentication attempts

SSH logs can show you:

• Repeated failed login attempts.
• Attempts against users that don’t exist.
• Access from countries/regions you don’t use.

With key-based auth and password login disabled, most of these attempts will fail, but it’s still good to see what’s going on.

6.2 Watch for unexpected new services

Combine your regular service audit with some monitoring:

• If a new service starts listening and you didn’t install it, that’s suspicious.
• If a known service suddenly listens on a different port, investigate.

Why this matters: malware and intruders often spin up their own processes or reuse existing software in odd ways.

6.3 Baseline and alert on changes

A simple but effective idea is:

• Decide what “normal” looks like for your server.
• Set alerts when something important deviates from that baseline.

Even lightweight monitoring is better than nothing. Early warning gives you time to respond calmly instead of in panic mode.

---

Putting It All Together (Without Losing Your Weekend)

If this all feels like a lot, here’s a simple order you can follow when provisioning a new Linux server:

1. Set up SSH keys and verify key-based login works.
2. Disable password and root SSH login once keys are solid.
3. Apply a default-deny firewall, then open only SSH and web ports you need.
4. Use private networking for any internal-only services.
5. Audit services and ports, disable/remove anything unnecessary.
6. Enable automated security updates and have a simple reboot plan.
7. Monitor logs and services so you spot weird behavior early.

You don’t need to be a security expert to do this. It’s mostly about a few habits and some boring but important defaults.

I learned a lot of this the same way I learned to fix old PCs and cars: break things a bit, fix them, take notes, repeat. Hopefully this checklist saves you from some of the more painful “learning moments.”

Need more help? Check the latest CrushEdge posts.