Ugniasienė įjungta, bet Docker portas pasiekiamas iš interneto. Kodėl?
Veikianti UFW ugniasienė dar neįrodo, kad konteinerio administravimo sąsaja uždaryta. Publikuojant Docker portus svarbu patikrinti tikrąjį tinklo kelią ir pasiekiamumą iš išorės.
Kai bandomoji paslauga tampa vieša
Įsivaizduokime įmonės Linux serverį, kuriame administratorius paleidžia naują konteinerį. Paslauga veikia, prisijungimo langas atsidaro, o UFW taisyklėse leidžiami tik būtini įmonės ryšiai. Atrodo, kad bandymą galima užbaigti. Tačiau konteinerio portas buvo publikuotas plačiau, negu planuota.
Tai iliustracinė situacija, o ne pranešimas apie naują pažeidžiamumą ar konkretų įsilaužimą. Jos esmė – skirtumas tarp administratoriaus numatyto rezultato ir faktinio paslaugos pasiekiamumo. Įmonėje verta tikrinti abu: ką aprašo konfigūracija ir ką iš tikrųjų gali pasiekti išorinis klientas.
Kodėl vien UFW būsenos nepakanka?
Oficialioje Docker dokumentacijoje nurodoma, kad Linux sistemoje konteinerių „bridge“ tinklams Docker sukuria savo ugniasienės taisykles. Publikuotų portų srautas gali būti nukreiptas NAT taisyklėmis dar prieš pasiekdamas UFW naudojamas INPUT ir OUTPUT grandines. Todėl įprastos UFW taisyklės gali nesuteikti tokio apribojimo, kokio tikisi administratorius.
Tai nereiškia, kad kiekvienas Docker serveris atviras internetui: rezultatą lemia tinklo režimas, maršrutizavimas ir kitos ugniasienės. Docker taip pat perspėja, kad savavališkas jo taisyklių keitimas ar automatinio jų kūrimo išjungimas gali sutrikdyti konteinerių tinklą. Žr. Docker ugniasienių dokumentaciją.
Skirtumas slypi publikavimo adrese
Pagal numatytąją konfigūraciją parametras -p 8080:80 susieja serverio 8080 portą su konteinerio 80 portu visuose serverio adresuose. Tai nėra tas pats, kas publikavimas tik vietiniam naudojimui. Pavyzdžiui, -p 127.0.0.1:8080:80 įprastame „bridge“ NAT scenarijuje susiejamas su serverio IPv4 „loopback“ adresu.
Svarbi versijų išimtis: Docker perspėja, kad senesnėse nei 28.0.0 versijose net į „localhost“ publikuotus portus galėjo pasiekti tame pačiame antrojo tinklo lygmens segmente esantys įrenginiai. Specialūs tiesioginio maršrutizavimo nustatymai taip pat reikalauja atskiro vertinimo. Todėl vienos komandos nereikėtų laikyti universalia saugumo garantija. Šiuos niuansus paaiškina Docker portų publikavimo vadovas.
Pradėkite nuo paslaugų sąrašo
INsec rekomenduojame kiekvienam konteineriui užrašyti paskirtį, atsakingą žmogų ir numatytą auditoriją. Ar paslauga skirta klientams? Tik darbuotojams per VPN? Tik kitai to paties sprendimo daliai? Šis sprendimas turėtų būti priimtas prieš kopijuojant paleidimo pavyzdį iš projekto dokumentacijos.
Atskirai pažymėkite administravimo sąsajas, duomenų bazes ir bandomąsias sistemas. Joms viešas prisijungimo langas dažnai nėra verslo poreikis. Peržiūroje naudinga turėti lentelę: paslauga, publikavimo adresas, portas, leidžiami klientai, patikrinimo data. Ji padeda pastebėti skirtumą tarp suplanuoto ir realaus diegimo.
Patikrinkite iš tinklo, kuriame neturėtų veikti
Priėmimo testui siūlome du aiškius scenarijus. Pirmame autorizuotas darbuotojas pasiekia reikalingą paslaugą numatytu būdu. Antrame klientas už leidžiamos prieigos ribų jos pasiekti negali. Abu rezultatus verta užfiksuoti: vien sėkmingas prisijungimas neparodo, ar apribojimai veikia.
Tikrinkite savo administruojamus adresus iš atskiro išorinio tinklo. Jei aplinka turi IPv4 ir IPv6, į patikrą įtraukite abu. Iš anksto sutarkite konkretų serverį ir portą, o rezultatus susiekite su konfigūracijos versija. Testą pakartokite po konteinerio perleidimo ir reikšmingų tinklo pakeitimų.
Pataisymas turi išlikti po kito diegimo
INsec siūlome taisyti ne tik veikiančios sistemos būseną, bet ir jos paleidimo aprašą. Užfiksuokite sprendimą naudojamame Compose faile ar kitame diegimo šaltinyje. Priešingu atveju kitas atnaujinimas gali vėl atkurti seną, per plačią konfigūraciją.
Pakeitimui numatykite patikros ir grįžimo planą. Patvirtinkite, kad darbuotojai vis dar gali atlikti savo darbą, o nereikalinga prieiga uždaryta. Nežinomų ugniasienės taisyklių nereikėtų aklai trinti veikiančiame serveryje. Pirmiausia išsiaiškinkite, kam jos reikalingos ir kokį srautą valdo.
Jei portas jau buvo atviras
Netikėtai pasiekiama paslauga savaime neįrodo įsilaužimo. Tačiau rekomenduojame užfiksuoti galimą atvirumo laikotarpį, peržiūrėti paslaugos prisijungimų žurnalus ir įvertinti, kokia informacija buvo prieinama. Tolimesnius veiksmus – prisijungimo duomenų keitimą, sesijų nutraukimą ar incidento tyrimą – rinkitės pagal rastus požymius.
Praktinis klausimas jūsų komandai: ar turite ne tik ugniasienės taisyklių sąrašą, bet ir patvirtintą išorinės prieigos patikrą po paskutinio diegimo?
INsec padeda prižiūrėti Linux serverius ir įvertinti paslaugų prieigos konfigūraciją. Aptarkime jūsų serverių aplinką.
Šaltiniai
Techninis paaiškinimas paremtas oficialia dokumentacija; patikrų ir darbo organizavimo žingsniai – INsec praktinės rekomendacijos.