Սերվերի hardening՝ ամբողջական checklist

01Մտածելակերպը՝ շերտեր և least privilege

Hardening-ը հետևում է երկու սկզբունքի։ Defence in depth՝ ենթադրիր, որ ցանկացած առանձին շերտ կարող է ձախողվել, ուստի դասավորիր մի քանիսը (edge WAF, firewall, SSH policy, հավելվածի թույլտվություններ, backup-ներ)։ Least privilege՝ յուրաքանչյուր օգտատեր, պրոցես և key ստանում է միայն իրեն անհրաժեշտ հասանելիությունը, ուստի կոտրումը մնում է փոքր։ Աշխատիր անվտանգ հերթականությամբ, որովհետև hardening-ի դասական դժբախտ պատահարը ինքդ քեզ դուրս թողնելն է։ Նախ ստեղծիր քո օգտատերն ու key-ը, երկրորդ տերմինալում հաստատիր, որ կարող ես մուտք գործել դրանով, և միայն դրանից հետո անջատիր root-ը և գաղտնաբառերը։ SSH-ը թույլատրիր firewall-ում մինչև այն միացնելը։ Provider-ի վեբ console-ը պահիր որպես վթարային դուռ։ Յուրաքանչյուր քայլ գրի առ կարճ runbook-ում կամ script-ում, որպեսզի հաջորդ սերվերը ստանա ճիշտ նույն վերաբերմունքը, և կարողանաս հաճախորդին ապացուցել, թե ինչ է արվել։

• Կրճատիր attack surface-ը՝ ավելի քիչ բաց port-եր, ծառայություններ և փաթեթներ։
• Սահմանափակիր blast radius-ը՝ առանձին օգտատերեր, private ցանցեր, սահմանափակ credential-ներ։
• Ենթադրիր կոտրում՝ off-site backup-ներ, log-եր և alert-ներ, որոնք իսկապես կկարդաս։

021. Օգտատերեր և SSH՝ միայն key-եր, առանց root-ի

Ստեղծիր անձնական admin օգտատեր sudo-ով և տեղադրիր քո public key-ը (Ed25519 key-ը ժամանակակից լռելյայնն է)։ Հետո անջատիր root login-ը և password authentication-ը /etc/ssh/sshd_config.d/-ում drop-in ֆայլով, որն ավելի լավ է դիմանում փաթեթների թարմացումներին, քան հիմնական ֆայլի խմբագրումը։ Ubuntu-ում ծառայությունը կոչվում է ssh։ Reload-ից առաջ վավերացրու config-ը sshd -t-ով և ընթացիկ session-ը բաց պահիր, մինչ մեկ այլ տերմինալում նոր login ես ստուգում։ SSH port-ը փոխելը միայն նվազեցնում է log-ի աղմուկը․ դա անվտանգության վերահսկում չէ, ուստի արա դա միայն այն դեպքում, եթե ուզում ես ավելի հանգիստ log-եր։ Թիմերի համար յուրաքանչյուր մարդու տուր իր օգտատերն ու key-ը, որպեսզի հասանելիությունը կարելի լինի revoke անել առանձին, և հեռացրու հեռացողների key-երը։

1# On the server, as root (one time)
2adduser your_user
3usermod -aG sudo your_user
4# From your laptop
5ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
6 
7# /etc/ssh/sshd_config.d/99-hardening.conf
8PermitRootLogin no
9PasswordAuthentication no
10KbdInteractiveAuthentication no
11PubkeyAuthentication yes
12MaxAuthTries 3
13AllowUsers your_user
14 
15# Validate, then reload (keep the current session open!)
16sudo sshd -t && sudo systemctl reload ssh

032. Firewall, թարմացումներ և fail2ban

