Inštalácia serverového firewallu: Ochrana servera pred DDoS a botmi

Inštalácia serverového firewallu je proces, pri ktorom sa otvoria iba nevyhnutné porty na serveri a všetky zbytočné prístupy sa zablokujú; vytvára prvú obrannú líniu proti DDoS, brute force a škodlivému botovému prenosu. Cieľom je v praxi obmedziť prístup cez SSH, kontrolovane otvoriť webové služby, obmedziť podozrivé požiadavky na určitý podiel, sledovať logy a, ak je to možné, filtrovať prenos pomocou nadstavbovej ochrany ako CDN/WAF ešte predtým, ako dorazí na server.

Ako náhle otvoríte webový server na internete, môžete sa do niekoľkých minút stretnúť s portovými skenovaniami, pokusmi o prístup cez SSH, botmi zneužívajúcimi zraniteľnosti a falošnými používateľskými agentmi. Obzvlášť pre štruktúry prevádzkujúce WordPress, e-commerce, panely, API alebo herné servery nie je firewall len technickou voľbou, ale nevyhnutnosťou pre trvalú prevádzku. V tejto príručke si krok za krokom zriadime architektúru firewallu pre Linux servery; spoločne sa pozrieme na UFW, firewalld, nftables, Fail2ban, webový aplikačný firewall a prístupy na zníženie DDoS.

Začnime s dôležitou pravdou: Lokálny serverový firewall nedokáže zastaviť veľké DDoS útoky. Keď útok s objemom 20 Gbps, 80 Gbps alebo vyšším dosiahne dátové centrum alebo sieťovú infraštruktúru, pakety môžu zaplniť šírku pásma skôr, ako sa dostanú k pravidlám vo vašom operačnom systéme. Preto je správny prístup viacvrstvová ochrana: DDoS ochrana na úrovni poskytovateľa, CDN/WAF, firewall operačného systému, obmedzenie prístupu na úrovni aplikácie a pravidelná analýza logov musia fungovať spoločne. Pre vhodný výber infraštruktúry môžeme odkázať na stránku Hostragons riešenia VPS a VDS servera a pre bezpečné možnosti webhostingu na stránku Hostragons balíky web hostingu.

Aké funkcie má serverový firewall?

Serverový firewall je bezpečnostná vrstva, ktorá filtruje sieťový prenos na základe zdrojovej IP, cieľovej IP, portu, protokolu, stavu pripojenia a v niektorých prípadoch aj charakteristík paketov. S jednoduchým príkladom; pre vašu webovú stránku musia byť otvorené porty 80 a 443, zatiaľ čo port databázy 3306 by nemal byť otvorený na internete. Namiesto toho, aby ste povolili všetkým pokusy o prístup na port 22 pre SSH, je bezpečnejšie povoliť prístup iba z vašej kancelárskej IP adresy.

Základným cieľom firewallu nie je mágicky eliminovať všetky útoky. Skutočným cieľom je zmenšiť útočnú plochu. Čím menšia je útočná plocha, tým menej možností má útočník, aby sa pokúsil preniknúť. Napríklad novovytvorený Linux server môže mať súčasne otvorené SSH, webový panel, poštovú službu, databázu, monitoring agent a testovacie služby. Každá z nich predstavuje samostatné riziko. Dobre nastavený firewall funguje na princípe "predvolene odmietnuť, povoliť to, čo je potrebné".

Pochopenie DDoS a botového prenosu

Čím sú DDoS útoky odlišné?

DDoS, teda distribuovaný útok na odmietnutie služby, sa snaží urobiť cieľovú službu nedostupnou masívnym prenosom z mnohých zdrojov. Útok niekedy zaplní šírku pásma, inokedy spotrebuje CPU a RAM zdroje servera, a niekedy aktivuje drahé operácie na aplikačnej vrstve. Napríklad malý aplikačný server, ktorý prijíma 50 000 HTTP požiadaviek za sekundu, sa môže stať nefunkčným kvôli PHP-FPM, Node.js alebo pripojeniu k databáze, aj keď sieťová linka nie je zaplnená.

Sú všetky boty zlé?

