Iptables ja rikkalike ning laiskade dissidentide liiklusfiltreerimine

Keelatud ressursside külastamise blokeerimise asjakohasus puudutab iga administraatorit, kellele võivad ametlikult esitada seaduse või vastavate organite korralduste täitmata jätmise eest süüdistuse.

Miks leiutada jalgratast, kui meil on juba spetsialiseeritud programmid ja distributsioonid meie ülesannete jaoks, näiteks: Zeroshell, pfSense, ClearOS.

Veel üks küsimus tekkis ülemusel: Kas kasutataval tootel on meie riigi turvasertifikaat?

Meil on olnud kogemusi nimetatud distributsioonidega:

• Zeroshell — arendajad isegi kinkisid 2 aastaks litsentsi, kuid selgus, et meie jaoks kriitilise funktsiooni täitmine ei olnud selle distributsiooni puhul mõistlik;
• pfSense — austus ja au, samas igav, harjumine FreeBSD tulemüüri käsureaga ja ei ole meile piisavalt mugav (arvan, et harjumise küsimus, aga see osutus mitte 'õige teeks');
• ClearOS — meie riistvara peal osutus see väga aeglaseks, tõsiste katsetusteni ei jõudnud, miks on sellised rasked liidest?
• Ideco SELECTA. Toote "Aideco" kohta on eraldi jutt, huvitav toode, kuid poliitilistel põhjustel mitte meie jaoks, ja tahaksin samuti "hamustada" neid Linuxi, Roundcube jne litsentsi küsimuses. Kust nad võtsid, et "puurides" liidese Python ja eemaldades superkasutaja õigused, saavad nad müüa lõpp-produkti, mis on koosnenud internetiühiskonna arendatud ja täiustatud moodulitest, mis levivad GPL&jne.

Mõistan, et nüüd hakkavad mu suunas sadama negatiivsed arvamused koos nõudmistega õigustada oma subjektiivseid tundeid, kuid tahan öelda, et see võrgu sõlm on samuti liikluse tasakaalustaja neljale välisele kanalile internetti, kus igal kanalil on oma eripära. Veel üheks nurgakiviks oli vajadus, et üks mitmest võrguliidesest töötaks erinevates aadressiruumides, ja ma olen valmis tunnistama, et ei ole valmis VLANe igal pool rakendama, kus vaja ja kus ei ole. Kasutuses on seadmed nagu TP-Link TL-R480T+ — nende käitumine ei ole ideaalne, üldiselt omade nüanssidega. Seda osa oli Linuxil mõistlikult seadistada tänu Ubuntu ametlikule veebilehele.IP-Balansseerimine: ühendame mitu interneti kanalit üheks. IP-Balansseerimine: ühendame mitu interneti kanalit üheks.. Iga kanaleid võib igal ajal "langetada", nagu ka tõsta. Kui teid huvitab skript, mis praegu töötab (ja sellest tasub eraldi postitus) — kirjutage kommentaarides.

Käsitletav lahendus ei pretendeeri ainulaadsusele, kuid sooviksin esitada küsimuse: "Miks peaks ettevõttes kohanema kahtlaste kolmandate osapoolte toodetega, millel on tõsised riistvaranõuded, kui saab kaaluda alternatiivset varianti?".

Kui Venemaal on Roskomnadzori nimekiri, siis Ukrainas — rakendus Riigi Julgeolekunõukogu otsusele (näiteks. siin on), siis kohaliku tasandi juhid ka ei maga. Näiteks anti meile üle nimekiri keelatud veebisaitidest, mis, juhtkonna arvates, halvendavad töö efektiivsust.

Suheldes kolleegidega teistes ettevõtetes, kus on vaikimisi keelatud kõik saidid ja ainult ülemuse loal on võimalik konkreetse saidi juurde pääseda, arutlesime ning mõistsime, et elu on siiski ilus ja alustasime oma otsingutele.

Olles suuteline mitte ainult analüütiliselt vaatama, mida kirjutatakse "koduperenaiste raamatutes" liikluse filtreerimise kohta, vaid ka jälgima, mis toimub erinevate teenusepakkujate kanalites, märkisime järgmised retseptid (kõik ekraanikuud on natuke kärbitud, palun mõistke):

Teenusepakkuja 1
— ei muretse ja pealeseb oma DNS-serverid ja läbipaistva proksi-serveri. Mis siis?.. kuid meil on ju juurdepääs sinna, kuhu on vaja (kui see meile vajalik on :))

