Leveling Up: An Advanced Linux Tutorial for Real World Ops

So about four years ago, I spun up a fresh Arch Linux install on a VPS for a personal project — a small web app I was hosting for maybe 12 people. I figured, "it's just a tiny project, nobody's going to bother with it." Within 48 hours, I had over 14,000 failed SSH login attempts in my logs. Fourteen thousand. On a server nobody knew about yet. That was my wake-up call, and honestly, I'm grateful it happened early.

Since then, I've hardened probably 30+ Arch installations across personal machines, workstations, and servers. I've made dumb mistakes, locked myself out more than once, and slowly built up a checklist that actually works without turning the system into an unusable fortress. Here's what I do now on every single Arch install, and why.

Lock Down SSH Before Anything Else

This is step one, always. If your machine faces the internet at all, SSH is the front door and it's getting hammered constantly. Bots don't care that you're running a hobby project.

Open /etc/ssh/sshd_config and make these changes immediately:

• PermitRootLogin no — Never, ever allow root login over SSH. Create a regular user and use sudo.
• PasswordAuthentication no — Switch to key-based authentication. Generate a key pair with ssh-keygen -t ed25519 on your local machine and copy it over with ssh-copy-id.
• Port 2222 (or something non-standard) — This won't stop a determined attacker, but it cuts automated bot traffic by roughly 95% in my experience. My logs went from thousands of attempts per day to maybe 3-5.
• MaxAuthTries 3 — Limit authentication attempts per connection.

After editing, restart the daemon: systemctl restart sshd. But here's my first lesson learned — don't close your current SSH session until you've confirmed you can connect in a new terminal window. I locked myself out of a remote server in 2021 because I fat-fingered the port number and closed my session. Had to contact the hosting provider to get console access. Embarrassing.

Set Up a Firewall With nftables

Arch doesn't come with firewall rules configured by default. Nothing. Wide open. A lot of people reach for ufw because they're used to it from Ubuntu, and that's fine — it's in the AUR. But I've switched to using nftables directly since it's been the default Linux firewall backend since kernel 3.13 and it's already installed on Arch.

Here's a minimal /etc/nftables.conf that I start with:

