Kuidas VPS-i tulemüürireegleid turvaliselt seadistada
Avaldatud 4. septembril 2026
Tulemüür peaks lubama liiklust, mida teie server vajab, ja ülejäänu vaikselt tagasi lükkama. VPS-i tulemüürireeglite turvaliseks seadistamiseks alustage teenustest, mis peavad jääma kättesaadavaks, eriti SSH-st, ning lisage seejärel veebi- ja rakendusepordid ükshaaval. Ärge alustage kõige blokeerimisega ainsast avatud terminaliseansist, mis teil on. Nii muutub rahulik hooldustöö konsooli-taastamise ülesandeks.
Enamiku Linuxi VPS-i juurutuste puhul on praktiline eesmärk lihtne: keelata vaikimisi soovimatu sissetulev liiklus, lubada vajalik väljaminev liiklus ning luua kitsad sissetulevad reeglid usaldusväärsetele kasutajatele ja teenustele. See vähendab ründepinda, tegemata rutiinset haldust keeruliseks.
Alustage liikluskaardist
Enne mis tahes reegli muutmist pange kirja, mida VPS tegelikult teeb. Näiteks avalik WordPressi sait vajab tavaliselt halduseks SSH-d ning veebiliikluse jaoks porte 80 ja 443. Privaatne API võib vajada ainult HTTPS-i, samas kui andmebaasiserver peaks tavaliselt aktsepteerima ühendusi ainult privaatvõrgus asuvalt rakendusserverilt.
Kontrollige kõigepealt kuulavaid teenuseid. Enamikus Linuxi distributsioonides annab see käsk kasuliku ülevaate:
```bash sudo ss -tulpn ```
Ärge avage automaatselt iga kuvatud porti. Mõned teenused kuulavad ainult localhostil või privaatsel liidesel ega vaja avalikku tulemüüri juurdepääsu. Teised võivad olla vanad testteenused, seireagendid või tarkvara, mis ei tohiks internetist üldse kättesaadav olla.
Iga avalikult ligipääsetava pordi puhul vastake kolmele küsimusele: kes seda vajab, kust ja millise protokolli kaudu? Reegel, mis lubab HTTPS-i kõikjalt, on avaliku veebisaidi puhul tavapärane. Reegel, mis lubab andmebaasiporti kõikjalt, on tavaliselt probleem, mis ootab viisakalt logides oma aega.
Hoidke taastetee alles enne VPS-i tulemüürireeglite seadistamist
Tulemüüri muudatuste tegemise ajal hoidke aktiivsena kahte SSH-seanssi. Kasutage ühte seanssi reeglite rakendamiseks ja jätke teine puutumata. Pärast muudatuse rakendamist testige enne millegi sulgemist uuest terminalist uut ühendust. See püüab kinni vead tegelikus ühendusteekonnas, selle asemel et loota optimismile.
Kinnitage ka, et teie VPS-i teenusepakkuja konsool on saadaval. Brauseripõhine konsool või päästekeskkond on varuvariant, kui SSH blokeeritakse. See ei asenda hoolikat tööd, kuid on operatiivselt hea kindlustus.
Kui SSH töötab mittestandardsel pordil, kontrollige see enne reeglite loomist üle:
```bash sudo ss -tulpn | grep ssh ```
Mittestandardne SSH-port võib vähendada automatiseeritud skannimiste taustamüra, kuid üksi ei ole see sisuline turvalisus. Tugev autentimine, piiratud lähtejuurdepääs ja õigeaegne paikamine teevad tegeliku töö ära.
Kasutage UFW-ga vaikimisi keelavat sissetuleva liikluse poliitikat
UFW on praktiline tulemüüri liides Ubuntu ja Debianil põhinevatele VPS-serveritele. Seda on hiljem lihtne lugeda, mis on oluline siis, kui mõni teine administraator peab kell 2 öösel katkestust tõrkeotsinguga lahendama.
Kõigepealt määrake mõistlikud vaikeväärtused:
```bash sudo ufw default deny incoming sudo ufw default allow outgoing ```
Järgmisena lubage enne tulemüüri sisselülitamist SSH. Kui teie server kasutab SSH vaikimisi porti, kasutage järgmist:
```bash sudo ufw allow OpenSSH ```
Kui SSH kuulab kohandatud pordil, määrake see selgesõnaliselt. Selles näites kasutatakse porti 2222:
```bash sudo ufw allow 2222/tcp ```
Tavalise avaliku veebisaidi puhul lubage HTTP ja HTTPS:
```bash sudo ufw allow 80/tcp sudo ufw allow 443/tcp ```
Seejärel lubage tulemüür ja kontrollige saadud poliitikat:
```bash sudo ufw enable sudo ufw status numbered ```
Nummerdatud olek on kasulik, sest reegleid saab hiljem täpselt eemaldada. Vältige pärast tõrkeotsingut ajutiste laiade reeglite allesjätmist. Ajutistel reeglitel on naljakas komme muutuda püsivaks sisustuseks.
Kui VPS majutab pöördproksi taga olevat veebirakendust, ei pruugi rakenduse port olla vaja avalikuks teha. Näiteks võib Nginx võtta liiklust vastu portidel 80 ja 443, samal ajal kui rakendus kuulab aadressil `127.0.0.1:3000`. Sellise ülesehituse puhul ei ole pordi 3000 jaoks tulemüürireeglit vaja.
Piirake haldusjuurdepääsu lähte-IP järgi
SSH ei tohiks olla avatud igale aadressile, välja arvatud juhul, kui teie meeskond tõesti vajab seda paindlikkust. Kui teie kontoril, VPN-il või hüppehostil on stabiilne avalik IP-aadress, piirake SSH sellega:
```bash sudo ufw allow from 203.0.113.25 to any port 22 proto tcp ```
Hajutatud meeskonna puhul, kelle kodused IP-d muutuvad, on VPN või bastionhost sageli parem lahendus kui SSH globaalselt avamine. See lisab veidi seadistustööd, kuid annab teile ühe kontrollitud haldustee ja puhtama auditeerimisjälje.
Kiiruse piiramine võib samuti vähendada lihtsaid SSH parooli äraarvamise katseid:
```bash sudo ufw limit 22/tcp ```
See ei asenda SSH-võtmeid, sobivatel juhtudel keelatud parooliautentimist ega mitmefaktorilist juurdepääsu teie haldusteel. Mõelge sellest kui ühest aiapaneelist, mitte kogu aiast.
Käsitlege andmebaase, paneele ja seiret eraldi
Andmebaasi pordid nagu MySQL pordil 3306, PostgreSQL pordil 5432, Redis pordil 6379 ja MongoDB pordil 27017 ei tohiks peaaegu kunagi olla avalikult kättesaadavad. Lubage neid ainult rakendusserveri privaatse IP-aadressi või alamvõrgu kaudu.
Näiteks selleks, et lubada MySQL-ühendusi ainult rakenduse VPS-ilt aadressil `10.10.0.12`:
```bash sudo ufw allow from 10.10.0.12 to any port 3306 proto tcp ```
Ka andmebaasiteenus ise peaks võimaluse korral siduma end ettenähtud privaatse liidesega. Tulemüürireeglid ja teenuse sidumine on eraldi kihid. Mõlema kasutamine tähendab, et ekslik tulemüüri muudatus paljastab teenuse väiksema tõenäosusega.
Majutuspaneelid, Grafana armatuurlauad ja seire lõpp-punktid väärivad sama tähelepanu. Kui need on ainult töötajatele, piirake need VPN-i, kontori IP-vahemiku või spetsiaalse haldusvõrguga. Avalikud seirelehed võivad paljastada oodatust rohkem taristu üksikasju, isegi kui need ei näita saladusi.
Arvestage teenusepakkuja tulemüüri ja IPv6-ga
Teie VPS-il võib olla rohkem kui üks tulemüürikiht. Pilve- või teenusepakkuja taseme tulemüür filtreerib liiklust enne, kui see serverini jõuab, samal ajal kui UFW, firewalld, nftables või iptables filtreerivad liiklust VPS-is endas. Mõlema kasutamine on mõistlik, kuid reeglid peavad omavahel kokku sobima.
Kui port 443 on VPS-is avatud, kuid teenusepakkuja kihis blokeeritud, ei saa külastajad ikkagi ühendust. Kui teenusepakkuja lubab porti, kuid VPS selle keelab, jääb VPS kaitstuks. Tõrkeotsingu ajal kontrollige mõlemat kihti järjekorras: teenusepakkuja poliitika, VPS-i tulemüür, teenuse kuulamisaadress ja rakenduse konfiguratsioon. Pärast nende kontrollimist räägivad logid tavaliselt sama lugu.
Ärge unustage IPv6-t. Kui teie VPS-il on avalik IPv6-aadress, on vaja samaväärseid IPv6-reegleid. UFW saab IPv6-t hallata, kui see on selle konfiguratsioonis lubatud, kuid kontrollige käsuga:
```bash sudo ufw status verbose ```
Korralikult kaitstud IPv4-aadress ei aita, kui sama teenus on IPv6 kaudu täiesti avali.
Testige väljastpoolt, seejärel jälgige tulemust
Pärast iga olulist muudatust testige võrgu kaudu, mis asub väljaspool VPS-i. Veenduge, et ettenähtud teenused töötavad, ja seejärel kinnitage, et privaatsena püsima pidanud pordid ei ole kättesaadavad. Brauseritestid on veebisaitide jaoks kasulikud, kuid käsurea testid annavad konkreetsete portide kohta selgemaid vastuseid:
```bash nc -vz your-server-ip 443 ```
Blokeeritud portide puhul võib ajalõpp või keeldumine tähendada erinevaid asju, sõltuvalt reeglist ja teenuse olekust. Vaadake üle tulemüüri olek, teenuse olek ja süsteemilogid, selle asemel et muuta korraga mitut seadistust.
Lubage logimine probleemi diagnoosimisel ettevaatlikult:
```bash sudo ufw logging low ```
Madal logimistase on tavaliselt piisav ootamatu keelatud liikluse märkamiseks, tekitamata tarbetut kettategevust. Suure koormusega serverites võivad mahukad tulemüürilogid muutuda omaette väikeseks töökorralduslikuks tülinaks.
Vaadake tulemüürireeglid üle alati, kui juurutate uue teenuse, eemaldate vana rakenduse kasutusest, muudate kontori IP-aadresse või muudate võrgutopoloogiat. Parimad reeglid ei ole kõige pikem reeglite kogum. Need on väikseim kogum, mis kirjeldab täpselt, kuidas server peaks suhtlema.
Kui eelistate seda tööd mitte üksi teha, saab hallatud VPS-i meeskond üle vaadata juurdepääsunõuded, rakendada muudatused koos taastamisplaaniga ja serverit pärast seda jälgida. At kodu.cloud, see sobitub loomulikult hallatud tegevuste ja pideva monitooringuga, eriti meeskondadele, kes peavad keskenduma klientidele ja tootele, mitte pakettide filtreerimisele.
Tulemüür teeb oma tööd siis, kui keegi seda ei märka. Hoidke poliitika kitsas, dokumenteerige, miks iga erand olemas on, ja testige juurdepääsu enne, kui kuulutate teenuse taas rahulikuks.
Andres Saar klienditoe insener