Լռելյայն մերժիր ամբողջ մուտքային traffic-ը և բացիր միայն այն, ինչ սերվերը սպասարկում է՝ SSH, HTTP և HTTPS։ Նույն կանոնները կրկնիր cloud provider-ի firewall-ում, որպեսզի traffic-ը զտվի, մինչև նույնիսկ կհասնի մեքենային։ Մեկ կարևոր թակարդ՝ Docker-ը կոնտեյների port-երը publish է անում՝ գրելով իր iptables կանոնները, որոնք շրջանցում են ufw-ն։ Compose ֆայլերում publish արված port-երը bind արա 127.0.0.1-ին, եթե դրանք իսկապես public լինելու կարիք չունեն։ Հետո միացրու unattended-upgrades-ը անվտանգության patch-երի համար․ kernel-ի թարմացումների մեծ մասին դեռ reboot է պետք, ուստի պլանավորիր maintenance window կամ թույլատրիր ավտոմատ reboot-ներ հանգիստ ժամին։ Տեղադրիր fail2ban՝ brute-force աղբյուրները ban անելու համար։ Վերջապես հեռացրու այն ծառայությունները, որոնք չես օգտագործում․ յուրաքանչյուր լսող daemon ևս մեկ բան է, որը պետք է patch անել։

1sudo ufw default deny incoming
2sudo ufw default allow outgoing
3sudo ufw allow OpenSSH
4sudo ufw allow 80/tcp
5sudo ufw allow 443/tcp
6sudo ufw enable
7sudo ufw status verbose
8 
9sudo apt update && sudo apt install -y unattended-upgrades fail2ban
10sudo dpkg-reconfigure -plow unattended-upgrades
11# Optional: /etc/apt/apt.conf.d/50unattended-upgrades
12#   Unattended-Upgrade::Automatic-Reboot "true";
13#   Unattended-Upgrade::Automatic-Reboot-Time "04:00";
14 
15sudo ss -tulpn   # everything listening; nothing unexpected on 0.0.0.0

043. Հավելվածներ՝ առանձին օգտատերեր, թույլտվություններ, private տվյալների բազաներ, secret-ներ

Յուրաքանչյուր կայք կամ հավելված գործարկիր իր system user-ով՝ իր PHP-FPM pool-ով կամ process manager-ի գրառմամբ։ Եթե մեկ հավելված կոտրվում է, այն չի կարող կարդալ մեկ այլ հավելվածի կոդը, upload-ները կամ environment ֆայլը։ Կոդը պետք է պատկանի deploy օգտատիրոջը և գրելի չլինի վեբ պրոցեսի համար․ գրելի են միայն այն թղթապանակները, որոնք պետք է փոխվեն runtime-ում (Laravel-ի storage-ը և bootstrap/cache-ը, upload թղթապանակները)։ Environment ֆայլերը կարդացվում են միայն հավելվածի օգտատիրոջ կողմից։ Տվյալների բազաները և Redis-ը լսում են localhost-ում կամ private ցանցում, և յուրաքանչյուր հավելված ունի իր least-privilege տվյալների բազայի օգտատերը։ Secret-ները գտնվում են սերվերի environment ֆայլերում կամ secrets manager-ում, երբեք՝ Git-ում, և rotate են արվում, երբ ինչ-որ մեկը հեռանում է կամ արտահոսքի կասկած կա։ Repository-ի վրա գործարկիր secret scanner, որովհետև հին commit-երում արտահոսած key-երը կոտրումների տարածված աղբյուր են։

1# One system user per app, no login shell
2sudo adduser --system --group --home /var/www/shop --shell /usr/sbin/nologin shop
3 
4# Code: owned by the deploy user, readable by the app group
5sudo chown -R deploy:shop /var/www/shop
6sudo find /var/www/shop -type d -exec chmod 750 {} +
7sudo find /var/www/shop -type f -exec chmod 640 {} +
8 
9# Only runtime folders are writable by the app
10sudo chmod -R 770 /var/www/shop/storage /var/www/shop/bootstrap/cache
11 
12# Secrets: readable by the app only
13sudo chown deploy:shop /var/www/shop/.env && sudo chmod 640 /var/www/shop/.env

054. HTTPS ամենուր և WAF առջևում