table inet filter {
chain input {
type filter hook input priority 0; policy drop;
iif lo accept
ct state established,related accept
tcp dport 2222 accept # your SSH port
# add other ports as needed
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}

Enable it with systemctl enable --now nftables. The policy is drop-by-default for incoming traffic, which means if you forget to open a port for a new service, it just won't work — annoying, but far safer than the alternative. I keep a sticky note on my monitor that says "did you open the port?" because I've wasted 45 minutes debugging a "broken" application that was just firewalled off. Twice.

Harden the Kernel With sysctl

There are a handful of kernel parameters that improve security significantly, and most Arch installs leave them at their defaults. Create a file at /etc/sysctl.d/99-security.conf with these settings:

• net.ipv4.tcp_syncookies = 1 — Protects against SYN flood attacks.
• net.ipv4.conf.all.rp_filter = 1 — Enables reverse path filtering to prevent IP spoofing.
• net.ipv4.conf.all.accept_redirects = 0 — Ignores ICMP redirects. You almost never need these.
• net.ipv4.conf.all.send_redirects = 0 — Same idea, outbound side.
• kernel.kptr_restrict = 2 — Hides kernel pointer addresses from all users, even root.
• kernel.dmesg_restrict = 1 — Restricts dmesg access to root. Kernel logs can leak hardware and configuration info.
• kernel.unprivileged_bpf_disabled = 1 — Limits BPF usage, which has been the source of multiple privilege escalation CVEs over the past few years.

Apply them without rebooting: sysctl --system. These won't break normal desktop or server usage, and I've been running all of them on every machine since around 2020 with zero issues.

Fail2ban: Your Automated Bouncer

Even with key-only SSH, I still run Fail2ban (currently on version 1.1.0 in the Arch repos as of early 2025). It monitors log files and temporarily bans IPs that show malicious behavior — too many failed logins, suspicious HTTP requests, whatever you configure.

Install it with pacman -S fail2ban, then create a local jail config at /etc/fail2ban/jail.local:

[sshd]
enabled = true
port = 2222
maxretry = 3
bantime = 3600
findtime = 600

This bans any IP that fails 3 login attempts within 10 minutes, for 1 hour. On my public-facing servers, I set bantime = 86400 (24 hours) because I'm not interested in giving repeat offenders another shot. Enable it: systemctl enable --now fail2ban.

You can check banned IPs anytime with fail2ban-client status sshd. I check mine weekly and it's consistently catching 20-40 unique IPs. These are almost always automated scanners from a handful of well-known IP ranges.

Keep Packages Updated (But Don't Be Reckless)

Arch is rolling release, which means security patches land fast — often within hours of upstream disclosure. That's great. But it also means a pacman -Syu can occasionally break things if you're not paying attention. I've had a kernel update brick a machine's boot process because I wasn't watching the pacman output and missed a warning about a required mkinitcpio rebuild.

My approach now:

• Run pacman -Syu at least twice a week. Don't let updates pile up for months — partial upgrades on Arch are much riskier than frequent small ones.
• Always read the output. Pacman prints warnings for a reason.
• Subscribe to the Arch Linux News feed. They post manual intervention notices there. I check it before every update.
• If you're running AUR packages, use an AUR helper like paru (version 2.0.4 as of writing) and read the PKGBUILDs before building. I know nobody does this, but you really should — AUR packages are user-submitted and unvetted.

Second lesson learned: back in 2022, I blindly installed an AUR package that had a post_install script running curl | bash from a sketchy URL. I caught it only because I happened to glance at the terminal output. Nothing bad happened, but it could have been a disaster. Now I cat every PKGBUILD before I confirm.

Disk Encryption and User Permissions

If this is a laptop or any machine that could be physically accessed by someone else, full disk encryption with LUKS isn't optional — it's mandatory. Arch's installation guide covers cryptsetup setup, and if you're using systemd-boot, the integration is straightforward. Use LUKS2 with argon2id as the key derivation function (this became the default in cryptsetup 2.4.0).

Beyond encryption, tighten up user permissions:

• Don't use your daily account in the wheel group on a shared machine. Create a separate admin user for sudo tasks.
• Set umask 077 in /etc/profile so new files are private by default.
• Audit your sudoers file. Use visudo and be specific about what commands users can run. A blanket ALL=(ALL:ALL) ALL is convenient but sloppy.
• Consider installing apparmor — it's available in the official repos now and works with kernel 6.x without patching. It adds mandatory access control profiles for individual applications. I run it on all my machines with profiles for Firefox, Chromium, and any network-facing services.

Bonus: Audit What You've Done

After all this setup, run lynis audit system (install lynis from the official repos, currently version 3.1.2). It scans your system and gives you a hardening score out of 100 along with specific suggestions. My fresh Arch installs typically score around 55-60 before hardening. After applying everything above, I usually land between 78-85. Getting above 90 requires some aggressive restrictions that tend to interfere with desktop usability, so I don't bother on workstations.

Do I really need to secure Arch Linux if it's just a desktop?

Yes. Your desktop connects to the internet, runs a browser, opens email attachments, and probably has SSH enabled. A compromised desktop gives an attacker access to your passwords, keys, documents, and potentially your network. The threat model is different from a server, but it's not zero. I apply everything above except Fail2ban on my daily driver.

Is Arch Linux less secure than Ubuntu or Fedora?

Not inherently. Arch gives you less out-of-the-box security configuration, which means you have to do more yourself. Ubuntu ships with AppArmor profiles and a firewall tool pre-installed. Fedora has SELinux enabled by default. Arch gives you a blank slate. That's a disadvantage if you're lazy, but an advantage if you want to understand exactly what's running on your system. I actually trust my Arch setups more because I configured every piece myself.

How often should I check my system for security issues?

I run lynis once a month, check Fail2ban logs weekly, and review journalctl -p 3 -b (priority error and above for current boot) daily — or at least every couple of days. For servers, I have a cron job that emails me a summary of failed login attempts every Monday morning. It takes maybe 5 minutes per week total once you've set it up.

What about antivirus software on Arch?

ClamAV exists for Linux and it's in the repos, but honestly, traditional antivirus isn't the primary defense model on Linux. Your main protections are: keeping packages updated, running a firewall, not executing untrusted code, and using proper file permissions. I run ClamAV on my mail server to scan attachments for the benefit of Windows users I email, but I don't run it on my desktops. If you're worried about rootkits specifically, rkhunter and chkrootkit are both available and worth running periodically.

Look, Arch Linux security isn't magic, and it isn't something you configure once and forget about. It's a habit. The steps I've listed here take maybe 30-45 minutes on a fresh install, and they block the vast majority of common attack vectors. You're not going to stop a nation-state actor with nftables and Fail2ban, but you're also probably not their target. What you are trying to stop is the constant background noise of automated bots, opportunistic scanners, and the occasional script kiddie. And for that, this setup works. I've been running it for years, and the only security incident I've had was the one I caused myself by not reading a PKGBUILD. Don't be like 2022 me — read the PKGBUILD.

Related Posts