A szerver már működik, mindhárom eszközödről belépsz kulccsal. Most bezárjuk az összes felesleges ajtót: root-tiltás, tűzfal, fail2ban, automata frissítések, mentés. Ugyanaz az álszerver: tzlab-szerver · 203.0.113.45 — minden adat kitalált.
sudo sshd -t.Az ajánlott sorrend — a doksi is ebben halad:
| # | Lépés | Miért ez a helye |
|---|---|---|
| 0 | Mentőövek ellenőrzése | Minden további lépés erre támaszkodik |
| 1 | Root SSH-tiltás | Előfeltétele a működő sudo-user |
| 2 | Csak-kulcs belépés | Előfeltétele a tesztelt kulcs minden eszközön |
| 3 | ufw tűzfal | SSH-szabály ELŐBB, csak utána bekapcsolás! |
| 4 | fail2ban | A tűzfalra épül, azt használja tiltásra |
| 5 | Automata frissítések | Független, bármikor mehet |
| 6 | Snapshot | A kész, keményített állapotot mented el |
Miért: a robotok 99%-a a root nevet próbálgatja, mert az minden Linuxon létezik. Ha a root egyáltalán nem léphet be SSH-n, a támadónak már a felhasználónevet is találgatnia kell, nem csak a titkot. Te a zoltan userrel dolgozol, és ha root kell, sudo-zol.
Előfeltétel-ellenőrzés (tényleg megy a sudo-user?):
zoltan@tzlab-szerver:~$ sudo whoami
root # ha ezt látod, a zoltan user teljes értékű admin — jöhet a tiltásBeállítás — saját drop-in fájlba tesszük, ami a cloud-init fájl UTÁN töltődik be (a fájlok név szerinti sorrendben olvasódnak, és azonos direktívánál az első nyer — ezért ellenőrizd, hogy a cloud-init drop-in nem mondja-e felül; ha igen, abban állítsd):
zoltan@tzlab-szerver:~$ sudo nano /etc/ssh/sshd_config.d/60-hardening.confPermitRootLogin no # root SSH-n egyáltalán nem léphet bezoltan@tzlab-szerver:~$ sudo sshd -t && sudo systemctl restart ssh
# új ablakból teszt: zoltan mehet, root már nemPermitRootLogin prohibit-password = root csak kulccsal (jelszóval nem) — ez a DO-image-ek gyakori alapértelmezése. A no a szigorúbb és az ajánlott végállapot. A DO webes/recovery konzolt a tiltás NEM érinti — az nem SSH.Ezt a Gyakorlat 6. pontjában már felépítetted — itt csak véglegesítjük és ellenőrizzük. A cél-állapot a drop-inban:
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no # a jelszókérés „interaktív" kiskapuja is zárvaEllenőrzés, hogy a ténylegesen ÉRVÉNYES beállítás mi (drop-inok összefésülve):
zoltan@tzlab-szerver:~$ sudo sshd -T | grep -Ei 'passwordauth|permitroot|pubkey'
permitrootlogin no
pubkeyauthentication yes
passwordauthentication nosshd -T a barátodNem azt mutatja, mit írtál a fájlokba, hanem amit az sshd ténylegesen alkalmaz az összes config összefésülése után. Drop-in-zavarnál ez a leggyorsabb diagnózis.Az ufw (Uncomplicated Firewall) elve: alapból minden bejövő tilos, és csak azt engeded, amire tényleg szükség van. Egy webszervernél ez tipikusan három dolog: SSH (22), HTTP (80), HTTPS (443).
ufw enable az SSH-szabály ELŐTTHa úgy kapcsolod be a tűzfalat, hogy az SSH-t még nem engedted, a következő pillanatban minden élő és jövőbeli SSH-kapcsolat elhal — magadat zártad ki. A sorrend szent: először allow SSH, utána enable. (Ha mégis megtörténne: DO recovery konzol + root jelszó, és onnan ufw disable.)# 1) alapszabályok: bejövő tilos, kimenő szabad
zoltan@tzlab-szerver:~$ sudo ufw default deny incoming
zoltan@tzlab-szerver:~$ sudo ufw default allow outgoing
# 2) ELŐSZÖR az SSH — e nélkül ne menj tovább!
zoltan@tzlab-szerver:~$ sudo ufw allow OpenSSH # = 22/tcp
# 3) web, ha van rajta weboldal (Caddy):
zoltan@tzlab-szerver:~$ sudo ufw allow 80/tcp
zoltan@tzlab-szerver:~$ sudo ufw allow 443/tcp
# 4) és csak MOST a bekapcsolás:
zoltan@tzlab-szerver:~$ sudo ufw enable
Firewall is active and enabled on system startup
# 5) ellenőrzés:
zoltan@tzlab-szerver:~$ sudo ufw status verbose
To Action From
-- ------ ----
OpenSSH ALLOW IN Anywhere
80/tcp ALLOW IN Anywhere
443/tcp ALLOW IN AnywhereHa egy szolgáltatást (pl. PostgreSQL, 5432) csak a szerveren belülről használsz, azt ne engedd kifelé — a „nem nyitott port" a legjobb tűzfalszabály.
Mit csinál: figyeli a naplókat (pl. az SSH sikertelen belépéseit), és aki rövid időn belül sokszor hibázik, annak az IP-jét automatikusan kitiltja a tűzfalon, adott időre. A jelszó-próbálgató robotok ellen ez a második védvonal (az első a csak-kulcs belépés — kulcsnál eleve esélyük sincs, de a zaj így is csökken).
zoltan@tzlab-szerver:~$ sudo apt update && sudo apt install fail2ban
# a beállítást SOSE a jail.conf-ban módosítsd (frissítéskor felülíródik),
# hanem saját jail.local fájlban:
zoltan@tzlab-szerver:~$ sudo nano /etc/fail2ban/jail.local[sshd]
enabled = true
maxretry = 5 # ennyi hiba után tilt
findtime = 10m # ennyi időn belül számolja a hibákat
bantime = 1h # ennyi időre tilt (lehet 1d, 1w is)zoltan@tzlab-szerver:~$ sudo systemctl restart fail2ban
# státusz — hány IP van épp kitiltva:
zoltan@tzlab-szerver:~$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Currently failed: 2
`- Currently banned: 14
# ha véletlenül SAJÁT magad tiltottad ki (pl. elgépelt passphrase sokszor):
zoltan@tzlab-szerver:~$ sudo fail2ban-client set sshd unbanip 198.51.100.7unbanip, vagy DO konzol. Megelőzés: a saját fix IP-d felveheted az ignoreip listára a jail.local-ban.A legtöbb betörés nem zseniális hack, hanem ismert, javított hiba kihasználása olyan gépen, ahol nem telepítették a javítást. Az unattended-upgrades a biztonsági frissítéseket magától felteszi:
zoltan@tzlab-szerver:~$ sudo apt install unattended-upgrades
zoltan@tzlab-szerver:~$ sudo dpkg-reconfigure -plow unattended-upgrades
# a megjelenő kérdésre: Yes
# ellenőrzés, hogy fut-e:
zoltan@tzlab-szerver:~$ systemctl status unattended-upgrades/var/run/reboot-required fájl jelzi.Népszerű tanács a 22-es port lecserélése (pl. 2222-re). Őszintén a mérleg:
A mi értékelésünk: csak-kulcs belépés + fail2ban mellett a portcsere opcionális kényelmi lépés, nem biztonsági alap. Ha mégis:
# 1) ELŐBB a tűzfalon engedd az új portot (különben kizárod magad!):
zoltan@tzlab-szerver:~$ sudo ufw allow 2222/tcp
# 2) a drop-inba: Port 2222 → sshd -t → restart
# 3) teszt ÚJ ablakból:
zoltan@notebook:~$ ssh -p 2222 zoltan@203.0.113.45
# 4) ha megy, a 22-es szabályt törölheted: sudo ufw delete allow OpenSSHKét külön dolog, ne keverd:
A DO panelen: Droplet → Snapshots → Take snapshot. A teljes lemez állapotát menti — ebből egy kattintással új, ugyanilyen szervert tudsz indítani. Konzisztensebb, ha a mentés idejére leállítod a gépet (sudo poweroff, snapshot, majd panelről Power On), de élő gépről is működik. Mikor: a most elkészült, keményített alapállapotról egyet mindenképp; utána nagyobb változtatások előtt.
A snapshot a DO-fiókodon belül él — ha a fiókod sérül, az is. A pótolhatatlan adatnak (adatbázis-dump, feltöltött fájlok) legyen fiókon kívüli másolata is, például naponta:
# PostgreSQL-dump (a TZlab-stackben ez az érték):
zoltan@tzlab-szerver:~$ pg_dump -U projekt_user projekt_db | gzip > /home/zoltan/backup/projekt_$(date +%F).sql.gz
# és ezt letöltöd/elszinkronizálod egy másik helyre (scp, rclone, object storage)# sikertelen belépési kísérletek (látni fogod, mennyi robot dörömböl):
zoltan@tzlab-szerver:~$ sudo lastb | head -20
# sikeres belépések — a TE eszközeid, időpontokkal:
zoltan@tzlab-szerver:~$ last | head -10
# az SSH-szolgáltatás naplója élőben:
zoltan@tzlab-szerver:~$ sudo journalctl -u ssh -f
# fail2ban éppen kiket tilt:
zoltan@tzlab-szerver:~$ sudo fail2ban-client status sshdHavonta egy pillantás elég: a lastb tele lesz robotokkal (ez normális, ezért a fail2ban), a last-ban viszont csak a saját belépéseidet szabad látnod. Ismeretlen sikeres belépés = azonnali kulcs-audit.
PermitRootLogin no — root SSH-n nem léphet be.PasswordAuthentication no + KbdInteractiveAuthentication no — csak kulcs.sudo sshd -T-vel ellenőrizve a TÉNYLEGES beállítás.jail.local-ban sshd engedélyezve, unban-parancsot ismered.last / lastb / fail2ban-státusz.Ha ez megvan: → Teszt 3 — Keményítés, majd → Edzőpálya 3, ahol be is gépeled az egészet.