Յուրաքանչյուր կայք ստանում է certificate, սովորաբար Let's Encrypt-ից certbot-ի միջոցով, ավտոմատ թարմացմամբ (certbot-ը տեղադրում է systemd timer․ ստուգիր այն dry run-ով)։ HTTP-ն redirect արա HTTPS-ի, օգտագործիր միայն TLS 1.2 և 1.3, և ավելացրու HSTS, երբ համոզված ես, որ բոլոր subdomain-ները աշխատում են HTTPS-ով։ Cloudflare-ը կամ նմանատիպ CDN/WAF առջևում դնելը թաքցնում է origin IP-ն, կլանում է հիմնական DDoS traffic-ը և թույլ է տալիս արգելափակել վատ bot-երին և կիրառել rate limit-եր edge-ում։ Օգտագործիր Full (strict) SSL ռեժիմը, որպեսզի Cloudflare-ից քո սերվեր միացումը գաղտնագրված լինի և certificate-ը ստուգվի․ Flexible-ը traffic-ը origin ուղարկում է չգաղտնագրված։ Լրացուցիչ պաշտպանության համար 80-ը և 443-ը թույլատրիր միայն Cloudflare-ի IP միջակայքերից կամ օգտագործիր tunnel, որպեսզի հարձակվողները չկարողանան շրջանցել edge-ը՝ ուղիղ հարվածելով origin IP-ին։

1sudo apt install -y certbot python3-certbot-nginx
2sudo certbot --nginx -d example.com -d www.example.com
3sudo certbot renew --dry-run
4systemctl list-timers | grep certbot
5 
6# nginx: modern TLS and HSTS (add HSTS only when all subdomains use HTTPS)
7ssl_protocols TLSv1.2 TLSv1.3;
8add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
9add_header X-Content-Type-Options "nosniff" always;
10add_header Referrer-Policy "strict-origin-when-cross-origin" always;
11server_tokens off;

065. Backup-ներ, monitoring և audit-ներ

Hardening-ը նշանակում է նաև գոյատևել այն, ինչ չկարողացար կանխել։ Արա provider-ի snapshot-ներ և, առանձին, տվյալների բազաների և upload-ների հավելվածի մակարդակի backup-ներ՝ պատճենված այլ հաշիվ կամ provider։ Restore-ները ստուգիր ժամանակացույցով․ չստուգված backup-ը հույս է, ոչ թե պլան։ Հետևիր այն բաներին, որոնք սովորաբար սպանում են փոքր սերվերները՝ լցված սկավառակներ, հիշողության սպառում, ժամկետանց certificate-ներ և անջատված կայք։ Արտաքին uptime checker-ը (Uptime Kuma կամ provider-ի alert-ները) գումարած սկավառակի և load-ի alert-ները ծածկում են դրա մեծ մասը։ Log-երը պահիր բավական երկար՝ incident-ը հետաքննելու համար։ Հետո audit արա․ Lynis-ը scan է անում համակարգը և ցուցակում է hardening-ի կոնկրետ առաջարկներ գնահատականով, ինչը լավ ձև է բռնելու այն, ինչ checklist-ը բաց է թողել։ Փոփոխություններից հետո նորից գործարկիր այն և պահիր հաշվետվությունը։

1# Audit the system and read the suggestions
2sudo apt install -y lynis
3sudo lynis audit system
4sudo less /var/log/lynis-report.dat
5 
6# Quick health checks
7df -h                          # disk usage
8free -h                        # memory
9sudo last -n 20                # recent logins
10sudo journalctl -p err -b      # errors since boot
11sudo fail2ban-client status sshd

07SSH-ը ժամանակակից Ubuntu-ում ներսից. socket activation և կրիպտոգրաֆիա