Nie. Googlebot, Bingbot a niektoré monitorovacie boty sú užitočné. Avšak škodlivé boty vykonávajú skenovanie administračných panelov, hľadanie otvorených adresárov, spamovanie formulárov, kopírovanie obsahu, zneužívanie XML-RPC, vytváranie falošných registrácií a pokusy o prihlásenie. Preto je cieľom správy botov neblokovať všetky boty, ale rozlišovať ich na základe správania. Vysoká miera chýb, veľké množstvo požiadaviek za veľmi krátky čas, hlavičky, ktoré sa správajú inak ako skutočný prehliadač, a podozrivé vzory URL sú dôležité signály.

Kontrolný zoznam pred začatím inštalácie

Najväčším rizikom pri písaní pravidiel firewallu na živom serveri je, že sa zamknete z prístupu k serveru. Preto je potrebné pred vykonaním zmien urobiť krátku prípravu. Nasledujúci kontrolný zoznam predstavuje bezpečný prístup, ktorý sa často používa v produkčných prostrediach.

• Nezavrite aktívnu SSH reláciu; vykonajte test pomocou druhého terminálu.
• Uistite sa, že váš poskytovateľ serverov ponúka prístup cez konzolu, VNC alebo obnova.
• Vytvorte zoznam existujúcich otvorených portov: skontrolujte výstup ss -tulpn alebo netstat -tulpn.
• Poznačte si, ktoré porty používajú webové, poštové, DNS, databázové, panelové a monitorovacie služby.
• Ak používate IPv6, naplánujte aj pravidlá firewallu pre IPv6.
• Najprv implementujte pravidlá na povolenie a potom pravidlá na zamietnutie.
• Uistite sa, že súbor pravidiel je trvalý; nemal by sa stratiť pri reštarte servera.

Napríklad na typickom serveri, ktorý hostí iba webovú stránku, sú porty, ktoré by mali byť otvorené, často 80, 443 a obmedzený port pre SSH. Ak nefunguje poštový server, porty ako 25, 465, 587, 993 nemusia byť otvorené. Ak je databáza používaná iba z tohto servera, porty 3306 alebo 5432 by mali byť uzavreté pre vonkajší svet.

Aký nástroj firewallu by ste mali zvoliť?

V Linuxovom svete existuje množstvo nástrojov a väčšina z nich spravuje rovnakú infraštruktúru filtrovania jadra s rôznymi užívateľskými rozhraniami. Pre začiatočníkov je UFW jednoduchý a rýchly. V podnikových alebo systémoch založených na Red Hat je populárny firewalld. V pokročilých scenároch ponúka nftables modernú a flexibilnú architektúru. Nasledujúca tabuľka uľahčuje výber.

Krok za krokom: Inštalácia serverového firewallu

1. Určte otvorené porty a služby

Prvým krokom je zistiť, čo je otvorené. Príkaz ss -tulpn na Linux serveri ukazuje, ktoré služby počúvajú na ktorých portoch. Napríklad, ak nginx počúva na 0.0.0.0:80 a 0.0.0.0:443, znamená to, že webový prenos je prijímaný zo všetkých rozhraní. Ak MariaDB počúva na 0.0.0.0:3306, je to zvyčajne rizikové; väčšina webových stránok by mala mať databázu spustenú na 127.0.0.1.

Praktické pravidlo je nasledovné: Žiadna služba, ktorá nemusí byť prístupná z internetu, by nemala počúvať na 0.0.0.0. Najprv je lepšie opraviť konfiguráciu služby a potom ju uzavrieť pomocou firewallu. Pretože aj keď je firewall vypnutý, služba by nemala byť otvorená pre vonkajší svet.

2. Nastavte predvolené pravidlo na uzavretie

V bezpečných sadách pravidiel sa predvolený prichádzajúci prenos odmieta a odchádzajúci prenos sa uvoľňuje podľa potreby. Tento prístup zabraňuje tomu, aby sa neskôr nainštalované služby omylom otvorili na internete. Logika pre Ubuntu server používajúci UFW je nasledovná: najprv sa povolí SSH, potom sa otvoria porty 80 a 443, následne sa predvolené prichádzajúce pravidlo nastaví na deny a firewall sa aktivuje.

Príklad toku: Povoľte SSH pre vašu IP adresu správcu, otvorte HTTP a HTTPS prenos, zavrite zbytočné porty a potom aktivujte. Otvorenie firewallu bez povolenia SSH patrí medzi najčastejšie chyby, najmä na vzdialených serveroch.

3. Obmedzte prístup cez SSH

