Kā droši konfigurēt VPS ugunsmūra noteikumus
Publicēts 2026. gada 4. septembrī
Ugunsmūrim vajadzētu atļaut datplūsmu, kas jūsu serverim ir nepieciešama, un mierīgi noraidīt pārējo. Lai droši konfigurētu VPS ugunsmūra noteikumus, sāciet ar pakalpojumiem, kuriem jāpaliek sasniedzamiem, īpaši SSH, pēc tam pa vienam pievienojiet tīmekļa un lietotņu portus. Nesāciet, bloķējot visu no vienīgās atvērtās termināļa sesijas. Tā mierīgs uzturēšanas uzdevums pārvēršas par konsoles atkopšanas uzdevumu.
Lielākajā daļā Linux VPS izvietojumu praktiskais mērķis ir vienkāršs: pēc noklusējuma liegt nevēlamu ienākošo datplūsmu, atļaut nepieciešamo izejošo datplūsmu un izveidot šaurus ienākošos noteikumus uzticamiem lietotājiem un pakalpojumiem. Tas samazina uzbrukuma virsmu, nepadarot ikdienas administrēšanu sarežģītu.
Sāciet ar datplūsmas karti
Pirms maināt jebkuru noteikumu, pierakstiet, ko VPS patiesībā dara. Piemēram, publiskai WordPress vietnei parasti administrēšanai ir nepieciešams SSH un porti 80 un 443 tīmekļa datplūsmai. Privātam API var būt nepieciešams tikai HTTPS, savukārt datubāzes serverim parasti vajadzētu pieņemt savienojumus tikai no lietotņu servera privātā tīklā.
Vispirms pārbaudiet klausīšanās pakalpojumus. Lielākajā daļā Linux distributīvu šī komanda sniedz noderīgu pārskatu:
```bash sudo ss -tulpn ```
Neatveriet automātiski katru parādīto portu. Daži pakalpojumi klausās tikai uz localhost vai privātas saskarnes un tiem nav nepieciešama publiska piekļuve caur ugunsmūri. Citi var būt veci testēšanas pakalpojumi, monitoringa aģenti vai programmatūra, kam vispār nevajadzētu būt sasniedzamai no interneta.
Katram publiski pieejamam portam atbildiet uz trim jautājumiem: kam tas ir vajadzīgs, no kurienes un pa kuru protokolu? Noteikums, kas atļauj HTTPS no jebkuras vietas, ir normāls publiskai vietnei. Noteikums, kas atļauj datubāzes portu no jebkuras vietas, parasti ir problēma, kas pieklājīgi gaida žurnālos.
Saglabājiet atkopšanas ceļu, pirms konfigurējat VPS ugunsmūra noteikumus
Veicot ugunsmūra izmaiņas, uzturiet divas aktīvas SSH sesijas. Vienu sesiju izmantojiet noteikumu piemērošanai, bet otru atstājiet neskartu. Pēc izmaiņu piemērošanas pārbaudiet jaunu savienojumu no cita termināļa, pirms kaut ko aizverat. Tas atklāj kļūdas faktiskajā savienojuma ceļā, nevis paļaujas uz optimismu.
Pārliecinieties arī, ka ir pieejama jūsu VPS nodrošinātāja konsole. Pārlūkā bāzēta konsole vai glābšanas vide ir rezerves variants, ja SSH tiek bloķēts. Tas neaizstāj rūpīgu darbu, bet ir labs darbības drošības spilvens.
Ja SSH darbojas uz nestandarta porta, pārbaudiet to pirms noteikumu izveides:
```bash sudo ss -tulpn | grep ssh ```
Nestandarta SSH ports var samazināt fonisko troksni no automatizētām skenēšanām, bet tas pats par sevi nav nozīmīga drošība. Īstu darbu paveic spēcīga autentifikācija, ierobežota piekļuve no avotiem un savlaicīga ielāpošana.
Izmantojiet pēc noklusējuma liegšanas ienākošo politiku ar UFW
UFW ir praktiska ugunsmūra saskarne Ubuntu un uz Debian balstītiem VPS serveriem. To vēlāk ir viegli lasīt, kas ir svarīgi, kad citam administratoram plkst. 2 naktī jānovērš darbības pārtraukums.
Vispirms iestatiet saprātīgus noklusējumus:
```bash sudo ufw default deny incoming sudo ufw default allow outgoing ```
Tālāk atļaujiet SSH pirms ugunsmūra ieslēgšanas. Ja jūsu serveris izmanto noklusējuma SSH portu, izmantojiet:
```bash sudo ufw allow OpenSSH ```
Ja SSH klausās uz pielāgota porta, norādiet to tieši. Šajā piemērā tiek izmantots ports 2222:
```bash sudo ufw allow 2222/tcp ```
Parastai publiskai vietnei atļaujiet HTTP un HTTPS:
```bash sudo ufw allow 80/tcp sudo ufw allow 443/tcp ```
Pēc tam ieslēdziet ugunsmūri un pārbaudiet iegūto politiku:
```bash sudo ufw enable sudo ufw status numbered ```
Numurētais statuss ir noderīgs, jo noteikumus vēlāk var precīzi noņemt. Izvairieties pēc problēmu novēršanas atstāt pagaidu pārāk plašus noteikumus. Pagaidu noteikumiem ir smieklīgs ieradums kļūt par pastāvīgām mēbelēm.
Ja VPS mitina tīmekļa lietotni aiz reversā starpniekservera, lietotnes portam var nebūt jābūt publiskam. Piemēram, Nginx var pieņemt datplūsmu portos 80 un 443, kamēr lietotne klausās uz `127.0.0.1:3000`. Šādā arhitektūrā ugunsmūra noteikums portam 3000 nav nepieciešams.
Ierobežojiet administratīvo piek ļuvi pēc avota IP
SSH nevajadzētu būt atvērtam katrai adresei, ja vien jūsu komandai patiešām nav vajadzīga šāda elastība. Ja jūsu birojam, VPN vai jump host ir stabila publiskā IP adrese, ierobežojiet SSH uz to:
```bash sudo ufw allow from 203.0.113.25 to any port 22 proto tcp ```
Izkliedētai komandai ar mainīgām mājas IP adresēm VPN vai bastion host bieži ir labāks risinājums nekā SSH atvēršana globāli. Tas prasa nedaudz vairāk sākotnējā darba, bet nodrošina vienu kontrolētu administrēšanas ceļu un skaidrāku audita pēdu.
Ātruma ierobežošana var arī samazināt vienkāršus SSH paroļu minēšanas mēģinājumus:
```bash sudo ufw limit 22/tcp ```
Tas neaizstāj SSH atslēgas, atspējotu paroles autentifikāciju, kur tas ir piemēroti, vai daudzfaktoru piekļuvi caur jūsu pārvaldības ceļu. Uztveriet to kā vienu žoga paneli, nevis visu žogu.
Datubāzes, paneļus un monitoringu apstrādājiet atsevišķi
Datubāzu porti, piemēram, MySQL uz 3306, PostgreSQL uz 5432, Redis uz 6379 un MongoDB uz 27017, gandrīz nekad nedrīkst būt publiski pieejami. Atļaujiet tos tikai no lietotņu servera privātās IP adreses vai apakštīkla.
Piemēram, lai atļautu MySQL savienojumus tikai no lietotņu VPS pie `10.10.0.12`:
```bash sudo ufw allow from 10.10.0.12 to any port 3306 proto tcp ```
Pašam datubāzes pakalpojumam, kur iespējams, arī vajadzētu piesaistīties paredzētajai privātajai saskarnei. Ugunsmūra noteikumi un pakalpojuma piesaiste ir atsevišķi slāņi. Abu izmantošana nozīmē, ka kļūdaina ugunsmūra izmaiņa mazāk ticami pakļaus pakalpojumu.
Mitināšanas paneļi, Grafana paneļi un monitoringa galapunkti ir pelnījuši tādu pašu uzmanību. Ja tie ir paredzēti tikai personālam, ierobežojiet tos uz VPN, biroja IP diapazonu vai īpašu pārvaldības tīklu. Publiskas monitoringa lapas var atklāt vairāk infrastruktūras detaļu, nekā gaidīts, pat ja tajās nav redzami noslēpumi.
Ņemiet vērā nodrošinātāja ugunsmūri un IPv6
Jūsu VPS var būt vairāk nekā viens ugunsmūra slānis. Mākoņa vai nodrošinātāja līmeņa ugunsmūris filtrē datplūsmu, pirms tā sasniedz serveri, savukārt UFW, firewalld, nftables vai iptables filtrē datplūsmu pašā VPS. Abu izmantošana ir saprātīga, taču noteikumiem ir jāsakrīt.
Ja ports 443 ir atvērts VPS, bet bloķēts nodrošinātāja slānī, apmeklētājiem joprojām neizdosies pieslēgties. Ja nodrošinātājs atļauj portu, bet VPS to liedz, VPS paliek aizsargāts. Problēmu novēršanas laikā pārbaudiet abus slāņus secībā: nodrošinātāja politika, VPS ugunsmūris, pakalpojuma klausīšanās adrese un lietotnes konfigurācija. Pēc šo pārbaudes žurnāli parasti stāsta vienu un to pašu stāstu.
Neaizmirstiet par IPv6. Ja jūsu VPS ir publiska IPv6 adrese, ir nepieciešami līdzvērtīgi IPv6 noteikumi. UFW var pārvaldīt IPv6, ja tas ir iespējots tā konfigurācijā, bet pārbaudiet ar:
```bash sudo ufw status verbose ```
Pareizi aizsargāta IPv4 adrese nepalīdz, ja tas pats pakalpojums ir pilnībā atvērts caur IPv6.
Pārbaudiet no ārpuses, pēc tam uzraugiet rezultātu
Pēc katras būtiskas izmaiņas pārbaudiet no tīkla ārpus VPS. Apstipriniet, ka paredzētie pakalpojumi darbojas, un pēc tam pārliecinieties, ka porti, kuriem jāpaliek privātiem, nav sasniedzami. Pārbaude pārlūkā ir noderīga vietnēm, taču komandrindas testi sniedz skaidrākas atbildes par konkrētiem portiem:
```bash nc -vz your-server-ip 443 ```
Bloķētiem portiem noildze vai atteikums var nozīmēt dažādas lietas atkarībā no noteikuma un pakalpojuma stāvokļa. Pārskatiet ugunsmūra statusu, pakalpojuma statusu un sistēmas žurnālus, nevis vienlaikus mainiet vairākus iestatījumus.
Ieslēdziet žurnalēšanu uzmanīgi, diagnosticējot problēmu:
```bash sudo ufw logging low ```
Zema līmeņa žurnalēšana parasti ir pietiekama, lai pamanītu negaidīti liegtu datplūsmu, neradot nevajadzīgu diska aktivitāti. Aizņemtos serveros liela apjoma ugunsmūra žurnāli var kļūt par atsevišķu nelielu darbības apgrūtinājumu.
Pārskatiet ugunsmūra noteikumus ikreiz, kad izvietojat jaunu pakalpojumu, atsakāties no vecas lietotnes, maināt biroja IP adreses vai pārveidojat tīkla arhitektūru. Labākie noteikumi nav garākais noteikumu kopums. Tie ir mazākais kopums, kas precīzi apraksta, kā serverim vajadzētu sazināties.
Ja nevēlaties šo darbu uzņemties vienatnē, pārvaldīta VPS komanda var pārskatīt piekļuves prasības, piemērot izmaiņas ar atkopšanas plānu un pēc tam uzraudzīt serveri. Kodu.cloud tas dabiski iederas līdzās pārvaldītām darbībām un pastāvīgai uzraudzībai, īpaši komandām, kurām jākoncentrējas uz klientiem un produktu, nevis pakešu filtrēšanu.
Ugunsmūris dara savu darbu tad, kad neviens to nepamana. Saglabājiet politiku šauru, dokumentējiet, kāpēc pastāv katrs izņēmums, un pārbaudiet piekļuvi, pirms paziņojat, ka pakalpojums atkal ir mierīgs.
Andres Saar Klientu apkalpošanas inženieris