Ubuntu 24.04-ից SSH-ը օգտագործում է systemd socket activation. ssh.socket-ը լսում է port-ը և առաջին կապի ժամանակ գործարկում ssh.service-ը։ systemd generator-ը sshd_config-ից կարդում է Port-ը և ListenAddress-ը՝ socket-ը կառուցելու համար, ուստի port-ը փոխելը նշանակում է daemon-reload գումարած ssh.socket-ի restart, ոչ թե պարզապես ծառայության reload։ Շատերն իրենց դուրս են թողել՝ փոխելով Port-ը, reload անելով ssh-ը և փակելով session-ը, մինչդեռ socket-ը դեռ լսում էր 22-ը, իսկ firewall-ը թույլատրում էր միայն նոր port-ը։ Կրիպտոգրաֆիայի առումով OpenSSH-ի ընթացիկ defaults-ը լավն են. վերջին release-ները ավտոմատ համաձայնեցնում են hybrid post-quantum key exchange, և Ed25519 key-երը ստանդարտ են։ Մի պատճենեք blog post-երից հին cipher ցուցակներ. դրանք հաճախ թուլացնում են ժամանակակից defaults-ը։ sshd -T-ն տպում է գործող կոնֆիգուրացիան բոլոր drop-in-երից հետո, իսկ ssh-audit գործիքը հաղորդում է թույլ ալգորիթմների մասին։ Ամենաբարձր վստահության համար օգտագործեք hardware-backed key-եր (ed25519-sk) security key-ի վրա, որպեսզի գողացված laptop-ի ֆայլն անօգուտ լինի։

1# /etc/ssh/sshd_config.d/99-hardening.conf
2Port 2222
3 
4# Open the new port first, then rebuild the socket
5sudo ufw allow 2222/tcp
6sudo sshd -t
7sudo systemctl daemon-reload
8sudo systemctl restart ssh.socket
9sudo ss -tlnp | grep -E ':22 |:2222 '
10 
11# Effective settings after all drop-ins
12sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|port'

08Ծառայությունների sandboxing systemd-ով

Առանձին Unix user-ը սահմանափակում է, թե որ ֆայլերը կարող է կարդալ compromised հավելվածը, բայց process-ը դեռ տեսնում է ֆայլային համակարգի մեծ մասը, կարող է գրել /tmp-ում, բեռնել կամայական binary-ներ և բացել ցանկացած ցանցային socket։ systemd-ը կարող է յուրաքանչյուր ծառայություն շատ ավելի սահմանափակել drop-in-ի մի քանի տողով. օպերացիոն համակարգի read-only տեսք, home directory-ների անհասանելիություն, private /tmp, setuid binary-ների միջոցով privilege escalation-ի բացառում և միայն անհրաժեշտ address family-ներ։ systemd-analyze security-ն յուրաքանչյուր unit-ի տալիս է գնահատական 0-ից (լավ պաշտպանված) մինչև 10 (բաց) և թվարկում բացակայող option-ները, ինչը սա դարձնում է չափելի։ Option-ները կիրառեք աստիճանաբար և թեստավորեք, քանի որ չափազանց խիստ sandbox-ը runtime-ում դրսևորվում է permission սխալներով։ MemoryMax-ը և CPUQuota-ն նաև թույլ չեն տալիս մեկ անկառավարելի process-ին ամբողջ սերվերը վայր գցել։ Նույն գաղափարները կան container-ների համար. աշխատեցնել non-root-ով, read-only root filesystem, հեռացված capability-ներ։

1# /etc/systemd/system/web.service.d/hardening.conf
2[Service]
3User=web
4NoNewPrivileges=yes
5ProtectSystem=strict
6ProtectHome=yes
7PrivateTmp=yes
8PrivateDevices=yes
9ReadWritePaths=/var/www/web/shared
10ProtectKernelTunables=yes
11ProtectKernelModules=yes
12ProtectControlGroups=yes
13RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
14CapabilityBoundingSet=
15MemoryMax=1G
16# Then: sudo systemctl daemon-reload && systemd-analyze security web.service

09Kernel-ի և ցանցի կարգավորումներ