SSH je jednou z najviac cielenej služieb útočníkmi. Server s otvoreným predvoleným portom 22 môže denne vidieť stovky alebo tisíce pokusov o uhádnutie hesla. Najbezpečnejší prístup je obmedziť prístup cez SSH na určité IP adresy. Ak používate statickú IP, povoľte prístup len z vašej kancelárie alebo VPN IP adresy. Ak nemáte statickú IP, aspoň použite autentifikáciu na základe kľúča a vypnite prihlásenie heslom.

• Zakážte priamy prístup cez SSH s rootom.
• Použite SSH kľúč namiesto hesla.
• Obmedzte používateľov pomocou AllowUsers alebo AllowGroups.
• Automaticky blokujte neúspešné pokusy pomocou Fail2ban.
• Ak používate administračný panel, obmedzte prístup k panelu aj na IP.

Zmena portu sama o sebe nezabezpečuje bezpečnosť, ale môže znížiť automatizovaný šum botov. Skutočná ochrana však vyžaduje obmedzenie IP, silnú autentifikáciu a sledovanie logov.

4. Kontrolovane otvorte webové porty

Pre väčšinu serverov, ktoré publikujú webové stránky, sú porty 80 a 443 nevyhnutné. V súčasnosti by mal byť port 443, teda HTTPS, hlavným prenosovým portom, zatiaľ čo port 80 by sa mal používať len na presmerovanie na HTTPS. Webové stránky bez SSL certifikátu negatívne ovplyvňujú dôveru používateľov a SEO výkon. V tomto ohľade je Hostragons SSL certifikáty prirodzenou príležitosťou na prepojenie, ktorá nasmeruje čitateľa k bezpečnej inštalácii HTTPS.

Pri otváraní webových portov dbajte na skutočné správanie IP. Ak používate CDN alebo reverzný proxy, je silnejšou ochranou povoliť prenos len z IP rozhraní CDN namiesto toho, aby ste otvorili porty 80 a 443 pre celý internet. Takto útočník, aj keď pozná skutočnú IP adresu servera, sa nemôže priamo pripojiť k webovej službe.

5. Uzavrite databázu a interné služby pred internetom

Otvorenie služieb ako MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB a podobne na internete predstavuje vážne riziko. Nedostatok autentifikácie pre Redis, neoprávnený prístup k indexu pre Elasticsearch alebo otvorený administratívny port pre MongoDB viedli v minulosti k mnohým únikom údajov. Tieto služby by mali, ak je to možné, počúvať len na localhost alebo prostredníctvom súkromnej siete.

Napríklad pre WordPress stránku bežiacu na rovnakom serveri je dostatočné, aby databáza bežala na 127.0.0.1. Ak používate samostatný aplikačný a databázový server, povoľte prístup len z privátnej IP adresy aplikačného servera. Nechať prístup k portom 3306 alebo 5432 z verejného internetu je známa chyba, ktorú neustále skenujú boty.

6. Zablokujte pokusy o brute force pomocou Fail2ban

Fail2ban sleduje logy a detekuje opakované neúspešné pokusy o prihlásenie, a dočasne blokuje príslušnú IP adresu. Pre SSH, nginx, Apache, Postfix, Dovecot, prihlásenie WordPressu a niektoré panelové služby môžu byť definované jails. Napríklad blokovanie IP adresy, ktorá urobila 5 neúspešných pokusov o SSH v priebehu 10 minút, na 1 hodinu je jednoduchý, ale účinný začiatok.

Pri konfigurácii Fail2ban buďte opatrní pri použití príliš agresívnych pravidiel. Nesprávny vzor logu môže zablokovať aj skutočných používateľov. Preto je v počiatočnej fáze lepšie udržiavať hodnotu bantime na rozumnej úrovni, sledovať logy a neskôr implementovať postupné sprísňovanie.

7. Pridajte obmedzenie prenosu a limity pripojení

Na úrovni operačného systému môže obmedzenie prenosu pomôcť proti DDoS a botovému prenosu. Napríklad, ak prichádza nadmerné množstvo nových pripojení zo samej IP adresy za sekundu, môže sa uplatniť limit. Na strane webového servera môžu byť pre nginx použité moduly limit_req a limit_conn, pre Apache mod_evasive alebo podobné riešenia. Na strane aplikácie by malo byť nastavené ďalšie obmedzenie prenosu pre prihlásenie, vyhľadávanie, nákupný košík, platby a API koncové body.

Konkrétny príklad: Na prihlasovacej stránke môže byť rozumné povoliť 10 pokusov za minútu pre jednu IP adresu. Pre vyhľadávací koncový bod môže byť dostatočné 2-5 požiadaviek za sekundu. Ak poskytujete API, mala by byť navrhnutá limitácia na úrovni používateľa, limit IP a analýza správania spoločne. Takto útočník nemôže len tak zmeniť IP a prekonať celý limit.

Príklad bezpečnej inštalácie pomocou UFW

Na Ubuntu alebo Debian založenom webovom serveri môže byť jednoduchý bezpečný počiatočný scenár nastavený nasledovne: najprv skontrolujte existujúce služby, povoľte prístup cez SSH z IP adresy správcu, otvorené porty 80 a 443, predvolene odmietnite prichádzajúci prenos a overte stav UFW. Ak nie je možné obmedziť prístup cez SSH na statickú IP, môžete dočasne povoliť SSH pre všetky IP a neskôr prejsť na VPN alebo statické IP riešenie.

Príklad rozhodovacej sady by mohol byť nasledovný: 203.0.113.10 ako IP adresa správcu. SSH by malo prichádzať len z tejto IP adresy. Webový prenos by mal byť otvorený pre všetkých cez porty 80 a 443. Databáza, Redis, panel a testovacie porty by mali zostať uzavreté pre vonkajší svet. Táto štruktúra je dobrým začiatkom pre mnoho malých a stredných podnikových webových stránok. Pre správne nasmerovanie domény a DNS môže byť pridaný odkaz na stránku Hostragons kontrol domény a registrácia.

firewalld a logika zón

Na serveroch založených na AlmaLinux, Rocky Linux a RHEL je bežné používanie firewalld. firewalld pracuje s konceptom zón. Public zóna je pre rozhrania otvorené na internet, trusted zóna je pre dôveryhodné súkromné siete a drop zóna sa používa na tiché odmietanie nežiadúceho prenosu. Najdôležitejším bodom je rozdiel medzi runtime a permanentnými pravidlami. Runtime pravidlo sa aplikuje okamžite, ale môže sa po reštarte stratiť; permanentné pravidlo je trvalé, ale môže vyžadovať reload.

Pri používaní firewalld v podnikových prostrediach uľahčuje servisné definície prácu. Napríklad môžete otvoriť http a https služby v public zóne a zabezpečiť, aby služba ssh bola prístupná iba z určitých zdrojových IP adries. Ak sú správcovská sieť, zálohovacia sieť a používateľský prenos na oddelených rozhraniach, logika zón zvyšuje bezpečnosť a čitateľnosť.

CDN, WAF a DDoS ochrana na úrovni poskytovateľa

Lokálny firewall prijíma rozhodnutia až po tom, čo pakety dorazia na server. Pri veľkých DDoS útokoch je však cieľom filtrovať prenos ešte predtým, než sa dostane na server. CDN, WAF a DDoS ochrana na úrovni poskytovateľa sú preto kritické. CDN poskytuje statický obsah na okrajových lokalitách, WAF filtruje škodlivé požiadavky na aplikačnej vrstve a ochrana poskytovateľa absorbuje alebo čistí objemné útoky na úrovni siete.

V ideálnom modeli prechádzajú vaše DNS záznamy cez CDN, skutočná IP adresa servera je skrytá, váš serverový firewall prijíma iba prenos z IP rozhraní CDN na portoch 80 a 443. Správne porty pre správu sú prístupné iba cez VPN alebo statickú IP. Takýto model znižuje pravdepodobnosť útoku na priamu IP a umožňuje vám odfiltrovať botový prenos pred tým, než dosiahne vašu aplikáciu. Pre obsah, ktorý sa zaoberá bezpečnosťou webu a výkonom, môže byť použitý odkaz Príručky na zrýchlenie a bezpečnosť webovej stránky.

Ochranné opatrenia na aplikačnej úrovni proti botom

Blokovanie botov nie je len o zozname IP banov. Moderné boty môžu používať proxy, mobilné siete, IP adresy dátových centier a variabilné používateľské agenty. Preto je potrebný prístup založený na správaní. Je potrebné analyzovať vysoký počet pokusov o prihlásenie z jednej IP adresy za krátky čas, neustále generovanie 404 chýb, hustota wp-login.php alebo xmlrpc.php, vzor kliknutí, ktorý sa líši od normálnych používateľov, a podozrivé hlavičky.

• Použite obmedzenie prenosu v prihlasovacích a registračných formulároch.
• Zavrite alebo obmedzte zbytočný prístup k XML-RPC.
• Chráňte administračný panel iným URL, obmedzením IP a viacfaktorovou autentifikáciou.
• Filtrujte podozrivé vzory user-agent a referer na úrovni WAF.
• Vyvážene používajte CAPTCHA alebo neviditeľné mechanizmy na overenie botov vo formulároch.
• Pre API koncové body pridajte kontroly kľúčov, podpisov, kvót a časových pečiatok.

Pri správe botov je dôležité nepoškodiť používateľskú skúsenosť. Nadmerné používanie CAPTCHA, agresívne blokovanie alebo chybné blokovanie krajín môže poškodiť vašich skutočných zákazníkov. Preto je najbezpečnejšou metódou meranie, testovanie a postupné sprísňovanie.

Sledovanie logov a pravidlá alarmu

Predpoklad, že inštalácia je dokončená, je bežná chyba. Firewall je živý systém a mal by byť pravidelne monitorovaný. V súboroch auth.log alebo secure by sa mali sledovať pokusy o SSH, anomálne požiadavky v logoch prístupu nginx, nárast 404 a 500 chýb v error logoch a sledovanie systémových metrík CPU a počtu pripojení. Aj jednoduchý alarm môže ušetriť minúty, keď útok začne.

Príklad prahových hodnôt pre začiatok by mohol byť: viac ako 100 požiadaviek 404 z tej istej IP za 5 minút, viac ako 20 pokusov na prihlasovacej stránke za 1 minútu, CPU používanie nad 90% po dobu 10 minút, počet pripojení trikrát vyšší ako normálne. Tieto prahové hodnoty sa líšia pre každú stránku; dôležité je poznať svoj normálny profil prenosu.

Bežné chyby a spôsoby, ako sa im vyhnúť

• Aktivácia firewallu bez povolenia SSH: Môže spôsobiť, že stratíte prístup na vzdialenom serveri. Vždy vykonajte test s druhou reláciou.
• Zabudnúť na IPv6: Služba môže byť otvorená cez IPv6, zatiaľ čo IPv4 je uzavretý.
• Nechať databázu otvorenú pre internet: Porty ako 3306, 5432, 6379 a 9200 sú neustále skenované botmi.
• Používať CDN a nechať skutočnú IP otvorenú: Útočník môže obísť CDN a zaútočiť priamo na server.
• Zmena pravidiel bez dokumentovania: V prípade naliehavej situácie je ťažké pochopiť, čo ktoré pravidlo robí.
• Nepripraviť plán záložného prístupu: Ak nie je prístup cez konzolu kvôli nesprávnemu pravidlu, prestoj môže trvať dlhšie.

Praktický príklad politiky firewallu

Pre malú podnikateľskú webovú stránku by mohla byť realizovateľná zhrnutá politika nasledovná: prichádzajúci prenos je predvolene uzavretý; port 443 je otvorený pre všetkých návštevníkov; port 80 je otvorený len na presmerovanie na HTTPS; SSH je prístupné iba z VPN alebo statickej IP adresy správcu; databáza je na localhost alebo v súkromnej sieti; ak sa používa CDN, porty 80 a 443 sú povolené len pre IP adresy CDN; Fail2ban monitoruje pokusy o prihlásenie cez SSH a web; logy sú odosielané na centrálny monitorovací nástroj.

Pre stredne veľký e-commerce web by sa navyše povolili IP adresy pre platobné callbacky, administračný panel by sa presunul za VPN, pre API by sa použila kvóta na úrovni používateľa, pravidlá pre SQL injection a XSS na úrovni WAF by sa aktivovali a plán dočasného filtrovania na základe krajiny alebo ASN by sa pripravil. Dôležité je mať tento plán zdokumentovaný; implementácia vopred určených postupov namiesto improvizácie počas útoku znižuje čas prestoja.

Testovanie: Pravidlá skutočne fungujú?

