Mājas lapu aizliegums pēc nosaukuma
Dažreiz ir nepieciešams ierobežot piekļuvi noteiktām mājaslapām pēc domēna nosaukuma: birojā, skolā, viesnīcā, ģimenes tīklā vai servera vidē, kur gribam samazināt riskus (piemēram, bloķēt ļaunprātīgus domēnus, reklāmu tīklus vai “nevajadzīgus” resursus). Bloķēšana “pēc nosaukuma” nozīmē, ka mēs orientējamies uz domēnu (piem., example.com), nevis uz konkrētu IP. Tas ir ērti, bet jāatceras: mūsdienās daudzi servisi izmanto HTTPS, CDN un bieži mainīgus IP, tāpēc vienkārša IP bloķēšana ne vienmēr strādā. Tāpēc visbiežāk izmanto DNS līmeņa vai proxy līmeņa pieeju.
Šajā rakstā apskatīsim vairākas metodes: hosts failu (vienkāršākais lokāli), DNS bloķēšanu (efektīvi visam tīklam), ugunsmūri ar SNI/hostname filtrēšanu (ierobežoti un atkarīgi no tehnoloģijas) un proxy risinājumus, kas ļauj veikt precīzāku kontroli, žurnālus un politikas. Ja jums vajag šādas kontroles centrāli vairākām ierīcēm, bieži noder maršrutēšanas vai drošības slānis. Šādu infrastruktūru var veidot uz MikroTik mākoņu maršrutētāja, vai arī izmantot serveri kā DNS/proxy mezglu uz VPS. Ja jums vajag profesionālu drošības perimetru, apsveriet Fortinet risinājumus.
Svarīgi: raksts ir par piekļuves ierobežošanu jūsu paša tīklā vai serverī, kuru jūs administrējat. Bloķēšana ārpus jūsu kontroles (piemēram, mēģinot ietekmēt citu cilvēku ierīces vai tīklus) nav korekts un drošs scenārijs. Turpmākie piemēri pieņem, ka jūs kontrolējat gala ierīces vai tīkla mezglus (DNS, maršrutētāju, proxy).
1) Hosts fails: vienkāršākais lokālais variants
Hosts fails ļauj lokāli “pārrakstīt” DNS atbildi konkrētam domēnam. Jūs varat norādīt, ka example.com atbilst 0.0.0.0 vai 127.0.0.1, un pārlūkprogramma nespēs atvērt lapu (vai atvērs lokālo). Tas ir ātrs risinājums vienai mašīnai, bet nav ērti lielam tīklam, jo katrā datorā tas jākonfigurē atsevišķi.
Linux vidē fails parasti ir /etc/hosts, Windows — C:WindowsSystem32driversetchosts, macOS — /etc/hosts. Pēc izmaiņām dažreiz jāiztīra DNS kešatmiņa (piem., systemd-resolved vai pārlūka cache), lai iestatījums stātos spēkā uzreiz.
# piemērs /etc/hosts 0.0.0.0 example.com 0.0.0.0 www.example.com
Trūkumi: hosts nesaprot “wildcard” (piem., *.example.com) bez manuāla saraksta, un mūsdienu servisi bieži izmanto daudz apakšdomēnu. Tāpēc hosts ir labs “ātram fix”, bet ne pilna mēroga politiku vadībai.
2) DNS līmenis: labākais risinājums visam tīklam
DNS bloķēšana nozīmē, ka jūs iestatāt DNS serveri (piem., lokālu resolveri) tā, lai noteikti domēni neatrisinātos vai risinātos uz “tukšu” adresi. To var darīt ar dnsmasq, unbound, BIND, Pi-hole, AdGuard Home vai arī ar ugunsmūru/UTM, kas iekļauj DNS filtrēšanu. Pluss: pietiek nomainīt DNS iestatījumu maršrutētājā, un politika attiecas uz visām ierīcēm.
Piemērs ar dnsmasq: varat norādīt, ka domēns vienmēr atgriež 0.0.0.0. Tas ir vienkāršs un efektīvs, bet atcerieties: ja ierīces izmanto DoH/DoT (DNS over HTTPS/TLS) uz publiskiem DNS, tad jūsu lokālais DNS filtrs var tikt apiets. Šādā gadījumā jābloķē DoH endpointi vai jāizmanto pārvaldīta ierīču politika (MDM) vai drošības ugunsmūris.
# dnsmasq piemērs address=/example.com/0.0.0.0 address=/www.example.com/0.0.0.0
DNS līmeņa bloķēšana labi strādā reklāmu/ļaunprātīgu domēnu sarakstiem un “kategoriju” filtrēšanai. Tā arī ļauj veidot baltos sarakstus, statistiku un “override” noteikumus. Mīnuss: ja lietotājs tieši ievada IP adresi (reti, bet iespējams) vai izmanto VPN, DNS filtrs var nebūt pietiekams.
3) Ugunsmūris un HTTPS realitāte: kāpēc “pēc nosaukuma” ir sarežģīti
Tradicionāls L3/L4 ugunsmūris (iptables/nftables) strādā ar IP un portiem, nevis ar domēnu. Bloķēt “pēc nosaukuma” ugunsmūrī ir sarežģīti, jo viens IP var apkalpot simtiem domēnu (SNI/Host header), un IP var mainīties. Ir pieejami risinājumi, kas izmanto TLS SNI (server name indication) lauka analīzi, bet tas strādā tikai noteiktos apstākļos un var salūzt ar ECH (Encrypted Client Hello) attīstību.
Tāpēc, ja jums vajag drošu un stabilu “domain-based” kontroli, labākais ceļš ir DNS filtrs + politika, kas neļauj apiet (DoH/DoT kontrole), vai arī pilnvērtīgs proxy/UTM, kas var veikt TLS inspekciju (ja tas ir pieļaujams jūsu organizācijā un juridiski korekts). Uzņēmuma vidē tieši UTM risinājumi (piem., Fortinet) bieži ir saprātīgākais veids, jo tie apvieno filtrēšanu, žurnālus un politikas.
4) Proxy pieeja: visprecīzākā kontrole un žurnāli
HTTP/HTTPS proxy (piem., Squid) ļauj kontrolēt piekļuvi pēc domēna, URL, kategorijas, lietotāja un laika. Tas dod “uzņēmuma” līmeņa kontroli un iespēju redzēt, kas notiek. Tomēr HTTPS gadījumā ir divi režīmi: (1) “tikai CONNECT filtrēšana” — redz domēnu, bet neredz pilnu URL; (2) “TLS inspekcija” — redz saturu, bet prasa klienta uzticamu CA sertifikātu un skaidru politiku/atļauju. Daudzos scenārijos pietiek ar (1), ja mērķis ir vienkārši bloķēt noteiktus domēnus.
Proxy var ieviest kā “explicit proxy” (klienti konfigurē proxy), vai “transparent” (tīkls pārvirza trafiku). Transparent režīms mūsdienu HTTPS pasaulē ir sarežģītāks un var radīt neparedzamas problēmas, tāpēc uzņēmumos bieži izvēlas explicit + politikas. Ja gribat to uzlikt uz servera, praktiski to dara uz VPS vai lokāla servera, un DNS/ugunsmūris nodrošina, ka lietotāji to neapiet.
Praktiska izvēle: kuru metodi izmantot
Ja jums jābloķē pāris domēni vienā datorā — izmantojiet hosts failu. Ja jums jābloķē domēni visam mājas vai biroja tīklam — izvēlieties DNS filtrēšanu, jo tā ir vienkārši uzturama un efektīva. Ja jums vajag politikas, lietotāju autentifikāciju, žurnālus un detalizētu kontroli — izmantojiet proxy vai UTM risinājumu. Bieži reālajā dzīvē labākais ir kombinācija: DNS bloķē “pamata sarakstu”, bet ugunsmūris/proxy nodrošina, ka apiet to ir grūtāk.
Neaizmirstiet par apvedceļiem: VPN, DoH, mobilie dati, “alternate DNS” un pārlūku iestatījumi. Ja jūsu mērķis ir reāla kontrole organizācijā, jums vajag ne tikai tehnisku bloķēšanu, bet arī politiku: kas drīkst mainīt DNS, kā tiek pārvaldītas ierīces, un kā tiek dokumentēti izņēmumi. Tehnoloģija bez procesa bieži nozīmē “strādā līdz pirmajam lietotājam, kurš zina, ko dara”.