sysctl կարգավորումները ճշգրտում են kernel-ի վարքագիծը։ Ubuntu-ն արդեն /etc/sysctl.d/10-*.conf-ում առաքում է ողջամիտ defaults. SYN cookie-ներ, պաշտպանված symlink-ներ և hardlink-ներ, սահմանափակված kernel pointer-ներ, իսկ 24.04-ից՝ AppArmor սահմանափակումներ unprivileged user namespace-երի վրա։ Փոքր լրացուցիչ ֆայլը ավելի է ամրացնում ցանցային stack-ը. անտեսել ICMP redirect-ները և source-routed փաթեթները, որոնք կարող են տրաֆիկը վերաուղղել, չուղարկել redirect-ներ, քանի որ սերվերը router չէ, և log անել անհնար source հասցեներով փաթեթները։ Երկու զգուշացում։ Docker-ը, Kubernetes-ը և VPN սերվերները պահանջում են net.ipv4.ip_forward = 1, ուստի այդպիսի host-երում երբեք կուրորեն մի անջատեք forwarding-ը։ Իսկ խիստ reverse-path filtering-ը (rp_filter = 1) կարող է կոտրել մի քանի interface-ով և ասիմետրիկ routing-ով սերվերները. այդ պատճառով Ubuntu-ն լռելյայն օգտագործում է loose mode (2)։ Կիրառեք sysctl --system-ով և rollout-ից առաջ ստուգեք, որ ցանցը և container-ները դեռ աշխատում են։

1# /etc/sysctl.d/99-hardening.conf
2net.ipv4.conf.all.accept_redirects = 0
3net.ipv6.conf.all.accept_redirects = 0
4net.ipv4.conf.all.send_redirects = 0
5net.ipv4.conf.all.accept_source_route = 0
6net.ipv6.conf.all.accept_source_route = 0
7net.ipv4.conf.all.log_martians = 1
8net.ipv4.tcp_syncookies = 1
9kernel.dmesg_restrict = 1
10kernel.kptr_restrict = 2
11 
12# Apply and check one value
13sudo sysctl --system
14sysctl net.ipv4.conf.all.accept_redirects

10Detection. իմանալ, երբ շերտը ձախողվել է

Կանխարգելումը վաղ թե ուշ ձախողվում է, ուստի պլանավորեք դա նկատել։ Log-երը ուղարկեք սերվերից դուրս (journald forwarding, Loki կամ hosted ծառայություն), քանի որ root ունեցող հարձակվողն առաջինը խմբագրում է լոկալ log-երը։ auditd-ը գրանցում է անվտանգության համար կարևոր իրադարձություններ, ինչպես /etc/passwd-ի, sudoers-ի կամ SSH key-երի փոփոխությունները։ AIDE-ի նման file integrity checker-ը կառուցում է համակարգային ֆայլերի hash-երի database և հաղորդում փոփոխությունների մասին. աշխատեցրեք այն timer-ով և baseline database-ը պահեք host-ից դուրս։ Patching-ը նույնպես ունի detection կողմ։ unattended-upgrades-ը տեղադրում է ուղղումները, բայց աշխատող process-ները հին գրադարանները պահում են հիշողության մեջ մինչև restart. needrestart-ը թվարկում է դրանք, իսկ /var/run/reboot-required-ը ասում է, որ նոր kernel-ը սպասում է reboot-ի։ Ubuntu Pro-ն, որն անվճար է փոքր քանակությամբ անձնական մեքենաների համար, ավելացնում է Livepatch՝ kernel-ի ուղղումների համար առանց reboot-ի, և Ubuntu Security Guide՝ ավտոմատացված CIS կամ DISA-STIG պրոֆիլների համար։ Alert դրեք նոր sudo user-ների, authorized_keys-ի նոր գրառումների և անսպասելի լսող port-երի վրա։

1# Watch changes to identity and SSH files
2sudo apt install -y auditd
3sudo auditctl -w /etc/passwd -p wa -k identity
4sudo auditctl -w /etc/sudoers.d -p wa -k sudoers
5sudo auditctl -w /home/your_user/.ssh/authorized_keys -p wa -k sshkeys
6sudo ausearch -k sshkeys --start today
7 
8# Services still running old libraries, and pending reboot
9sudo needrestart -r l
10[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs