Novi VPS iz panela tipično ima root login, otvorene portove i zastarjele pakete dok ne napravite prvi update. Hardening nije jednokratan security pack nego checklista koju odradite prije produkcijskog prometa i održavate.
Osnovne naredbe za navigaciju i dijagnostiku pokriva Linux osnovne naredbe. Za administrativni pristup bez izlaganja SSH-a cijelom internetu koristan je WireGuard VPN.
1. Korisnik, SSH ključevi, sudo
adduser deploy
usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
# ubacite javni ključ u authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
Provjerite da se možete prijaviti kao deploy u drugom terminalu prije nego što zatvorite root pristup. Sudo: preferirajte deploy ALL=(ALL) NOPASSWD: samo za uske naredbe ako automatizirate; inače tražite lozinku za interaktivni rad.
2. sshd: isključite password auth
sudo nano /etc/ssh/sshd_config.d/99-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
AllowUsers deploy
# opcionalno, ako SSH ide samo s VPN-a:
# ListenAddress 10.8.0.1
sudo sshd -t && sudo systemctl reload ssh
Na Ubuntu 24.04 socket-activated SSH može koristiti ssh.socket. Reload/restart prema tome što systemctl status ssh pokazuje. Test u drugoj sesiji obavezan.
3. Promjena SSH porta (tradeoff)
Pomicanje s 22 na npr. 2222 smanjuje automatski šum u logovima, ali nije prava kontrola pristupa. Napadači skeniraju i nestandardne portove. Bolje kontrole: ključevi only, AllowUsers, firewall allowlist / VPN, eventualno port knocking samo ako znate što radite. Ako mijenjate port, ažurirajte firewall i dokumentaciju prije reload sshd.
4. Firewall: UFW ili nftables
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
# ili: sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
Ako ste na nftables direktno, držite isti model: default deny in, eksplicitni allow. Ne otvarajte Postgres/Redis/MySQL na javni interface. Ako koristite cloud security groups uz host firewall, uskladite pravila. Dvostruki deny je OK; dvostruki conflicting allow zbunjuje.
5. unattended-upgrades
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
Omogućite barem security updatee. Kernel update često traži reboot. Planirajte maintenance window ili NeedRestart monitoring. Automatski update aplikacijskih paketa iz third-party repoa može lomiti stvari; držite se security origin-a dok nemate staging.
6. fail2ban (s oprezom)
fail2ban parsira logove i ban-a IP nakon ponavljanja neuspjeha. Koristan je protiv glupog SSH brute-force šuma. Loše filtrirano pravilo može banati legitimne IP-ove (NAT uredi, CI runneri). Ne zamjenjuje ključeve i firewall. Uz WireGuard-only SSH često vam fail2ban na sshd gotovo ne treba. Pratite fail2ban-client status sshd nakon uvođenja.
7. Non-root servisi
Aplikacije (Gunicorn, Node, Docker rootless gdje ima smisla) ne trebaju trčati kao root. Docker daemon tipično i dalje zahtijeva root na hostu. Smanjite blast radius: deploy user u docker grupi samo ako mora, inače rootless ili strogi sudoers za compose naredbe.
8. Kernel / sysctl osnove
# /etc/sysctl.d/99-hardening.conf
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
sudo sysctl --system
Ne kopirajte "100 hardening sysctl" liste s foruma slijepo. Neke vrijednosti lome VPN, Kubernetes CNI ili nestandardni routing. Mijenjajte u malim koracima i testirajte mrežu.
9. AppArmor vs SELinux: što ne raditi
Ubuntu i Debian tipično koriste AppArmor. RHEL/CentOS/Fedora koriste SELinux. Isključivanje SELinuxa "jer smeta" na sustavu koji ga koristi uklanja važan sloj MAC politike. Ako profil blokira legitimnu akciju: popravite kontekst/profil, ne gasite enforcement globalno bez razloga. Na Ubuntu ne tražite SELinux tutoriale. Radite s AppArmor statusom (aa-status).
10. Ostalo prije produkcije
Timezone / NTP (timedatectl) za točne logove. Swap po potrebi na malom VPS-u; pratite OOM. Automatski security obavijesti (email iz unattended-upgrades). Backup i restore test: hardening bez backupa nije plan oporavka. Minimalni instalirani paketi; maknite nepotrebne network servise.
Česte greške
Zatvoriti SSH prije potvrde ključa u drugoj sesiji. Password auth ostavljen "privremeno". Baza publishana na 0.0.0.0. Slijepo gasenje SELinux/AppArmor. Oslanjanje samo na promjenu SSH porta.
Logovi i audit trail
Hardening bez pregleda logova slijepa je ulica. Minimalno: journalctl -u ssh / auth logovi (tko se pokušava prijaviti), disk prostor za journal (SystemMaxUse u journald.conf) da logovi ne napune root filesystem, i vrijeme sinkronizirano (NTP). Inače koreliranje incidenta s CI/deploy logovima postaje nagađanje.
Ne trebate odmah puni SIEM. Treba vam navika pogledati auth log nakon što otvorite SSH prema internetu i nakon što uvedete fail2ban.
Backup pristupa prije tvrđeg lockdowna
Prije nego zatvorite password auth i root SSH, imajte out-of-band put: cloud provider console / serial console, ili drugi korisnik s ključem. Dokumentirajte recovery korake. Hardening koji vas trajno zaključa s VPS-a nije uspjeh.
Držite kopiju privatnog ključa (ili hardware key enrollment) na sigurnom mjestu. Ne dijelite isti deploy ključ između ljudi i CI-ja bez potrebe. Odvojeni ključevi olakšavaju revoke.
SSH keys: praksa
Koristite Ed25519 ključeve (ssh-keygen -t ed25519 -a 100). Za CI deploy ključ bez passphrase (ili s agentom), za ljudski pristup preferirajte ključ zaštićen passphraseom ili hardware token. Revoke je brži kad svaka osoba/proces ima svoj ključ u authorized_keys.
Zaključak
Prije produkcije: ključevi only, firewall default deny, security updatei i MAC sloj uključen. SSH po mogućnosti preko VPN-a. Za tvrđi baseline na Ubuntu/Debian VPS-u, IT podrška.