Paskutinis atnaujinimas/papildymas: 2022-12-29
Raspberry Pi + DietPi OS + Pi-hole Ad Blocking + Update Pi-hole’s lists from remote sources + Unbound DNS + Wireguard VPN + Wireguard UI + UFW + Fail2ban diegimas vidiniame namų, mažos/vidutinės ar net gana didelės įmonės/organizacijos tinkle.
Turinys
Jei kada tektų grįžti:
- Ko prireiks ir kokia microSD kortelė – geriau;
- Pasiruošimas – DietPi įrašymas, įrenginio IP adreso nustatymas;
- DietPi – nustatymai ir pradinis reikiamos programinės įrangos diegimas;
- SSH raktas, Dropbear niuansai, SSH config;
- Unbound DNS ir DNSSEC tikrinimas;
- Pi-hole nustatymai ir testavimas;
- Automatinis trečiųjų šalių „juodųjų sąrašų“ atnaujinimas Pi-hole;
- Wireguard „paruošimas” Wireguard UI naudojimui;
- Wireguard UI, kaip systemd servisas; nustatymai ir testavimas;
- Saugumas; Lighttpd, UFW ir Fail2ban;
- Rezervinės microSD ir DietPi kopijos.
Turėkite omenyje, kad viskas gana greitai keičiasi ir kai kurios ekrano nuotraukos, veiksmų seka ir pan. gali jau šiek tiek skirtis. Esmės tai nekeičia, bet būkite atidesni.
Prireiks
Raspberry Pi – priklausomai nuo vidinio tinklo dydžio ir jo apkrovos – namams ar mažai įmonei turėtų užtekti ir Raspberry Pi 3 B+; didesniam ar kur kas labiau apkrautam tinklui – Raspberry Pi 4 B 2GB ar Raspberry Pi 4 B 4GB; o Raspberry Pi 4 B 8GB tikrai susidoros ir su 1-2 milijonais užklausų per parą. O keletas „triukų” padės susidoroti ir su dar didesniais kiekiais.
Jei turite, puikiai tiks ir Raspberry Pi 400, bet rekomenduočiau jį išnaudoti kam kitam, bet apie tai – kada kitą kartą :P
Jei įsigijote ne rinkinį, tai papildomai prireiks maitinimo šaltinio, tinklo laido ir korpuso. Ir rekomenduočiau įsigyti radiatorių šilumai išsklaidyti, o dar geriau – ir priklausomai nuo turimo Raspberry Pi modelio – 3-jų ar net 4-ių radiatorių komplektą. Galima rasti ir specialių korpusų, kurie, iš esmės, yra ne kas kita, o dideli radiatoriai.
Ventiliatorių, jei įmanoma, siūlyčiau vengti.
Jei neturite SD kortelių skaitytuvo, prireiks microSD USB adapterio.
Ir, žinoma, prireiks microSD kortelės. Kokios – verta panagrinėti atskirai.
microSD kortelė
Šiaip, užtektų ir pačios pigiausios ir beveik niekur negirdėto gamintojo 4 Gb talpos microSD kortelės. Klausimas tik – kiek ilgai?
Būtent taip ir gimsta mitai. Kad Raspberry Pi – tik „šiaip”, „pasižaidimams”, o SD kortelės – „nieko nelaiko”.
Bet dabartinės žinomesnių gamintojų SD kortelės „atlaiko” iki 100 tūkst. duomenų įrašymo/naikinimo ciklų. O NAND užtikrina, kad ta pati „vieta” kortelėje „drožiama” nebus – duomenų įrašymas ir jų naikinimas „slinksis”.
Kitaip tariant, kuo didesnės talpos microSD kortelė, tuo ilgiau ji tarnaus. Būtent todėl daugumoje Raspberry Pi rinkinių būna 32 Gb talpos žinomesnių gamintojų kortelės.
Ir – būtinai – „Class 10”. Nes įrašymo greitis – labai svarbu.
Mūsų atveju, 32 Gb microSD kortelė turėtų „išgyventi” 2-3 metus. O jei sumažinsime Pi-hole FTL įrašymų į DB dažnį – ir gerokai ilgiau.
Pasiruošimas
Parsisiunčiame DietPi ARMv8 64-bit, išarchyvuojame ir įrašome į microSD kortelę. Išsami instrukcija – čia.
Kortelę su DietPi – į atitinkamą Raspberry Pi lizdą; vieną tinklo laido galą – į Raspberry Pi, kitą – į maršrutizatorių; o, va, maitinimo laido vieną galą – į Raspberry Pi, o kitą – į rozetę. Jei viską padarėme teisingai, turėjo užsidegti Raspberry Pi lemputės :P
Ir belieka išsiaiškinti, kokiu adresu vidiniame tinkle mums pasiekti šį savo naują žaislą. Bet prieš tai reikia išsiaiškinti, kokia yra vietinio tinklo IP adresų sritis.
O tam reikia bent vieno įrenginio – bet kurio kompiuterio, planšetės ar telefono – IP adreso vidiniame tinkle.
„Ančiukų” atsakymai Windows ir macOS vartotojams, o „draugaujantys su pingvinais” atsidaro terminalą ir rašo ifconfig arba ip addr:
marijus@marijus:~$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether f7:74:a3:32:ca:f2 brd ff:ff:ff:ff:ff:ff 3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 10:62:c7:d7:41:cb brd ff:ff:ff:ff:ff:ff inet 192.168.1.110/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp2s0 valid_lft 35707sec preferred_lft 35707sec
Šiuo atveju, mano kompiuterio IP adresas vidiniame tinkle yra 192.168.1.110, o tai reiškia, kad mano vidinio tinklo IP adresų sritis yra 192.168.1.0/24. Kas reiškia visus adresus nuo 192.168.1.0 iki 192.168.1.255. Įsimename, nes vėliau mums to prireiks. Kaip ir maršrutizatoriaus IP adreso.
Beje, vidinio tinklo IP adresų sritį, įprastai, išduoda maršrutizatoriaus IP adresas. O ant maršrutizatoriaus, įprastai, būna lipdukas su juo :P
Kai žinome vidinio tinklo IP adresų sritį, galime jį skenuoti. Yra daugybė būdų, bet rekomenduočiau Nmap. Debian/Ubuntu atveju tai atrodytų taip:
marijus@marijus:~$ sudo nmap -sn 192.168.1.0/24 Starting Nmap 7.80 ( https://nmap.org ) at 2022-03-04 10:16 EET Nmap scan report for openwrt (192.168.1.1) Host is up (0.031s latency). Nmap scan report for dietpi.lan (192.168.1.118) Host is up (0.0024s latency).
Jei visa tai – per sudėtinga, bet turite Android telefoną – tiesiog, įsidiekite Ning. Nepamirškite tik prisijungti prie vietinio tinklo Wi-Fi :P
Štai, ir išsiaiškinome, kad – mano atveju – naujasis žaislas pasiekiamas adresu 192.168.1.118. Pradinis DietPi vartotojas yra root, o slaptažodis – dietpi, tai:
marijus@marijus:~$ ssh [email protected]
Ir, kai to reikalaujama, įvedame slaptažodį.
Mėgstantiems žiūrėti pro langus prireiks PuTTY :P
DietPi
Tik prisijungus, teks sutikti su sąlygomis:
O po to – kantriai palaukti, kol DietPi parsiųs ir įdiegs reikiamus atnaujinimus, išdidins pagrindinį skirsnį iki microSD kortelės dydžio ir t.t.
Kažkuriuo momentu, priklausomai nuo įdiegtų atnaujinimų, gali pareikalauti perkrauti sistemą. Ir pasiteiraus, ar nekankina paranoja:
Pasiūlys pasikeisti globalų programinės įrangos slaptažodį:
Ir, žinoma, vartotojų root ir dietpi slaptažodį:
Sekantis klausimas kiek sudėtingesnis, bet kartu pateiktas ir atsakymas – daugeliu atvejų to neprireiks, išjungiame:
Štai, „prisikasėme” prie DietPi-Software. Jame galima rasti tikrai labai įdomių dalykų, bet dabar mus domina DietPi-Config:
Kur randame ne ką mažiau įdomų sąrašą, bet mums reikalingi tik trys. Pradžiai – regiono nustatymai:
Ir pakeičiame laiko juostą į tą, kurioje esame, mano atveju – „Europe/Vilnius”:
Po to spaudžiame Esc ir, „grįžę” į DietPi-Config, renkamės saugumo nustatymus:
Ir keičiame pavadinimą į kažką ne tokio akivaizdaus, pvz., į kokį „katukai” ar – būtų geriausia – į visiškai bereikšmį raidžių ir skaičių kratinį:
Vėl Esc, „grįžtame” į DietPi-Config ir „keliaujame” į tinklo nustatymus:
Kur išjungiame mums visiškai nereikalingą IPv6 palaikymą:
Ir „lendame” į esamo tinklo nustatymus:
Kur DHCP:
Keičiame į statinį IP:
Ir kopijuojame esamą IP ir kitus duomenis:
O dabar – ir čia – teks apsispręsti dėl esamo IP adreso. Sakykime, kad mūsų žaislui maršrutizatoriaus priskirtas adresas yra „negražus”, „nuobodus”, „šiaip, nepatinka” ir mes norime kur kas „-esnio”, pvz., kokio 192.168.1.100 :D
Tik – prisimenate dar Nmap? – įsitikiname, kad tas „-esnis” IP adresas tikrai nėra priskirtas kokiam kitam įrenginiui vidiniame tinkle. Ir tada jau keičiame:
Ir – nepriklausomai nuo to, keitėme IP adresą ar ne – išsaugome pakeitimus:
„Tik nereikia mūsų gąsdinti”:
Ir, tikrai taip… viską, kas susiję su Wi-Fi, „metame lauk” :D
Teks kantriai palaukti. Ir – jei jau keitėme IP adresą – viskas sustos iškart po „Dropping connections, please wait…”:
Tik čia laukti jau neverta – „priverstinai” uždarome šį terminalo/PuTTY langą, atsidarome naują ir jungiamės jau tuo „-esniu” IP adresu. Kuris nuo šiol nebesikeis. Net jei pakeistume maršrutizatorių. Mums beliks tik pasistengti, kad vidiniame tinkle „netyčia” neatsirastų koks naujesnis žaislas su tokiu pačiu statiniu IP adresu :P
O tada, prisijungus, paaiškės, kad:
Enter – ir turėtume vėl atsidurti DietPi-Software. O jei nutiktų taip, kad čia „užstrigome” – Ctrl + c, reboot ir prisijungiame iš naujo.
Jei IP adreso nekeitėme – Esc, Esc, Esc, Tab, Enter – atsiduriame ten pat. Ir pasirūpiname dar vienu svarbiu dalyku – log’ais:
Galimybė – taip paprastai – visiškai „išjungti” log’us ar „sukišti” juos į RAM’us yra, turbūt, vienas įdomiausių dalykų DietPi, bet mūsų atvejis, deja, ne tas; log’ų mums gali net labai prireikti; ypač, jei vidinis tinklas – įmonės ar, tiesiog, didesnis:
Patvirtiname:
Kas mus „sugrąžins” atgal į DietPi-Software, kur „lendame” į dar vieną įdomų sąrašą:
Kurį peržvelgus, gali kilti labai daug minčių. Pvz., kad reiktų dar bent keleto Raspberry Pi :D
Tikrai patogus rinktinis sąrašas greitam diegimui. Ar – pabandymui. Yra čia ir mums reikalingi Pi-hole, Unbound ir Wireguard. Taip pat, ir Fail2ban. Susirandame juos sąraše su ↑, ↓, žymime su Space ir – Tab, Enter – patvirtiname. Čia sulauksime perspėjimo, kad DNS serveriui būtinas statinis IP adresas.
O mes tuo jau pasirūpinome, todėl tingiai spaudžiame Esc. Kas mus „sugrąžina” atgal į DietPi-Software, kur „sakome” „Go”:
Patvirtiname, kad suprantame, ką darome:
Ir teks vėl kantriai palaukti.
O jei būsime kiek atidesni, pastebėsime dar kai ką įdomaus – DietPi ne tik įdiegia, ko reikia, bet ir visą tai sukonfigūruoja. Ir kūrėjai teigia, kad:
„As well as automating the Linux installation and configuration process for you, DietPi-Software also applies specific optimizations unique to your hardware model, ensuring you get the maximum performance from your device.”.
Skamba gerai, ar ne?
Kol „apsireikš” Pi-hole:
Enter, kol sulaukiame jau eilinio perspėjimo, kad reikalingas statinis IP. Tada – Tab, Enter – patvirtiname, kad supratome:
Ir – visada – Enter, kol sulaukiame pranešimo, kad Pi-hole įdiegtas:
Išsisaugome slaptažodį ir įsimename, kad užtenka „/admin” prie IP adreso ir – vėl – Enter. Čia mums pasiūlys kiek apriboti priėjimą prie to „/admin”:
Vėl palaukiame – šįkart jau Wireguard „apsireiškimo” – ir nurodome, kad tai bus serveris:
Įvedame savo išorinį IP adresą, kurį galime sužinoti kad ir čia:
O port’ą – apie jį mes dar kalbėsime – paliekame, kokį siūlo:
Gali tekti dar kiek palaukti. Kol, galų gale, turėtume išvysti tokį vaizdą:
Ir rekomenduoju perkrauti šį naują žaislą:
root@DietPi:~# reboot Connection to 192.168.1.100 closed by remote host. Connection to 192.168.1.100 closed.
SSH raktas
Liko dar vienas dalykas, kuriuo turėtų pasirūpinti kiekvienas „save gerbiantis IT tinginys” – prisijungimas su SSH raktu. Labai sudėtingas daiktas tol, kol jo neturime :P
Informacija keleiviams, žiūrintiems į pasaulį pro atvirus langus – čia.
Visi kiti, neturintys šių „stebuklų” – SSH rakto ir Windows – „lenda” į terminalą ir susigeneruoja raktą taip. O tada – ssh-copy-id – kopijuojame jį į savo žaislą. Mano atveju:
marijus@marijus:~$ ssh-copy-id [email protected] /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 3 key(s) remain to be installed -- if you are prompted now it is to install the new keys [email protected]'s password: Number of key(s) added: 3 Now try logging into the machine, with: "ssh '[email protected]'" and check to make sure that only the key(s) you wanted were added.
Įvedame slaptažodį ir – kaip ir siūloma – bandome:
marijus@marijus:~$ ssh [email protected]
Ir čia mūsų laukia netikėtumas – prašo slaptažodžio, kai jo prašyti jau neturėtų.
Nežinau, kieno – DietPi ar Dropbear – kūrėjų klaida čia, bet išspręsti ją galime 4-iais būdais. Bet mes – tinginiai, o ir įpratę, kad raktai būtų saugomi ne kokiame /etc/dropbear/authorized_keys, kurio pats Dropbear neranda – kas ir nutiko šiuo atveju -, o ~/.ssh/authorized_keys.
Įvedame dar kartą tą prašomą slaptažodį ir:
root@katukai:~# mv /etc/dropbear/authorized_keys ~/.ssh
Tada – Ctrl + d – atsijungiame ir bandome jungtis iš naujo. Turėtume prisijungti be jokio slaptažodžio ir pamatyti, ką jau matę:
O tai reiškia, kad mūsų SSH raktas veikia. Ir kad slaptažodžio jau nereiks kaskart įvedinėti. Ir, išvis, dabar galime ir uždrausti prie SSH jungtis su slaptažodžiu:
root@katukai:~# nano /etc/default/dropbear
Susirandame ten:
DROPBEAR_EXTRA_ARGS=
Ir šiek tiek „pakoreguojame”:
DROPBEAR_EXTRA_ARGS="-s"
Išsaugome pakeitimus – Ctrl + x, y ir Enter – ir perkrauname Dropbear:
root@katukai:~# service dropbear restart
O iki „visai begėdiškos tinginystės” trūksta dar vienos smulkmenos. Neaktualu naudojantiems PuTTY, o visi kiti – Ctrl + d. Ir – jau savo kompiuteryje:
marijus@marijus:~$ nano .ssh/config
Kur – Ctrl + Shift + v – pridedame šias eilutes:
Host katukai HostName 192.168.1.100 Port 22 User root IdentityFile ~/.ssh/id_ed25519
Nepamirštame tik to savo „-esnio” IP adreso ir – Ctrl + x, y, Enter – išsaugoti :P
Va! Dabar galime jungtis, tiesiog, su ssh katukai. O jei prarasime SSH raktą, bus taip:
marijus@marijus:~$ ssh katukai [email protected]: Permission denied (publickey).
Bet, turint fizinį priėjimą, lengvai galima įrašyti kitą raktą. Ir ne tik raktą :D Čia – pamąstymui :D Nes laikas imtis rimtų dalykų :P
Unbound
Tie, kas jau susidūrę su Unbound diegimu, gali kiek ir nustebti – DietPi jau parsiuntė root.hints ir viską jau sukonfigūravo. Mums belieka tik:
root@katukai:~# nano /etc/unbound/unbound.conf.d/dietpi.conf
Ir – pačioje apačioje – Ctrl + Shift + v – pridėti:
# DNS record for Pi-hole Web Interface private-domain: "pi.hole" local-zone: "pi.hole" static local-data: "pi.hole IN A 192.168.1.100"
Žinoma, pakeičiame IP į tą savo kur kas „-esnį”. Va, galėsime Pi-hole pasiekti ir adresu pi.hole/admin.
Ctrl + x, y, Enter – išsaugome pakeitimus ir perkrauname Unbound:
root@katukai:~# service unbound restart
Ir įsitikiname, kad mūsų DNS veikia:
root@katukai:~# dig pi-hole.net @127.0.0.1 -p 5335
Atsakymas turėtų būti NOERROR, o ANSWER SECTION – būtinai su „IN A” IP adresu:
; <<>> DiG 9.16.22-Debian <<>> pi-hole.net @127.0.0.1 -p 5335 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33427 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;pi-hole.net. IN A ;; ANSWER SECTION: pi-hole.net. 30 IN A 3.18.136.52 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#5335(127.0.0.1) ;; WHEN: Tue Mar 15 21:18:12 EET 2022 ;; MSG SIZE rcvd: 56
Ir dvigubas DNSSEC tikrinimas. Iš pradžių – neigiamas:
root@katukai:~# dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5335
Kai atsakymas – SERVFAIL, o ANSWER SECTION net nėra:
; <<>> DiG 9.16.22-Debian <<>> sigfail.verteiltesysteme.net @127.0.0.1 -p 5335 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49908 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;sigfail.verteiltesysteme.net. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#5335(127.0.0.1) ;; WHEN: Tue Mar 15 23:48:50 EET 2022 ;; MSG SIZE rcvd: 57
Ir – teigiamas:
root@katukai:~# dig sigok.verteiltesysteme.net @127.0.0.1 -p 5335
Kai atsakymas yra NOERROR, o ANSWER SECTION turi IP:
; <<>> DiG 9.16.22-Debian <<>> sigok.verteiltesysteme.net @127.0.0.1 -p 5335 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16493 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;sigok.verteiltesysteme.net. IN A ;; ANSWER SECTION: sigok.verteiltesysteme.net. 300 IN A 134.91.78.139 ;; Query time: 40 msec ;; SERVER: 127.0.0.1#5335(127.0.0.1) ;; WHEN: Tue Mar 15 23:54:55 EET 2022 ;; MSG SIZE rcvd: 71
Jei viskas taip ir yra, reiškia, mūsų DNS veikia kuo puikiausiai. Laikas prie jo „prijungti” Pi-hole.
Pi-hole
Visų pirma, jei nenusikopijavome ar tas – automatiškai sugeneruotas – Pi-hole slaptažodis „nemielas” – pihole -a -p – keičiame jį.
Ir – jau naršyklėje – „keliaujame” į pi.hole/admin. Jei šis adresas „nesuveiktų”, adreso laukelyje įrašome savo žaislo IP adresą ir pridedame „/admin”:
Čia renkamės „Login”, įvedame slaptažodį ir spaudžiame „Log in”:
Ir, prisijungę, renkamės „Settings”, po to – „DNS”, kur:
- „nuimame varnas” – jei tokių yra – ties žinomais viešais DNS serveriais;
- „dedame varną” ties „Custom 1 (IPv4)” ir nurodome jau savo lokalų Unbound DNS – 127.0.0.1#5335;
- esame vidiniame tinkle, maršrutizatoriaus 53 port’o neliesime, o saugumu dar pasirūpinsime – renkamės „Permit all origins”:
„Leidžiamės žemyn” prie „Advanced DNS settings”. Čia viskas gali atrodyti labai komplikuotai, bet esmė yra ta, kad mūsų DHCP serveriu jau yra mūsų maršrutizatorius, todėl:
- nenaudosime Pi-hole kaip DHCP – „nuimame varnas” ties „Never forward non-FQDN A and AAAA queries” ir „Never forward reverse lookups for private IP ranges”;
- ir viską nukreipiame į maršrutizatorių – „dedame varną” ties „Use Conditional Forwarding” ir nurodome savo vidinio tinklo IP adresų sritį bei maršrutizatoriaus IP adresą.
Tik „nededame varnos” ties „Use DNSSEC” – tuo jau „rūpinasi” Unbound. Ir nepamirštame išsaugoti pakeitimų:
Belieka įsitikinti, kad mūsų „juodoji skylė” veikia. Tą galime padaryti dviem būdais.
Arba – laikinai – kuriam savo įrenginiui nurodome savo DNS IP adresą – ančiukų atsakymai Windows ir macOS vartotojams, o Pop_OS! tai atrodo štai taip:
Arba savą DNS nurodome maršrutizatoriaus DHCP. Ką, galų gale, vis tiek teks padaryti.
Skirtingų gamintojų maršrutizatoriuose tai gali kiek skirtis, bet esmė – ta pati. Šią ekrano nuotrauką, kaip pavyzdį, kiek „paredagavęs”, „nukosėjau” iš pažįstamo:
O po to „užsukame” į kurį „naujienų” portalą :D Ir, „grįžę” į Pi-hole, turėtume pamatyti jau kiek kitokį vaizdą:
Belieka įsitikinti, kad ir DNSSEC tikrai veikia – „keliaujame” į DNSSEC Resolver Test ir spaudžiam „Start test”. Jei viską padarėme teisingai, turėtume ten išvysti tai :D
Va, dabar jau galima ir paploti sau :D Ir imtis sekančio „iššūkio”.
Automatinis trečiųjų šalių „juodųjų sąrašų” atnaujinimas Pi-hole
Pi-hole turi net labai neprastą ~100-140 tūkst. domenų „juodąjį sąrašą” ir puikiai „susidoroja” su dauguma reklamų apraiškų elektroninėje erdvėje, tik… gyvename laikais, kai „užknisa juodai” ne tik reklama. Visai nenuostabu, kad yra ir daugybė kitokių sąrašų.
Ir kiekvienas gali pats nuspręsti, kuriuos jų naudoti, bet bėda yra ta, kad Pi-hole – iki kažkurios versijos – „nemokėjo” tokių sąrašų „atsinaujinti” ir „išmoko” tai visiškai neseniai.
Taigi, galime pridėti norimus sąrašus „rankutėmis”:
Atkreipkite dėmesį į komentarus prie kiekvieno sąrašo.
Arba galime tai padaryti „senoviškai” ir greičiau. Ir naudosime jacklul/pihole-updatelists ir jų rekomenduojamus sąrašus. Ir tam yra script’as, kuris beveik viską ir atliks.
Bet pirma pasiruošiame:
root@katukai:~# apt install php-cli php-sqlite3 php-intl php-curl
Tada parsisiunčiame ir paleidžiame diegimo script’ą:
root@katukai:~# wget -O - https://raw.githubusercontent.com/jacklul/pihole-updatelists/master/install.sh | bash
„Išjungiame” įprasto Pi-hole sąrašo atnaujinimą – tai nuo šiol darys pihole-updatelists:
root@katukai:~# sed -e '/pihole updateGravity/ s/^#*/#/' -i /etc/cron.d/pihole
Beje, rekomenduoju šią komandą kur nors išsisaugoti – deja, bet prireiks. Po kiekvieno Pi-hole atnaujinimo. Kas nėra labai dažnai, bet tenka „įsikišti”. „Rankutėmis”.
Atsidarome /etc/pihole-updatelists.conf:
root@katukai:~# nano /etc/pihole-updatelists.conf
Kiek pakoreguojame:
; Pi-hole's Lists Updater by Jack'lul ; https://github.com/jacklul/pihole-updatelists ; For a full list of available variables please see the readme. ; Remote list URL containing list of adlists to import ; URLs to single adlists are not supported here! ADLISTS_URL="https://v.firebog.net/hosts/lists.php?type=tick" ; Remote list URL containing exact domains to whitelist WHITELIST_URL="https://raw.githubusercontent.com/anudeepND/whitelist/master/domains/whitelist.txt" ; Remote list URL containing regex rules for whitelisting REGEX_WHITELIST_URL="" ; Remote list URL containing exact domains to blacklist ; This is specifically for handcrafted lists only, do not use regular blocklists here! BLACKLIST_URL="" ; Remote list URL containing regex rules for blacklisting REGEX_BLACKLIST_URL="https://raw.githubusercontent.com/mmotti/pihole-regex/master/regex.list"
Ir atnaujiname visus blokuojamų domenų sąrašus:
root@katukai:~# pihole-updatelists
Teks kiek palaukti, bet kai baigs, Pi-hole raudonajame stačiakampyje turėtume pamatyti kur kas didesnį skaičių:
Su Pi-hole – viskas. Grįšime dar prie jo, bet jau netiesiogiai. Kai rūpinsimės saugumu. Bet prieš tai – Wireguard ir Wireguard UI.
Wireguard
Wireguard nustatymais „pasirūpino” DietPi. Ir – net labai gerai. Bet mes jų generavimą ir įrašymą į wg0.conf patikėsime Wireguard UI, todėl… triname visą tai lauk :D
root@katukai:~# rm -rf /etc/wireguard/*
Dėl šios pačios priežasties IPv4 paketų nukreipimą turime „įjungti” patys:
root@katukai:~# nano /etc/sysctl.conf
Ir triname groteles prieš „net.ipv4.ip_forward=1”:
Ctrl + x, y, Enter – išsaugome ir – sysctl -p – turime pamatyti tą pačią eilutę:
root@katukai:~# sysctl -p net.ipv4.ip_forward = 1
Ir nors Wireguard UI įrašys pakeitimus į Wireguard wg0.conf, to nepakanka – pakeitimai „nesuveiks” tol, kol Wireguard nebus paleistas iš naujo. Kiekvieną kartą.
O mes – tinginiai – patikėsime tai gana „gudriam” systemd servisui iš dviejų dalių.
wg.path, kuris tikrins ar wg0.conf nepasikeitė:
root@katukai:~# nano /etc/systemd/system/wg.path
Kur įrašome ir išsaugome:
[Unit] Description=Watch /etc/wireguard/wg0.conf for changes [Path] PathModified=/etc/wireguard/wg0.conf [Install] WantedBy=multi-user.target
Ir wg.service, kuris perkraus Wireguard, jei wg0.conf pasikeitė:
root@katukai:~# nano /etc/systemd/system/wg.service
Kur išsaugome tai:
[Unit] Description=Restart WireGuard After=network.target [Service] Type=oneshot ExecStart=/usr/bin/systemctl restart [email protected] [Install] RequiredBy=wg.path
Žinoma, pasirūpiname, kad tai veiktų ir perkrovus mūsų žaislą:
root@katukai:~# systemctl enable wg.{path,service}
Created symlink /etc/systemd/system/multi-user.target.wants/wg.path → /etc/systemd/system/wg.path.
Created symlink /etc/systemd/system/wg.path.requires/wg.service → /etc/systemd/system/wg.service.
Ir – reboot. Nes systemctl start wg.{path,service} nesuveiks.
Wireguard UI
Laikomės įprastos tvarkos ir švaros sistemoje ir tokius – „nesisteminius” – dalykus laikome /opt:
root@katukai:~# cd /opt/
Būtinai patikriname, kuri Wireguard UI versija yra naujausia. Ir mums reikalinga būtent Linux ARM64 versija. Kopijuojame nuorodą ir parsisiunčiame:
root@katukai:/opt# wget https://github.com/ngoduykhanh/wireguard-ui/releases/download/v0.3.6/wireguard-ui-v0.3.6-linux-arm64.tar.gz
Išarchyvuojame:
root@katukai:/opt# tar -xf wireguard-ui-v0.3.6-linux-arm64.tar.gz
Ir nereikalingą archyvą ištriname:
root@katukai:/opt# rm wireguard-ui-v0.3.6-linux-arm64.tar.gz
O čia siūlau truputį „pristabdyti arklius” ir nepulti prie to išarchyvuoto wireguard-ui.
Visų pirma, mes ir nenorėtume jungtis ir „rankutėmis” jį paleidinėti kiekvieną kartą, jam „užstrigus” ar įjungus/perkrovus savo naują žaislą. Antra, Wireguard UI nustatymai išsaugomi būtent toje vietoje, iš kurios jis buvo paleistas, kas veda prie „kažkur dingo mano nustatymai” ir nereikalingo jų dubliavimo.
Kitaip tariant, mums reikia, kad Wireguard UI startuotų kartu su sistema; jam „užstrigus”, būtų paleistas iš naujo; ir tai visada turi vykti iš tos pačios vietos, pvz., ~/.
Ir tai – vėl – patikėsime systemd. Sukuriame wgui.service:
root@katukai:~# nano /etc/systemd/system/wgui.service
Ir Ctrl + Shift + v šias eilutes:
[Unit] Description=Run Wireguard UI After=network-online.target multi-user.target Wants=network-online.target [Service] WorkingDirectory=/root ExecStart=/opt/wireguard-ui Restart=on-failure [Install] WantedBy=multi-user.target
Ctrl + x, y, Enter – išsaugome ir:
root@katukai:~# systemctl enable wgui.service Created symlink /etc/systemd/system/multi-user.target.wants/wgui.service → /etc/systemd/system/wgui.service.
Nuo šiol Wireguard UI pasileis kartu su sistema ir – jei dėl kokių priežasčių nustotų veikti – sistema pabandys jį paleisti iš naujo. O kol kas paleidžiame taip:
root@katukai:~# systemctl start wgui.service
O dabar į naršyklės adreso laukelį įrašome savo žaislo IP, pridedame „:5000” – šiuo mano atveju tai yra 192.168.1.100:5000 – ir, štai jis, Wireguard UI:
Ir pirmas dalykas, ką dabar darome – „grįžtame” atgal į terminalą ir pakeičiame prisijungimo prie Wireguard UI duomenis:
root@katukai:~# nano ~/db/server/users.json
Va, dabar galime jungtis. Ir iškart renkamės „Global Settings”, kur:
- „Endpoint Address” – „Suggest” mygtuko pagalba ar sužinoję čia – įvedame savo išorinį IP adresą;
- „DNS Servers” – triname tą „1.1.1.1” ir pridedame savo žaislo IP adresą;
- kitų laukų neliečiame, nebent tikrai žinome, ką darome.
Nepamirštame „Save” ir „lendam” į „Wireguard Server”, kur į „Post Up Script” įrašome:
iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
O į „Post Down Script”:
iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
Kitų laukų – kol kas – neliečiame, bet, jei jau taip norisi, galime susigeneruoti kokius „-esnius” raktus :P
„Save”, „Wireguard Clients” ir – „New Client” – pridedame pirmąjį įrenginį:
„Apply Config” ir – jau terminale – įsitikiname, kad Wireguard UI visą tai išsaugojo wg0.conf, o systemd perkrovė Wireguard:
root@katukai:~# wg interface: wg0 public key: ji7Qy6nFZBoBTwr83gAJPnLCZkpbihygWRoknEl6/Fk= private key: (hidden) listening port: 51820 peer: 1cer0+fZGWKBfox2OIb7Y+L5BLdD8H1FSHq3aBC55wI= preshared key: (hidden) allowed ips: 10.252.1.1/32
Jei matome tiek – viskas veikia. Lokaliai. Ko, žinoma, maža. Todėl dar kartą „lendame” į maršrutizatorių ir „nukreipiame” UDP 51820 port’ą į savo žaislą:
Tai, priklausomai nuo gamintojo, gali gerokai skirtis. Jei nesame tikri, geriau klausiame „ančiukų”. Tik įrašome savo maršrutizatoriaus gamintojo pavadinimą.
Pasiruošiame savo pridėto įrenginio nustatymų QR kodo nuskaitymui:
Griebiame telefoną, susirandame ir įdiegiame jame Wireguard programėlę, paleidžiame ją ir skenuojame tą QR:
Ir jei dabar telefone išjungsime Wi-Fi, įjungsime mobilius duomenis ir „užsuksime” iš jo į manoip.lt, turėtume pamatyti ne kokį nors mobiliojo ryšio operatoriaus priskirtą IP adresą, o savo namų/įmonės išorinį IP adresą. O tai reiškia, kad viskas tikrai veikia. Tą patį turėtų „tvirtinti” ir wg terminale ar Wireguard UI „Status”.
Ir – nuo šiol – visiškai nesvarbu, kaip ir kur – mobilūs duomenys, viešas nesaugus Wi-Fi kokiame oro uoste, viešbutyje ar kavinėje – iš šio telefono jungsimės, iš tikro – šifruotu Wireguard VPN tuneliu – jungsimės prie savo vidinio tinklo; visas srautas „eis” per mūsų maršrutizatorių, mūsų Pi-hole ir mūsų Unbound DNS; o visus įrenginius – pradedant maršrutizatoriumi ir baigiant šiuo žaislu su Pi-hole ir Wireguard UI – pasieksime jau žinomais vidinio tinklo IP adresais:
Galime telefonui ir uždrausti jungtis ne per VPN – o jis, patikėkite, tikrai bandys tai daryti :D Mano telefono /e/OS tai atrodo štai taip:
Ir taip – tik vėliau, neskubame dar – su visais telefonais, planšetėmis ir kompiuteriais, kuriems tikrai reikalingas priėjimas prie vidinio tinklo įrenginių (pvz., NAS) iš išorės; reklamų – ir ne tik – blokavimas; ar, tiesiog, šifruotas tunelis, jungiantis prie potencialiai nesaugių Wi-Fi. Ir nesvarbu, ką naudojame – Windows, macOS, Linux ar dar ką – oficialioje Wireguard svetainėje rasime viską, ko reikia.
Beje, galime ištrinti – tiek iš Wireguard UI, tiek iš telefono – tą bandymą. Nes laikas aptarti kai ką svarbaus.
Saugumas
Nes saugumas – svarbu. Ypač, kai tai yra kažkas tokio, per ką „keliauja” visas namų ar įmonės duomenų srautas. Ir diskutuoti apie tai galėtume iki išsekimo.
Todėl padarykime paprasčiau – imame šį savo naują žaislą ir kritiškai peržvelgiame viską, ką su juo darėme; ir tik tada – kiekvienas sau, atsižvelgęs ir įvertinęs savo situaciją ir aplinkybes, – sprendžiame, kas ir kiek yra svarbu.
O tokiu, regis, nesvarbiu dalyku gali būti ir įrenginio pavadinimas tinkle (angl. hostname). Gal ir nėra svarbu, koks tas pavadinimas bus namų tinkle, bet didesniame ir dažniau kintančiame kokios organizacijos tinkle tai gali būti didelių nemalonumų pradžia.
Vis gi, paliktas pradinis „dietpi” iškart „išduoda” naudojamą OS ir kad tai – greičiausiai – mikrokompiuteris, kuris – nebūtinai, bet greičiausiai – yra Raspberry Pi. „pihole”, „dns” ar „vpn” išduoda paskirtį. „pi” ar „hole” – lengvai atspėjamos užuominos. O, va, „katukai” – prastas pavyzdys – be reikalo atkreipia dėmesį.
Bet tai nesunku pakeisti – dietpi-config › Security Options. Po keitimo – reboot.
Ko tiesiogiai „neišduoda” pavadinimas, netiesiogiai „išduoda” port’ai.
22-asis „išduoda” SSH, bet jo keitimas – kai įrenginys pasiekiamas tik vidiniame tinkle, o prie SSH leidžiama jungtis tik su raktais – būtų, ko gero, perteklinė saugumo priemonė. O kai kuriais atvejais geriau yra žinoti, kas ar iš kur ir kada bandė „kišti nagus”. O tai gali būti nebūtinai žmogus.
53-iasis „išduoda” DNS, o 5335-asis – jau netiesiogiai – Unbound, bet tai – normalu.
80-asis „išduoda” web serverį, kas taip pat būtų normalu, jei tik naršyklėje neišvystume „You should replace this page with your own web pages as soon as possible.”. Kas – šiuo mūsų atveju – yra labai neįprasta, todėl dar panagrinėsime atskirai.
Riboti priėjimą prie viso web serverio ar tik prie Pi-hole? Diskutuotina. O, štai, 5000-ojo port’o, „vedančio” į Wireguard UI virtualų web serverį, atveju – nediskutuotina.
4711-asis mums problemų nesukels, jei tik įsiskaitysime, ką apie jį rašo Pi-hole kūrėjai.
Todėl prie šių port’ų taip pat grįšime.
Su UDP 51820-uoju – kiek kitokia situacija – jis jau tiesiogiai siejamas su Wireguard. Ir „išduos” šį, skenuojant net tik mūsų žaislo IP adresą vidiniame tinkle, bet ir skenuojant mūsų išorinį IP adresą. Ir geriausia, ką mes galime padaryti – pakeisti jį. Nesunku, o ir jau žinome, kur – Wireguard UI › Wireguard Server ir maršrutizatoriuje.
O, štai, kokiu – jau įdomesnis klausimas.
Saugiausia – kad kažko „nesugriausime” – būtų keisti į skaičių nuo 49152 iki 65535, bet ne 51820. Geriausia būtų, jei tas skaičius, išvis, net nebūtų panašus. Gana saugu keisti ir į kažką tarp 1024 ir 49151, bet ne į 5335, kuris jau skirtas Unbound, ir ne į 4711, skirtą Pi-hole.
Galima naudoti ir kokį žinomesnį UDP port’ą ir bandyti „apsimesti” kitu įrenginiu ar servisu, kuriam reikalingas atviras port’as išorėje nesukeltų didesnių įtarimų. Ypač, jei tokį pat atvirą TCP port’ą, nesukeliant beveik jokių įtarimų, galima nukreipti į kokį izoliuotą virtualų web serverį, kuriame nieko nėra :D
Čia – pamąstymui. Nes galimų – paprastesnių ir saugesnių, tik šiek kiek kainuojančių – sprendimų yra ne vienas.
Esmė ta, kad kitų (ar, tiksliau, jokių laisvai prieinamų) port’ų nukreipimų iš išorės – jei tokių dar yra – neturėtų likti. Visiškai. Ir nesvarbu, kiek ir ko dar yra mūsų vidiniame tinkle – dabar tai galima pasiekti kur kas saugesniu šifruotu Wireguard tuneliu per vieną vienintelį port’ą. Net jei tai būtų kokie serveriai, besikeičiantys duomenimis su serveriais kituose tinkluose. Ar net – su serveriais globaliame tinkle.
Kad ir kam – serveriui ar žmogui – leistume prisijungti ir naudoti savą VPN, visada turėtume tiksliai numatyti, ką, kiek ir kaip jis vidiniame tinkle gali. Visi Wireguard klientai gauna atskirus IP adresus VPN potinklyje, o tai reiškia, kad kiekvieną jų galime identifikuoti ir valdyti.
Bet visa tai nepadės, jei prie tokio „žaislo” galima laisvai prieiti fiziškai. Juokai juokais, bet ištraukti maitinimo laidą, microSD kortelę ir įrašyti „papildomą” SSH raktą ir/ar nusikopijuoti wg0.conf daug laiko nereikia :D
O SSH raktai visada turėtų būti generuojami su slaptažodžiais. „Tingėjimas” kaskart įvesti slaptažodžius tėra dalis tiesos. Teks įvesti. *nix sistemose to reikės tik kartą per vartotojo prisijungimo prie kompiuterio sesiją – tam yra ssh-agent.
Ir – beveik kaip ir su slaptažodžiais – visur naudoti vieną ir tą patį SSH raktą būtų neatsakinga ir kvaila.
Programinės įrangos atnaujinimai ir nuolatinės rezervinės kopijos turėtų būti „savaime” suprantamais dalykais. Ir DietPi tai – daugiau ar mažiau – palengvina.
Tiek tos teorijos – laikas pamiklinti pirštus.
Lighttpd
Jei ne Pi-hole, šis vaizdas nebūtų toks jau neįprastas:
Nes Pi-hole, įprastai, pakeičia tai į savo index.php, o mes turėtume matyti tai:
Įtartina. Ir mūsų įtarimai pasitvirtina:
root@katukai:~# ls -la /var/www/ total 132 drwxr-xr-x 3 root root 4096 Apr 2 09:51 . drwxr-xr-x 12 root root 4096 Mar 11 15:36 .. lrwxrwxrwx 1 root root 19 Mar 18 00:48 admin -> /var/www/html/admin -rw-r--r-- 1 root root 38300 Mar 18 00:47 apc.php drwxr-xr-x 4 root root 4096 Mar 18 00:48 html -rw-r--r-- 1 root root 3388 Mar 11 15:37 index.lighttpd.html -rw-r--r-- 1 root root 71811 Mar 18 00:47 opcache.php -rw-r--r-- 1 root root 20 Mar 18 00:47 phpinfo.php lrwxrwxrwx 1 root root 20 Mar 18 00:48 pihole -> /var/www/html/pihole
DietPi „pasirūpino” web serverio, įskaitant PHP, konfigūracija ir galimybe visą tai mums peržiūrėti ir patikrinti. Ir galimybe – jei norėtume – panaudoti šį serverį dar kam nors, ne tik Pi-hole.
Verta atkreipti dėmesį į kiek neįprastą struktūrą – Pi-hole yra įdiegtas /var/www/html/admin ir į jį „veda” admin simbolinė nuoroda; o /var/www/html/pihole, į kurį „veda” pihole, „guli” ne kas kita, o tai, ką mes ir tikėjomės pamatyti naršyklėje – įprastas Pi-hole index.php su savo CSS. Kas yra puiki užuomina, ką daryti su tuo index.lighttpd.html.
O su apc.php, opcache.php ir phpinfo.php – vienas iš dviejų – arba galimybė pasiekti juos turi būti apribota, arba jų čia neturi būti. Ir geriausia, turbūt, būtų – ir jei kada ateityje prireiktų – sukurti kokį katalogą:
root@katukai:~# mkdir /opt/default-dietpi-lighttpd-www
Perkelti į jį iš /var/www viską, išskyrus html katalogą ir esančias admin ir pihole simbolines nuorodas:
root@katukai:~# mv /var/www/!(html|admin|pihole) /opt/default-dietpi-lighttpd-www/
Ir vietoje index.lighttpd.html sukurti nuorodą į įprastą Pi-hole index.php:
root@katukai:~# ln -s /var/www/html/pihole/index.php /var/www/
O didesnio įmonės vidinio tinklo atveju geriau bus sukurti tuščią index.html:
root@katukai:~# touch /var/www/index.html
Arba – nekurti nei vieno, nei kito. Tik nepamirštame rm /var/www/pihole ar mv /var/www/pihole /opt/default-dietpi-lighttpd-www/, jei nekursime simbolinės nuorodos į Pi-hole index.php.
To pakaks, kad dauguma Pi-hole nerastų :D
UFW
UFW tikrai toks ir yra – „Uncomplicated Firewall” :P
root@katukai:~# apt install ufw
Ir šiek tiek – nes IPv6 mums nereikalingas – pakoreguojame /etc/default/ufw:
root@katukai:~# nano /etc/default/ufw
„IPV6=yes” keisdami į „IPV6=no”:
# Set to yes to apply rules to support IPv6 (no means only IPv6 on loopback # accepted). You will need to 'disable' and then 'enable' the firewall for # the changes to take affect. IPV6=no
Ctrl + x, y, Enter – išsaugome ir… uždarome visus „įėjimus”:
root@katukai:~# ufw default deny Default incoming policy changed to 'deny'
O visus „išėjimus” – atidarome:
root@katukai:~# ufw default allow outgoing Default outgoing policy changed to 'allow'
Ir atidarome tik tuos „įėjimus”, kurie mums būtini. Ir pats pats „-iausias” jų – SSH:
root@katukai:~# ufw allow 22/tcp Rules updated
Žinoma, „22” tik tuo atveju, jei nekeitėme į ką kito.
DNS:
root@katukai:~# ufw allow 53
Unbound:
root@katukai:~# ufw allow 5335
Wireguard – „51820” tik tuo atveju, jei nusprendėme nekeisti:
root@katukai:~# ufw allow 51820/udp
Wireguard UI virtualų serverį leidžiame pasiekti tik iš tam tikro įrenginio (pvz., asmeninio kompiuterio) IP adreso vidiniame tinkle:
root@katukai:~# ufw allow from 192.168.1.110 to any proto tcp port 5000
Taip galime leisti Wireguard UI pasiekti ir kitiems įrenginiams. Svarbiausia, kad tokių įrenginių IP adresai vidiniame tinkle būtų susieti su tų įrenginių MAC adresais. Nežinantiems, kas tai ir kaip – „ančiukų” atsakymai, tik įrašome savo maršrutizatoriaus gamintoją.
Lygiai taip pat galime riboti priėjimą ir prie Lighttpd:
root@katukai:~# ufw allow from 192.168.1.110 to any proto tcp port 80
Bet jei dėl kokių priežasčių norime, kad Lighttpd būtų pasiekiamas visiems, o Pi-hole – tik „išrinktiesiems”:
root@katukai:~# ufw allow 80/tcp
O tada:
root@katukai:~# nano /etc/lighttpd/conf-enabled/99-dietpi-pihole-block_public_admin.conf
Ir pakoreguojame tai, ką ten randame :D
# Block non-LAN access to Pi-hole admin panel
$HTTP["url"] =~ "^(/html)?/admin(/|$)" {
$HTTP["remoteip"] !~ "^(1(27|92\.168|0|72\.(1[6-9]|2[0-9]|3[0-1]))\.|::1|fe[89ab].:|f[cd]..:)" {
url.access-deny = ("")
}
}
O jei rimtai, štai – kiek „patobulintas” variantas su keliais pavyzdžiais:
# Block non-LAN access to Pi-hole admin panel
$HTTP["url"] =~ "^(/html)?/(admin|pihole)(/|$)" {
# $HTTP["remoteip"] !~ "^(1(27|92\.168|0|72\.(1[6-9]|2[0-9]|3[0-1]))\.|::1|fe[89ab].:|f[cd]..:)" {
# $HTTP["remoteip"] !~ "192.168.1.110" {
# $HTTP["remoteip"] !~ "192.168.1.110|192.168.1.120" {
# $HTTP["remoteip"] !~ "^(192\.168\.1\.110|120)$" {
url.access-deny = ("")
}
}
Išsirenkame tą vieną, kuris mums „-esnis”, pašaliname groteles priekyje, keičiame IP į savą, išsaugome ir perkrauname Lighttpd:
root@katukai:~# service lighttpd restart
Liko dar vienas port’as, kuris vertas atskiro mūsų dėmesio. Nes absoliuti dauguma, rašančių apie Pi-hole diegimą, ignoruoja tai, ką rašo Pi-hole kūrėjai:
„FTL is our API engine and uses port 4711 on the localhost interface. This port should not be accessible from any other interface.”.
Taigi, ufw allow 4711/tcp – blogai. Ir turėtų būti:
root@katukai:~# ufw allow proto tcp from 127.0.0.1 to 127.0.0.1 port 4711
Ir aktyvuojame visą tai:
root@katukai:~# ufw enable Firewall is active and enabled on system startup
Va, o jei matome „Connection to 192.168.x.x closed.” ir nebegalime prisijungti… :D
O, šiaip, jei ką „suveltume”:
root@katukai:~# ufw status numbered Status: active To Action From -- ------ ---- [ 1] 22/tcp ALLOW IN Anywhere [ 2] 53 ALLOW IN Anywhere [ 3] 5335 ALLOW IN Anywhere [ 4] 51820/udp ALLOW IN Anywhere [ 5] 5000/tcp ALLOW IN 192.168.1.110 [ 6] 80/tcp ALLOW IN 192.168.1.110 [ 7] 127.0.0.1 4711/tcp ALLOW IN 127.0.0.1
Ir:
root@katukai:~# ufw delete n
Kur n > 1 :D
Nesakykite, kad neperspėjau :D
Fail2ban
O Fail2ban konfigūracija – ir vėl – „pasirūpino” DietPi, bet yra šis tas, ką turėtume padaryti. Visų pirma, apsisaugome nuo galimo pakeitimų, kuriuos atliksime mes, „dingimo”:
root@katukai:~# cp /etc/fail2ban/jail.{conf,local}
Kas, beje, yra tas pats, kas ir:
root@katukai:~# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Atsidarome tą jail.local:
root@katukai:~# nano /etc/fail2ban/jail.local
Ir pakoreguojame šiek tiek laikus:
[DEFAULT] enabled = true ignoreip = 127.0.0.1/8 ignorecommand = backend = systemd mode = normal filter = %(__name__)s[mode=%(mode)s] findtime = 3600 maxretry = 3 bantime = 86400 banaction = route action = %(banaction)s[blocktype=blackhole] [dropbear] [sshd] # Mode: normal (default), ddos, extra or aggressive (combines all) # See "filter.d/sshd.conf" for details. #mode = normal
Kas mūsų atveju reikš „Trys klaidingi bandymai jungtis prie sshd/dropbear per valandą – ban’as parai.”.
Tą patį reikš ir:
[DEFAULT] findtime = 3600 bantime = 86400
Fail2ban veiks taip, kaip tai aprašyta jail.conf, bet su mūsų „patikslinimais” jail.local. Patogu, o mūsų pakeitimai niekur „nedings”, jei – atnaujinant Fail2ban ar įdiegiant ką – DietPi perrašytų jail.conf.
Nepamirštame tik:
root@katukai:~# service fail2ban restart
O jei prireiktų kokį IP atblokuoti anksčiau laiko:
root@katukai:~# fail2ban-client set dropbear unbanip 192.168.x.x
Rezervinės kopijos
Ir kai viskas jau įdiegta, sukonfigūruota ir išbandyta, protinga būtų pasirūpinti rezervinėmis kopijomis. Yra du būdai, jie – labai skirtingi, bet puikiai papildo vienas kitą.
Pirmasis būdas – visos microSD kortelės kopija. Išjungiame savo žaislą:
root@katukai:~# shutdown now
Ištraukiame kortelę, kišame ją į microSD USB adapterį, o šį – į kompiuterį. Tiems, kurie ilgai žiūri į langus (ir langai ima žiūrėti į juos), užteks įsidiegti Win32 Disk Imager, o visi kiti „lenda” į terminalą ir:
marijus@marijus:~$ df
macOS vartotojai turėtų atpažinti kortelę kaip /dev/rdisk2, o Linux – kaip /dev/sda. Pavadinimai gali būti ir kiek kitokie, todėl būtinai įsitikiname, kad atpažinome teisingai, ir tik tada:
marijus@marijus:~$ sudo dd bs=4M if=/dev/sda of=katukai-backup-220411.img conv=fsync 7454+1 records in 7454+1 records out 31267487744 bytes (31 GB, 29 GiB) copied, 1615.15 s, 19.4 MB/s
Žinoma, vietoj „katukai-backup-220411” įrašome ką nors kur kas „-esnio” :P
Tai – gali tekti ilgokai palaukti – sukurs idealią microSD kortelės kopiją kompiuteryje. Bėda tik su tokiomis idealiomis kopijomis – jos užima tiek pat vietos, kokio dydžio yra kortelės :D Bet tai bėdai yra PiShrink:
marijus@marijus:~$ wget https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh marijus@marijus:~$ chmod +x pishrink.sh marijus@marijus:~$ sudo mv pishrink.sh /usr/local/bin
Ir:
marijus@marijus:~$ sudo pishrink.sh katukai-backup-220411.img pishrink.sh v0.1.2 pishrink.sh: Gathering data ... pishrink.sh: Checking filesystem ... /dev/loop0: 26123/1893120 files (0.3% non-contiguous), 405280/7599872 blocks resize2fs 1.46.3 (27-Jul-2021) pishrink.sh: Shrinking filesystem ... resize2fs 1.46.3 (27-Jul-2021) Resizing the filesystem on /dev/loop0 to 446926 (4k) blocks. Begin pass 2 (max = 86745) Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Begin pass 3 (max = 232) Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Begin pass 4 (max = 2828) Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX The filesystem on /dev/loop0 is now 446926 (4k) blocks long. pishrink.sh: Shrinking image ... pishrink.sh: Shrunk katukai-backup-220411.img from 30G to 1.9G ...
O jei norime, kad ši kopija būtų „prieinama” ir mūsų „kasdieniam” vartotojui, pakeičiame teises. Mano atveju:
marijus@marijus:~# sudo chown marijus katukai-backup-220411.img
Tokią kopiją užtektų pasidaryti kartą per pusę metų ar net metus, o dažnesnes kopijas tegul – jau kitu būdu – daro pats DietPi:
root@katukai:~# dietpi-launcher
Ir turėtume pamatyti – jei nematę – dar kai ką labai įdomaus:
Kur galime:
Ir:
Paprasta!