Linux VPS қорғау: SSH, файрвол, жаңарту және мониторинг чек-парағы

Ubuntu немесе Debian орнатылған жаңа VPS-те алғашқы сағатта автоматты сканерлер IP мекенжайы желіде пайда болғаннан кейін бірнеше минут ішінде тексеретін есіктерді жабу керек. Жүйені жаңартыңыз, Ed25519 кілті бар sudo құқықты қарапайым пайдаланушымен кіріңіз, SSH drop-in файлы арқылы құпиясөзбен және root ретінде кіруді өшіріңіз, тек 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 бұлттық бейнелерінде sudo құқығы бар ubuntu тіркелгісі бұрыннан бар. Root құпиясөзі берілген минималды Debian орнатылымында 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 журналы	тек журнал; Debian 12-ден бері rsyslog әдепкі бойынша орнатылмайды
sudo	орнатылған	минималды орнатылымда болмауы мүмкін
OpenSSH	9.6	Debian 12-де 9.2, Debian 13-те 10.0

Ed25519 кілттері және hardening drop-in файлы бар SSH

Кілтті жасап, орнатыңыз

Кілтті серверде емес, өз жұмыс компьютеріңізде жасаңыз. 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 файлын жазыңыз

Ubuntu-дағы /etc/ssh/sshd_config файлы Include /etc/ssh/sshd_config.d/*.conf жолынан басталады, ал sshd_config анықтамасы әр кілт сөз үшін алғаш алынған мән қолданылатынын айтады. Drop-in файлдары лексикалық ретпен оқылады және негізгі файлдың қалған бөлігінен басым болады. Бұлттық бейнелерде көбіне PasswordAuthentication мәнін орнататын 50-cloud-init.conf немесе 60-cloudimg-settings.conf сияқты өз файлы болады, сондықтан өз файлыңызға кіші префикс беріңіз:

# /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 PasswordAuthentication өшірулі болса да құпиясөз сұрай алатын PAM арқылы өтетін keyboard-interactive жолын жабады. 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 ережесі 30 секунд ішінде 6 немесе одан көп қосылым ашқан мекенжайды бұғаттайды. Бұл сканерлерді баяулатады, бірақ көп параллель SSH қосылымын ашатын автоматтандыруға кедергі болуы мүмкін, ондай жағдайда қарапайым allow қолайлырақ. Әкімшінің тұрақты мекенжайы немесе VPN болса, SSH-ке тек сол жерден рұқсат беріңіз: sudo ufw allow from 198.51.100.7 to any port 22 proto tcp. /etc/default/ufw ішінде әдепкідегідей IPV6=yes тұрғанда ережелер IPv6-ға да қолданылады.

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-ны ашық қалдырыңыз: IPv6-дағы көршілерді анықтау мен жол MTU-ын анықтау соған тәуелді. flush ruleset fail2ban немесе Docker жасаған кестелерді де жояды, сондықтан ережелерді қайта жүктегеннен кейін оларды қайта іске қосыңыз. Бір хостта файрволды басқаратын бір ғана құралды пайдаланыңыз.

Веб-порттарға тек CDN-ді жіберіңіз

Сайт Cloudflare немесе басқа CDN артында тұрса, origin 80 және 443 порттарында басқа ешкімге жауап бермеуі керек. Әйтпесе origin мекенжайын ескі DNS жазбалары, сол IP-дегі пошта сервері немесе интернетті сканерлеу арқылы тапқан кез келген адам CDN-нің WAF-ын, сұраныс лимиттерін және кэшін айналып өтеді. 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 жалғандауына осал деп атайды және күштірек нұсқаларды сипаттайды: Full немесе Full (strict) шифрлау режимін талап ететін Authenticated Origin Pulls және кіріс веб-порттарын мүлде қажет етпейтін 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-те пакет sshd jail-ін systemd журналы бэкендімен және nftables әрекеттерімен қосады, ал бұл бэкенд auth.log жоқ Debian-ға да сай келеді. Оны 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 үшін CDN-нің WAF ережелері мен сұраныс шектеулерін пайдаланыңыз.

Қолданбаға арналған systemd құмсалғышы

Бэкендті shell ішінде немесе nohup арқылы емес, systemd unit файлында жеке жүйелік пайдаланушы атынан іске қосыңыз және процеске қажет емес нәрсенің бәрін systemd алып тастасын. Пайдаланушыны sudo useradd --system --no-create-home --shell /usr/sbin/nologin webapp командасымен жасаңыз. Бұл unit Nginx артында localhost-та жұмыс істейтін Node.js сервисін іске қосады:

# /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 қоспағанда тек оқуға арналған етіп тіркейді, сондықтан жазуға болатын жалғыз орын — StateDirectory= берген /var/lib/webapp. Басқа орындар үшін ReadWritePaths= қосыңыз. ProtectHome=yes /home, /root және /run/user каталогтарын жасырады, ал PrivateTmp=yes сервиске жеке /tmp пен /var/tmp береді. Бос CapabilityBoundingSet= барлық capabilities-ті алып тастайды, ал @system-service — systemd.exec анықтамасы бастапқы нүкте ретінде ұсынатын рұқсат етілген шақырулар тізімі.

MemoryDenyWriteExecute=yes әдейі қосылмаған: анықтамада оның JIT қозғалтқыштарымен үйлеспейтіні айтылған, ал Node.js-тегі V8 кодты орындау кезінде генерациялайды. Go, Rust немесе C тілдеріндегі сервистерге оны қосып, тексеріңіз.

systemd 255 орнатылған Ubuntu 24.04-те systemd-analyze security --offline=true командасы бұл файлды 1.5 деп бағалады, ал тек User= орнатылған дәл сондай unit 9.0 алды. Сервисті іске қосып, тексеріңіз:

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 тексеріңіз. /var/log ішіндегі Nginx пен қолданба логтарын logrotate айналдырады, сондықтан /etc/logrotate.d/ баптауларын да сол мерзімге келтіріңіз. Debian 12 шығарылым жазбалары rsyslog енді әдепкі бойынша орнатылмайтынын растайды, сондықтан Debian-да systemd журналы жалғыз жүйелік лог болып табылады. Қол жеткізу логтарында IP мекенжайлары бар, ал GDPR бойынша олар дербес деректер болуы мүмкін, сондықтан қысқарақ сақтау мерзімі көбіне дұрыс шешім.

Құпиялар және файлға қол жеткізу құқықтары

VPS-тегі құпиялар әдетте қарапайым жолдармен ағып кетеді: барлық пайдаланушы оқи алатын .env файлы, Git тарихындағы кілт немесе ақау туралы есепке түскен орта айнымалысы. systemd анықтамасы орта айнымалыларының құпияларға жарамайтынын тура айтады: олар D-Bus арқылы артықшылығы жоқ клиенттерге қолжетімді және еншілес процестерге мұраға беріледі. Жоғарыдағы unit сияқты LoadCredential= пайдаланыңыз. Бастапқы файлды тек 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 оқиға ықтималдығын төмендетеді, ал сақтық көшірмелер мен ескертулер оның қанша уақытқа созылатынын анықтайды. Провайдер суреттері жылдам кері қайтаруға ыңғайлы, бірақ олар сервермен бір аккаунтта тұрады, сондықтан тәуелсіз көшірме болып саналмайды. Шифрланған, нұсқаланған көшірмені провайдерден тыс сақтап, қалпына келтіруді тексеріңіз. restic арқылы 3-2-1 сақтық көшірме нұсқаулығы репозиторий құрылымын, сақтау мерзімін және қалпына келтіру жаттығуларын талдайды.

Бір VPS-ке бірнеше сигнал жеткілікті: CDN арқылы сыртқы HTTP тексерісі, origin тікелей қосылымдардан бас тартатынын тексеру, дискінің толуы, сертификаттардың жарамдылық мерзімі, істен шыққан systemd unit-тері және әр жоспарлы тапсырмадан 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

Қолданба мен сақтық көшірме unit файлдарының [Unit] бөліміне OnFailure=notify-failure@%n.service қосыңыз. Скрипт unit атауы мен журналдың соңғы жолдарын чаттың немесе ескерту жүйесінің webhook-ына жібере алады. Prometheus node exporter сияқты метрика экспорттаушылары localhost-ты немесе жеке желіні тыңдауы керек. Серверде shell-ге қолжетімді AI агенттері немесе MCP құралдары жұмыс істесе, оларға жеке пайдаланушы мен құмсалғыш бөліп, кіріс деректерін сенімсіз деп есептеңіз, мұны prompt injection және MCP қауіпсіздігі нұсқаулығы түсіндіреді.

Алғашқы сағатқа арналған чек-парақ

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