Po inštalácii firewallu by sa malo určite vykonať testovanie. Skenujte otvorené porty z inej siete, overte, že prístup cez SSH funguje len z povolených IP, skontrolujte, či je webová stránka prístupná cez HTTPS, a uistite sa, že port databázy je uzavretý pre vonkajší svet. Ak používate CDN, overte, že skutočná IP servera bola zablokovaná pri pokuse o priamu HTTP požiadavku.

Počas testovacej fázy nevykonávajte agresívne skenovanie, ktoré by mohlo poškodiť produkčné systémy. Cieľom je zabezpečiť bezpečné overenie. Okrem toho po každej zmene exportujte alebo zapíšte súbor pravidiel. Takto sa v prípade problému ľahko vrátiť k predchádzajúcej zdravej konfigurácii.

Plán údržby a aktualizácie

Bezpečnosť servera nie je jednorazová inštalácia, ale pravidelný proces údržby. Pri pridávaní nových služieb by sa mala prehodnotiť potreba portov, pri odstraňovaní starých služieb by sa mali odstrániť príslušné povolenia, bezpečnostné aktualizácie by sa mali aplikovať včas a logy by sa mali pravidelne kontrolovať. Vykonávanie kontroly otvorených portov aspoň raz mesačne a prehodnotenie sady pravidiel firewallu každé tri mesiace je dobrým praktickým začiatkom.

Okrem toho plán zálohovania je súčasťou bezpečnostnej stratégie. DDoS útok môže prerušiť prístup, ale ransomwaru alebo neoprávnenému prístupu môže viesť k strate údajov. Bezpečné hostovanie, SSL, správa domény a zálohovanie by mali byť zohľadnené spoločne. V tomto kontexte sú Čo treba zvážiť pri výbere bezpečného hostingu a ako sa inštaluje certifikát SSL prirodzenými pokračovaním.

Záver

Inštalácia serverového firewallu nezabezpečuje úplnú neviditeľnosť servera pred DDoS a botmi; avšak výrazne znižuje útočnú plochu, znižuje riziko neoprávneného prístupu a umožňuje vám lepšie reagovať na incidenty. Najlepšie výsledky sa dosiahnu kombinovaním DDoS ochrany na úrovni poskytovateľa, CDN/WAF, prísnych politik portov, obmedzenia SSH, Fail2ban, obmedzenia prenosu a pravidelného sledovania logov.

Ako novú projekt spúšťate, je jednoduchšie plánovať politiku firewallu na začiatku, než ju neskôr opravovať. Pri hodnotení vašich serverov, hostingu, domén a SSL na Hostragons nezabudnite zohľadniť aj vaše bezpečnostné potreby, aby ste vytvorili odolnejšie webové prostredie. Ak potrebujete, začnite malým kontrolným zoznamom: zavrite otvorené porty, obmedzte SSH, urobte HTTPS povinným a sledujte logy.

Často kladené otázky

Zabráni serverový firewall DDoS útoku úplne?

Nie. Lokálny firewall môže znížiť malé a niektoré protokolové útoky, ale na ochranu pred veľkými DDoS útokmi je potrebné použiť ochranu na úrovni poskytovateľa, CDN a WAF.

Aké porty by mali byť otvorené na webovom serveri?

Na typickom webovom serveri zostávajú otvorené porty 80 a 443. Port SSH by mal byť povolený len pre povolené IP adresy správcu. Porty databázy a interné služby by mali byť uzavreté pred internetom.

Mám používať UFW alebo firewalld?

Pre Ubuntu a Debian ponúka UFW jednoduchší začiatok. Na serveroch založených na AlmaLinux, Rocky Linux a RHEL je firewalld bežný. V pokročilých a špecifických scenároch môže byť vhodnejšie zvoliť nftables.

Môžem zastaviť botový prenos iba blokovaním IP?

Vo všeobecnosti nie. Moderné boty používajú rôzne IP adresy a proxy. Okrem blokovania IP by sa mali používať obmedzenia prenosu, pravidlá WAF, analýza správania, CAPTCHA a kvóty na úrovni aplikácie.

Aké je najväčšie riziko pri nastavovaní firewallu?

Najväčším rizikom je stratiť prístup k svojmu SSH kvôli nesprávnemu pravidlu. Preto by sa najprv malo definovať povolenie pre SSH, testovať s druhou reláciou a mať pripravený prístup cez konzolu poskytovateľa.