Абарона Linux VPS: чэк-ліст SSH, файрвола, абнаўленняў і маніторынгу

У першую гадзіну на новым VPS з Ubuntu ці Debian трэба закрыць тое, што аўтаматычныя сканеры правяраюць праз некалькі хвілін пасля з'яўлення IP-адраса ў сетцы. Абнавіце сістэму, уваходзьце як звычайны карыстальнік з sudo і ключом Ed25519, адключыце ўваход па паролі і пад root праз drop-in-файл SSH, уключыце файрвол з забаронай па змаўчанні, які адкрывае толькі SSH і вэб-парты, у ідэале толькі для вашага CDN. Потым уключыце аўтаматычныя абнаўленні бяспекі з планавымі перазагрузкамі, дадайце fail2ban або CrowdSec, змясціце праграму ў пясочніцу systemd і наладзьце рэзервовыя копіі і алерты да таго, як DNS пачне паказваць на сервер.

Каманды ніжэй арыентаваныя на Ubuntu 24.04 LTS, а адрозненні Debian 12 і 13 пазначаны асобна. Пакуль працуеце, трымайце адкрытай вэб-кансоль правайдара. Гэта ваш шлях назад на сервер, калі змена SSH або файрвола адрэжа доступ.

Абнавіце сістэму і стварыце карыстальніка з sudo

Многія правайдары выдаюць уваход пад root з паролем, таму найперш замяніце і тое, і другое. Усталюйце наяўныя абнаўленні, потым стварыце асабісты ўліковы запіс з правамі sudo:

apt update && apt full-upgrade -y
adduser deploy
usermod -aG sudo deploy

У воблачных вобразах Ubuntu ўжо ёсць уліковы запіс ubuntu з правамі sudo. У мінімальнай усталёўцы Debian з паролем root пакета sudo можа не быць, таму спачатку выканайце apt install sudo. Кожнаму чалавеку заводзьце іменны ўліковы запіс, каб журнал аўдыту паказваў на канкрэтнага чалавека. UTC спрашчае супастаўленне логаў паміж серверамі і панэлямі CDN: timedatectl set-timezone Etc/UTC.

Чым Debian адрозніваецца ад Ubuntu 24.04

Галіна	Ubuntu 24.04 LTS	Debian 12 і 13
Слухач SSH	ssh.socket запускае дэман па запыце	звычайна ssh.service; праверце праз systemctl status
Файрвол	ufw усталяваны, але неактыўны	нічога не ўключана; стандартны фрэймворк nftables
Аўтаабнаўленні	unattended-upgrades усталяваны і ўключаны	можа адсутнічаць; усталюйце і ўключыце
Журнал аўтэнтыфікацыі	/var/log/auth.log і журнал systemd	толькі журнал; rsyslog не ставіцца па змаўчанні з Debian 12
sudo	усталяваны	можа адсутнічаць у мінімальнай усталёўцы
OpenSSH	9.6	9.2 у Debian 12, 10.0 у Debian 13

SSH з ключамі Ed25519 і drop-in-файлам hardening

Стварыце і ўсталюйце ключ

Генерыруйце ключ на сваёй працоўнай машыне, ніколі не на серверы. Ключы Ed25519 кароткія, хуткія і падтрымліваюцца любой актуальнай версіяй OpenSSH. Абараніце закрыты ключ парольнай фразай і трымайце яго ў ssh-agent. Калі ў вас ёсць апаратны ключ FIDO2, ssh-keygen -t ed25519-sk прывяжа ключ да прылады.

ssh-keygen -t ed25519 -C "deploy@laptop-2026"
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

ssh-copy-id патрабуе аднаго ўваходу па паролі. Калі root ужо прымае ваш ключ, а паролі адключаны, скапіруйце файл ключа на самім серверы:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys

Правы доступу маюць значэнне: пры ўключаным па змаўчанні StrictModes дэман sshd ігнаруе файлы ключоў, у якія могуць пісаць іншыя карыстальнікі.

Напішыце drop-in-файл