Teenusepakkuja 2
— arvab, et tema ülemine teenusepakkuja peaks selle eest hoolitsema, isegi ülemise teenusepakkuja tehniline tugi tunnustas, miks ma ei saa avada vajalikku, mitte keelatud saiti. Arvan, et pilt paneb teid naerma 🙂

Selgus, et nad tõlgivad keelatud saitide nimed IP-aadressideks ja blokeerivad just IP-d (neid ei huvita, et sellel IP-aadressil võib olla 20 saiti).

Teenusepakkuja 3
— laseb liikluse sinna, kuid tagasi mööda marsruuti ei lase.

Teenusepakkuja 4
— keelab kõik pakettide manipulatsioonid näidatud suunas.

Ja mida teha VPN-iga (Opera brauserile austus) ja brauseri pluginatega? Mängides alguses Mikrotik node'iga, tekkis meil isegi ressursimahukas L7 retsept, millest pidime hiljem loobuma (keelatud nimesid võib olla rohkem, kahju on, kui peale oma otseste ülesannete marsruutide, CPU PPC460GT koormus ulatub 100% peale kolme kümne väljendi).

.

Selgeks sai:
DNS 127.0.0.1 ei ole absoluutne lahendus, tänapäeva brauserite versioonid võimaldavad tõepoolest selliseid probleeme vältida. Kõiki kasutajaid ei saa piirata vähendatud õigustega ning ei tohi unustada, et alternatiivsete DNS-ide hulk on tohutu. Internet ei ole staatiline ja peale uute DNS-aadresside ostavad keelatud saidid uusi aadresse, muudavad tippdomeene, võivad oma aadressis märkmeid lisada/ära kustutada. Kuid siiski on õigust elada midagi sellist:

ip route add blackhole 1.2.3.4

IP-aadresside nimekirja saamine keelatud saitide loendist oleks täiesti tõhus, kuid eespool nimetatud kaalutlustel läksime Iptables'iga arutlemisse. Keskmes oli juba töötav tasakaalustaja CentOS Linuxi versioonil 7.5.1804.

Kasutaja internet peab olema kiire ja brauser ei tohi oodata pool minutit, järeldades, et see leht ei ole saadaval. Pikkade otsingute järel jõudsime sellise mudelini:
Fail 1 -> /script/denied_host, keelatud nimede nimekiri:

test.test
blablabla.bubu
torrent
porno

Fail 2 -> /script/denied_range, keelatud adresseerimise ruumide ja aadresside nimekiri:

192.168.111.0/24
241.242.0.0/16

Fail-skript 3 -> ipt.sh, mis tegeleb iptables'ega:

# считываем полезную информацию из перечней файлов
HOSTS=`cat /script/denied_host | grep -v '^#'`
RANGE=`cat /script/denied_range | grep -v '^#'`
echo "Stopping firewall and allowing everyone..."
# сбрасываем все настройки iptables, разрешая то что не запрещено
sudo iptables -F
sudo iptables -X
sudo iptables -t nat -F
sudo iptables -t nat -X
sudo iptables -t mangle -F
sudo iptables -t mangle -X
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT
#решаем обновить информацию о маршрутах (особенность нашей архитектуры)
sudo sh rout.sh
# циклически обрабатывая каждую строку файла применяем правило блокировки строки
for i in $HOSTS; do
sudo iptables -I FORWARD -m string --string $i --algo bm --from 1 --to 600 -p tcp -j REJECT --reject-with tcp-reset;
sudo iptables -I FORWARD -m string --string $i --algo bm --from 1 --to 600 -p udp -j DROP;
done
# циклически обрабатывая каждую строку файла применяем правило блокировки адреса
for i in $RANGE; do
sudo iptables -I FORWARD -p UDP -d $i -j DROP;
sudo iptables -I FORWARD -p TCP  -d $i -j REJECT --reject-with tcp-reset;
done

Sudo kasutamine on tingitud sellest, et meil on väike häkk, et hallata läbi WEB-interfääsi, kuid nagu näitas selle mudeli kasutamine rohkem kui aasta jooksul, pole WEB nii vajalik. Pärast rakendamist oli soov tõsta veebisaitide loend andmebaasi ja nii edasi. Blokeeritud hostide hulk on üle 250 + kümme adresseerimise ruumi. Tõepoolest on probleem HTTPS-ühendusega saidile minekul, nagu süsteemiadministraatoril on mul brauserite osas pretensioone :), kuid need on erijuhud, enamus juhtub ikkagi meie poolel, samuti blokime edukalt Opera VPN-i, friGate tüüpi pluginaid ja Microsofti telemeetriat.

Allikas: habr.com