Файл /etc/ssh/sshd_config у Ubuntu пачынаецца з радка Include /etc/ssh/sshd_config.d/*.conf, а даведка sshd_config кажа, што для кожнага ключавога слова выкарыстоўваецца першае атрыманае значэнне. Drop-in-файлы чытаюцца ў лексічным парадку і пераважаюць астатнюю частку асноўнага файла. Воблачныя вобразы часта маюць уласны файл накшталт 50-cloud-init.conf або 60-cloudimg-settings.conf, які задае PasswordAuthentication, таму дайце свайму файлу малы прэфікс:

# /etc/ssh/sshd_config.d/00-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
AllowUsers deploy
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no

KbdInteractiveAuthentication no закрывае шлях keyboard-interactive праз PAM, які можа запытаць пароль нават пры выключаным PasswordAuthentication. AllowUsers абмяжоўвае ўваход іменнымі ўліковымі запісамі. Асноўны файл Ubuntu задае X11Forwarding yes, і drop-in перамагае, бо чытаецца першым. Калі перанакіраванне нікому не патрэбна, дадайце AllowAgentForwarding no і AllowTcpForwarding no.

Праверце сінтаксіс, выведзіце дзейныя значэнні і прымяніце налады:

sudo sshd -t
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|kbdinteractive|authenticationmethods|allowusers'
sudo systemctl restart ssh

sshd -t выяўляе сінтаксічныя памылкі, а sshd -T паказвае канфігурацыю, якая сапраўды прымяняецца, у тым ліку ці не перамог файл cloud-init. Перазапуск ssh захоўвае ўсталяваныя сесіі. У Ubuntu 24.04 сокет, які слухае злучэнні, належыць ssh.socket, таму змена Port або ListenAddress патрабуе яшчэ sudo systemctl daemon-reload і sudo systemctl restart ssh.socket, прычым пасля таго, як файрвол дазволіць новы порт. Астатнія параметры апісаны ў кіраўніцтве Ubuntu па OpenSSH server.

Праверце ў другой сесіі, перш чым закрыць першую

Не закрывайце бягучую сесію. З новага тэрмінала ўвайдзіце як deploy па ключы і выканайце sudo -v. Потым пераканайцеся, што закрытыя шляхі больш не працуюць:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected]
ssh [email protected]

Абедзве спробы павінны скончыцца паведамленнем Permission denied (publickey). Толькі пасля гэтага закрывайце зыходную сесію. Перанос SSH на іншы порт памяншае шум у логах, але мерай абароны не з'яўляецца.

Файрвол з забаронай па змаўчанні: ufw або nftables

Файрвол на хосце з'яўляецца другім слоем пасля сеткавага файрвола правайдара, калі той яго прапануе. Адкідайце ўвесь уваходны трафік, акрамя SSH і вэб-партоў, дазваляйце выходны і абараняйце IPv6 гэтак жа, як IPv4.

Ubuntu: ufw

Дадайце правіла для SSH да ўключэння файрвола, інакш ufw enable абарве вашу сесію:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit OpenSSH
sudo ufw allow proto tcp from any to any port 80,443 comment 'web'
sudo ufw enable
sudo ufw status verbose

Паводле даведкі ufw, правіла limit блакуе адрас, які адкрывае 6 або больш злучэнняў за 30 секунд. Гэта тармозіць сканеры, але можа замінаць аўтаматызацыі, што адкрывае шмат паралельных SSH-злучэнняў; там лепш падыходзіць звычайны allow. Калі ў вас сталы адрас адміністратара або VPN, дазвольце SSH толькі з яго: sudo ufw allow from 198.51.100.7 to any port 22 proto tcp. Правілы дзейнічаюць і для IPv6, пакуль у /etc/default/ufw стаіць IPV6=yes, як па змаўчанні.

Дакументацыя Docker папярэджвае, што парты, апублікаваныя Docker, абыходзяць правілы ufw і firewalld. Публікуйце кантэйнеры на loopback, напрыклад -p 127.0.0.1:3000:3000, а вонкі выстаўляйце reverse proxy.

Debian: nftables

У Debian стандартным фрэймворкам файрвола з'яўляецца nftables. Гэты /etc/nftables.conf рэалізуе тую ж палітыку і загадзя стварае іменныя наборы для дыяпазонаў CDN з наступнага раздзела:

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  set cloudflare_v4 {
    type ipv4_addr
    flags interval
  }

  set cloudflare_v6 {
    type ipv6_addr
    flags interval
  }

  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    ct state invalid drop
    iif "lo" accept
    meta l4proto { icmp, ipv6-icmp } accept
    tcp dport 22 accept
    ip saddr @cloudflare_v4 tcp dport { 80, 443 } accept
    ip6 saddr @cloudflare_v6 tcp dport { 80, 443 } accept
  }

  chain forward {
    type filter hook forward priority filter; policy drop;
  }
}

Праверце файл камандай sudo nft -c -f /etc/nftables.conf, потым выканайце sudo systemctl enable --now nftables. ICMPv6 пакідайце адкрытым: ад яго залежаць выяўленне суседзяў і вызначэнне MTU шляху ў IPv6. flush ruleset выдаляе і табліцы, створаныя fail2ban або Docker, таму пасля перазагрузкі правіл перазапускайце гэтыя службы. Выкарыстоўвайце на хосце адзін інструмент кіравання файрволам.

Пускайце да вэб-партоў толькі CDN

Калі сайт працуе за Cloudflare ці іншым CDN, origin не павінен адказваць нікому іншаму на партах 80 і 443. Інакш кожны, хто знойдзе адрас origin праз старыя DNS-запісы, паштовы сервер на тым жа IP або сканаванне інтэрнэту, абыдзе WAF, ліміты запытаў і кэш CDN. Cloudflare публікуе свае дыяпазоны па адрасах https://www.cloudflare.com/ips-v4 і https://www.cloudflare.com/ips-v6, а ў дакументацыі пра IP-адрасы сказана, што новыя дыяпазоны трапляюць у спіс яшчэ да ўводу ў эксплуатацыю.

У ufw дадайце па правіле на кожны дыяпазон. У файлах няма завяршальнага сімвала новага радка, таму цыкл павінен яўна апрацаваць апошні радок, інакш ён моўчкі прапусціць адзін дыяпазон:

#!/usr/bin/env bash
set -euo pipefail
for list in ips-v4 ips-v6; do
  curl -fsS "https://www.cloudflare.com/$list" |
    while read -r cidr || [ -n "$cidr" ]; do
      ufw allow proto tcp from "$cidr" to any port 80,443 comment 'cloudflare'
    done
done

Потым выдаліце адкрытае правіла камандай sudo ufw delete allow proto tcp from any to any port 80,443. У nftables абнаўляйце абодва наборы адной транзакцыяй, бо nft -f прымяняе пакет цалкам або не прымяняе нічога. Калі загрузка не ўдалася, set -e спыніць скрыпт, а старыя наборы застануцца на месцы:

#!/usr/bin/env bash
set -euo pipefail
v4=$(curl -fsS https://www.cloudflare.com/ips-v4 | paste -sd, -)
v6=$(curl -fsS https://www.cloudflare.com/ips-v6 | paste -sd, -)
nft -f - <<EOF
flush set inet filter cloudflare_v4
flush set inet filter cloudflare_v6
add element inet filter cloudflare_v4 { $v4 }
add element inet filter cloudflare_v6 { $v6 }
EOF

Запускайце яго пры загрузцы пасля nftables.service і штотыдзень па таймеры systemd. Пасля гэтага Nginx патрэбныя set_real_ip_from для тых жа дыяпазонаў і real_ip_header CF-Connecting-IP;, інакш логі і ліміты будуць бачыць адрасы Cloudflare замест наведвальнікаў. Серверны бок разбірае кіраўніцтва па кэшаванні ў Nginx і Cloudflare.

Спіс дазволеных IP даказвае, што злучэнне прыйшло з сеткі Cloudflare, але не тое, што яно адносіцца да вашай зоны. Кіраўніцтва Cloudflare па абароне origin называе такі спіс уразлівым да падмены IP і апісвае мацнейшыя варыянты: Authenticated Origin Pulls, якім патрэбны рэжым шыфравання Full або Full (strict), і Cloudflare Tunnel, якому ўваходныя вэб-парты ўвогуле не патрэбныя.

Аўтаматычныя абнаўленні і перазагрузкі ядра

Ubuntu Server па змаўчанні ўсталёўвае unattended-upgrades і ўключае абнаўленні бяспекі, як апісана ў кіраўніцтве па аўтаматычных абнаўленнях. Праверце гэта:

cat /etc/apt/apt.conf.d/20auto-upgrades
sudo unattended-upgrade --dry-run -v

Файл павінен змяшчаць APT::Periodic::Update-Package-Lists "1"; і APT::Periodic::Unattended-Upgrade "1";. У Debian выканайце sudo apt install unattended-upgrades і sudo dpkg-reconfigure -plow unattended-upgrades.

Выпраўленні ядра пачынаюць дзейнічаць толькі пасля перазагрузкі. У Ubuntu 24.04 needrestart перазапускае службы, якія выкарыстоўваюць абноўленыя бібліятэкі, але замяніць працоўнае ядро ён не можа. Калі пакету патрэбна перазагрузка, з'яўляецца /var/run/reboot-required. Захоўвайце лакальныя налады ў файле, які сартуецца пасля пакетнага 50unattended-upgrades:

// /etc/apt/apt.conf.d/52unattended-upgrades-local
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";

Выберыце час з нізкім трафікам і пераканайцеся, што праграма падымаецца пасля загрузкі без ручных дзеянняў. Логі ляжаць у /var/log/unattended-upgrades/. Canonical Livepatch, бясплатны для асабістага выкарыстання на пяці машынах, закрывае крытычныя і высокія ўразлівасці ядра проста ў памяці, але Canonical прама піша, што перазагрузку ён не замяняе.

fail2ban ці CrowdSec

Калі ўваход па паролі адключаны, перабор пароляў SSH не можа быць паспяховым. Інструмент блакіровак з'яўляецца другім слоем: ён памяншае шум у логах, эканоміць CPU на ўсталяванні злучэнняў і тармозіць сканеры. Выберыце адзін.

fail2ban ёсць у рэпазіторыях абодвух дыстрыбутываў і не патрабуе ўліковага запісу. У Ubuntu 24.04 пакет уключае jail sshd з бэкендам журнала systemd і дзеяннямі nftables, і такі бэкенд падыходзіць і для Debian, дзе няма auth.log. Усталюйце яго камандай sudo apt install fail2ban, потым наладзьце jail у лакальным файле, а не ў jail.conf:

# /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
bantime.increment = true

Прымяніце файл праз sudo systemctl restart fail2ban і паглядзіце стан jail камандай sudo fail2ban-client status sshd.

CrowdSec разбірае тыя ж логі, абменьваецца сігналамі з агульным спісам блакіровак супольнасці і прымяняе рашэнні праз асобны кампанент блакіроўкі. Ubuntu 24.04 пастаўляе версію 1.4.6, а кіраўніцтва па ўсталёўцы CrowdSec патрабуе навейшую версію з рэпазіторыя распрацоўшчыка. Прачытайце скрыпт усталёўкі, перш чым запускаць яго:

curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec crowdsec-firewall-bouncer-nftables
sudo cscli collections list
sudo cscli decisions list

За CDN вэб-запыты прыходзяць з адрасоў CDN. Блакіроўка HTTP-зламысніка ў файрволе хоста або адрэжа вузел Cloudflare, або закране адрас, які ніколі не падключаецца напрамую. Пакіньце блакіроўкі на хосце для SSH, а для HTTP выкарыстоўвайце правілы WAF і абмежаванні запытаў у CDN.

Пясочніца systemd для праграмы

Запускайце бэкенд ад асобнага сістэмнага карыстальніка ў unit-файле systemd, а не ў shell ці праз nohup, і няхай systemd забярэ ў працэсу ўсё, што яму не патрэбна. Стварыце карыстальніка камандай sudo useradd --system --no-create-home --shell /usr/sbin/nologin webapp. Гэты unit запускае сэрвіс на Node.js на localhost за Nginx:

# /etc/systemd/system/webapp.service
[Unit]
Description=Example web application
After=network-online.target
Wants=network-online.target

[Service]
User=webapp
Group=webapp
WorkingDirectory=/opt/webapp
ExecStart=/usr/bin/node /opt/webapp/server.js
Environment=HOST=127.0.0.1 PORT=3000
LoadCredential=db_password:/etc/webapp/db_password
Restart=on-failure
StateDirectory=webapp
UMask=0077

NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectKernelLogs=yes
ProtectControlGroups=yes
ProtectClock=yes
ProtectHostname=yes
ProtectProc=invisible
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
LockPersonality=yes
CapabilityBoundingSet=
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

[Install]
WantedBy=multi-user.target

NoNewPrivileges=yes не дае працэсу і яго нашчадкам атрымаць прывілеі праз setuid-файлы або файлавыя capabilities. ProtectSystem=strict мантуе файлавую сістэму для сэрвісу толькі для чытання, акрамя /dev, /proc і /sys, таму адзінае месца для запісу — /var/lib/webapp з StateDirectory=. Для астатняга дадайце ReadWritePaths=. ProtectHome=yes хавае /home, /root і /run/user, а PrivateTmp=yes дае сэрвісу ўласныя /tmp і /var/tmp. Пусты CapabilityBoundingSet= прыбірае ўсе capabilities, а @system-service з'яўляецца спісам дазволеных выклікаў, які даведка systemd.exec раіць як адпраўную кропку.

MemoryDenyWriteExecute=yes прапушчаны наўмысна: у даведцы сказана, што ён несумяшчальны з JIT-рухавікамі, а V8 у Node.js генерыруе код падчас выканання. Для сэрвісаў на Go, Rust або C дадайце яго і пратэстуйце.

У Ubuntu 24.04 з systemd 255 каманда systemd-analyze security --offline=true ацаніла гэты файл у 1.5 супраць 9.0 для такога ж unit толькі з User=. Запусціце сэрвіс і праверце:

sudo systemctl daemon-reload
sudo systemctl enable --now webapp
systemd-analyze security webapp.service
journalctl -u webapp -b -n 50 --no-pager

Калі сэрвіс не стартуе, журнал звычайна называе заблакаваны шлях або сістэмны выклік. Паслабляйце па адным параметры, а не выдаляйце ўвесь блок. Пакетныя службы накшталт Nginx запускаюцца ад root і патрабуюць пэўных capabilities, таму ўмацоўвайце іх праз sudo systemctl edit nginx, таксама па адным параметры.

Сінхранізацыя часу, journald і захоўванне логаў

Праверка TLS, коды TOTP, расклады рэзервовага капіявання і супастаўленне логаў патрабуюць дакладнага гадзінніка. Ubuntu 24.04 і Debian 12 па змаўчанні выкарыстоўваюць systemd-timesyncd. Выканайце timedatectl status і знайдзіце радкі System clock synchronized: yes і NTP service: active. Калі служба NTP не працуе, усталюйце systemd-timesyncd або chrony.

Пры стандартным Storage=auto журнал захоўваецца на дыску, толькі калі існуе /var/log/journal, і можа займаць да 10 працэнтаў файлавай сістэмы, але не больш за 4 ГБ. Задайце яўныя ліміты, каб шумны сэрвіс не запоўніў малы дыск, а тэрмін захоўвання адпавядаў вашай палітыцы прыватнасці:

# /etc/systemd/journald.conf.d/50-retention.conf
[Journal]
Storage=persistent
SystemMaxUse=1G
MaxRetentionSec=30day

Прымяніце яго праз sudo systemctl restart systemd-journald і праверце journalctl --disk-usage. Ратацыю логаў Nginx і праграмы ў /var/log выконвае logrotate, таму прывядзіце /etc/logrotate.d/ да таго ж тэрміну. Заўвагі да выпуску Debian 12 пацвярджаюць, што rsyslog больш не ўсталёўваецца па змаўчанні, таму ў Debian журнал systemd з'яўляецца адзіным сістэмным логам. Логі доступу змяшчаюць IP-адрасы, якія паводле GDPR могуць быць персанальнымі данымі, таму карацейшы тэрмін захоўвання часта і ёсць правільны.

Сакрэты і правы доступу да файлаў

Сакрэты на VPS звычайна ўцякаюць будзённымі шляхамі: файл .env, даступны для чытання ўсім карыстальнікам, ключ у гісторыі Git або зменная асяроддзя, што трапіла ў справаздачу пра збой. Даведка systemd прама кажа, што зменныя асяроддзя не падыходзяць для сакрэтаў: яны даступныя непрывілеяваным кліентам праз D-Bus і наследуюцца даччынымі працэсамі. Выкарыстоўвайце LoadCredential=, як у unit вышэй. Зыходны файл застаецца даступным толькі root, а сэрвіс атрымлівае копію толькі для чытання ў $CREDENTIALS_DIRECTORY:

sudo install -d -m 0700 -o root -g root /etc/webapp
sudo install -m 0600 -o root -g root /dev/null /etc/webapp/db_password
sudoedit /etc/webapp/db_password

systemd-creds encrypt разам з LoadCredentialEncrypted= дадаткова захоўвае файл зашыфраваным ключом хоста або TPM. Код праграмы павінен належаць root або карыстальніку для дэплою, але не карыстальніку сэрвісу, каб скампраметаваны працэс не мог перапісаць сам сябе. Пасля ўсталёўкі старонняга ПЗ шукайце файлы, даступныя для запісу ўсім, і нечаканыя setuid-файлы:

sudo find / -xdev -type f -perm -0002 -print
sudo find / -xdev -type f -perm -4000 -print

Ключу дэплою з CI вылучыце асобны радок у authorized_keys з опцыяй restrict і, дзе магчыма, спісам адрасоў from=. Агентам для праграмавання, якія выконваюць каманды на серверы, патрэбна тая ж дысцыпліна: асобны карыстальнік, ніякіх production-сакрэтаў і пацвярджэнне разбуральных каманд. Кіраўніцтва па агентным праграмаванні параўноўвае механізмы дазволаў у сучасных CLI.

Рэзервовыя копіі і хукі маніторынгу

Hardening зніжае верагоднасць інцыдэнту, а рэзервовыя копіі і алерты вызначаюць, колькі ён працягнецца. Здымкі правайдара зручныя для хуткага адкату, але жывуць у тым жа акаўнце, што і сервер, таму незалежнай копіяй не з'яўляюцца. Трымайце зашыфраваную версіянаваную копію па-за правайдарам і правярайце аднаўленне. Кіраўніцтва па рэзервовым капіяванні 3-2-1 з restic разбірае структуру рэпазіторыя, захоўванне і вучэнні па аднаўленні.

Аднаму VPS патрэбна некалькі сігналаў: вонкавая HTTP-праверка праз CDN, праверка таго, што origin адмаўляе ў прамых падключэннях, запоўненасць дыска, тэрмін дзеяння сертыфікатаў, збойныя unit systemd і heartbeat ад кожнай планавай задачы, каб моўчкі спынены бэкап выклікаў алерт. systemd умее выклікаць апавяшчэнне пры збоі любога unit:

# /etc/systemd/system/[email protected]
[Unit]
Description=Alert on failure of %i

[Service]
Type=oneshot
ExecStart=/usr/local/bin/notify-failure %i

Дадайце OnFailure=notify-failure@%n.service у секцыю [Unit] unit-файлаў праграмы і рэзервовага капіявання. Скрыпт можа адпраўляць назву unit і апошнія радкі журнала ў webhook чата або сістэмы апавяшчэнняў. Экспарцёры метрык, напрыклад Prometheus node exporter, павінны слухаць localhost або прыватную сетку. Калі на серверы працуюць AI-агенты ці MCP-інструменты з доступам да shell, вылучыце ім асобнага карыстальніка і пясочніцу і лічыце іх уваходныя даныя недаверанымі, як тлумачыць кіраўніцтва па prompt injection і бяспецы MCP.

Чэк-ліст на першую гадзіну

1. Усталюйце абнаўленні, стварыце іменнага карыстальніка з sudo і трымайце кансоль правайдара адкрытай.
2. Усталюйце ключ Ed25519 і дадайце 00-hardening.conf з адключаным уваходам пад root і па паролі.
3. Выканайце sshd -t і sshd -T, перазапусціце ssh і праверце новую сесію да закрыцця старой.
4. Уключыце файрвол з забаронай па змаўчанні для IPv4 і IPv6, адкрыўшы SSH, 80 і 443.
5. Абмяжуйце вэб-парты дыяпазонамі Cloudflare або выкарыстайце Authenticated Origin Pulls ці Tunnel і аднавіце IP наведвальнікаў у Nginx.
6. Праверце аўтаматычныя абнаўленні бяспекі і наладзьце аўтаматычныя перазагрузкі.
7. Уключыце fail2ban або CrowdSec для SSH, а для HTTP выкарыстоўвайце WAF у CDN.
8. Запусціце праграму ад асобнага карыстальніка ў пясочніцы systemd і праверце systemd-analyze security.
9. Праверце сінхранізацыю часу і задайце ліміты памеру і тэрміну захоўвання журнала.
10. Перанясіце сакрэты ў файлы credentials, даступныя толькі root, і праверце правы доступу.
11. Наладзьце рэзервовыя копіі па-за правайдарам, праверце аднаўленне і дадайце алерты пра збоі і heartbeat.
12. Адзін раз наўмысна перазагрузіце сервер і пераканайцеся, што ўсе службы вярнуліся без ручных дзеянняў.