Iptables i filtració de trànsit de dissidents pobres i mandrosos

La rellevància del bloqueig de visites a recursos prohibits afecta qualsevol administrador que pugui ser acusat oficialment d'incompliment de la llei o les ordres de les autoritats corresponents.

Per què reinventar la roda quan hi ha programes i distribucions especialitzades per a les nostres tasques, per exemple: Zeroshell, pfSense, ClearOS.

La direcció tenia una altra pregunta: el producte utilitzat té un certificat de seguretat del nostre estat?

Teníem experiència treballant amb les següents distribucions:

• Zeroshell: els desenvolupadors fins i tot van donar una llicència de 2 anys, però va resultar que el kit de distribució que ens interessava, il·lògicament, realitzava una funció crítica per a nosaltres;
• pfSense: respecte i honor, alhora que avorrit, acostumant-nos a la línia d'ordres del tallafoc FreeBSD i no prou convenient per a nosaltres (crec que és una qüestió d'hàbit, però va resultar ser el camí equivocat);
• ClearOS: al nostre maquinari va resultar molt lent, no vam poder fer proves serioses, així que per què interfícies tan pesades?
• Ideco SELECTA. El producte Ideco és una conversa a part, un producte interessant, però per motius polítics no per a nosaltres, i també els vull “mossegar” sobre la llicència del mateix Linux, Roundcube, etc. D'on van treure la idea que tallant la interfície Pitó i en retirar els drets de superusuari, poden vendre un producte acabat format per mòduls desenvolupats i modificats de la comunitat d'Internet distribuïts sota GPL&etc.

Entenc que ara s'abocaran exclamacions negatives en la meva direcció amb demandes per justificar els meus sentiments subjectius en detall, però vull dir que aquest node de xarxa també és un equilibrador de trànsit per a 4 canals externs a Internet, i cada canal té les seves pròpies característiques. . Una altra pedra angular va ser la necessitat que una de les diverses interfícies de xarxa funcionés en diferents espais d'adreces, i jo llest admetre que les VLAN es poden utilitzar a tot arreu quan sigui necessari i no necessari no està llest. Hi ha dispositius en ús com ara TP-Link TL-R480T+: no es comporten perfectament, en general, amb els seus propis matisos. Va ser possible configurar aquesta part a Linux gràcies al lloc web oficial d'Ubuntu Equilibri d'IP: combinació de diversos canals d'Internet en un sol. A més, cadascun dels canals pot "caure" en qualsevol moment, així com pujar. Si esteu interessats en un guió que funcioni actualment (i val la pena publicar-lo per separat), escriviu als comentaris.

La solució en qüestió no pretén ser única, però m'agradaria fer la pregunta: "Per què una empresa s'ha d'adaptar a productes dubtosos de tercers amb requisits de maquinari greus quan es pot considerar una opció alternativa?"

Si a la Federació Russa hi ha una llista de Roskomnadzor, a Ucraïna hi ha un annex a la Decisió del Consell de Seguretat Nacional (per exemple. aquí), llavors els líders locals tampoc dormen. Per exemple, ens van donar una llista de llocs prohibits que, segons l'opinió de la direcció, perjudiquen la productivitat en el lloc de treball.

Comunicar-nos amb companys d'altres empreses, on per defecte tots els llocs estan prohibits i només a petició amb el permís del cap es pot accedir a un lloc específic, somrient respectuosament, pensant i "fumant sobre el problema", vam arribar a entendre que la vida encara està bé i vam començar la seva recerca.

Tenint l'oportunitat no només de veure analíticament el que escriuen als "llibres de mestresses de casa" sobre el filtratge de trànsit, sinó també de veure què passa als canals de diferents proveïdors, vam observar les receptes següents (qualsevol captura de pantalla està una mica retallada, si us plau). entendre quan pregunta):

Proveïdor 1
— no es molesta i imposa els seus propis servidors DNS i un servidor intermediari transparent. Bé?.. però tenim accés on ho necessitem (si ho necessitem :))

Proveïdor 2
- creu que el seu principal proveïdor hauria de pensar en això, el suport tècnic del principal proveïdor fins i tot va admetre per què no podia obrir el lloc que necessitava, cosa que no estava prohibida. Crec que la imatge us divertirà :)

Com va resultar, tradueixen els noms dels llocs prohibits a adreces IP i bloquegen la pròpia IP (no els molesta el fet que aquesta adreça IP pugui allotjar 20 llocs).

Proveïdor 3
— permet que el trànsit hi vagi, però no el permet tornar pel recorregut.

Proveïdor 4
— prohibeix totes les manipulacions amb paquets en la direcció especificada.

Què fer amb la VPN (respecte al navegador Opera) i els connectors del navegador? Jugant amb el node Mikrotik al principi, fins i tot vam aconseguir una recepta intensiva en recursos per a L7, que després vam haver d'abandonar (pot haver-hi més noms prohibits, es fa trist quan, a més de les seves responsabilitats directes per a rutes, en 3 dotzenes). expressions que la càrrega del processador PPC460GT arriba al 100 %).

.

Què va quedar clar:
DNS a 127.0.0.1 no és absolutament una panacea; les versions modernes dels navegadors encara us permeten evitar aquests problemes. És impossible limitar tots els usuaris a drets reduïts, i no hem d'oblidar-nos de la gran quantitat de DNS alternatius. Internet no és estàtica i, a més de les noves adreces DNS, els llocs prohibits compren noves adreces, canvien els dominis de primer nivell i poden afegir/eliminar un caràcter a la seva adreça. Però encara té dret a viure alguna cosa com:

ip route add blackhole 1.2.3.4

Seria força efectiu obtenir una llista d'adreces IP de la llista de llocs prohibits, però per les raons exposades anteriorment, vam passar a consideracions sobre Iptables. Ja hi havia un equilibrador en directe a la versió 7.5.1804 de CentOS Linux.

Internet de l'usuari ha de ser ràpid, i el navegador no ha d'esperar ni mig minut, arribant a la conclusió que aquesta pàgina no està disponible. Després d'una llarga recerca vam arribar a aquest model:
Fitxer 1 -> /script/host_denegat, llista de noms prohibits:

test.test
blablabla.bubu
torrent
porno

Fitxer 2 -> /script/interval_denegat, llista d'espais d'adreces i adreces prohibides:

192.168.111.0/24
241.242.0.0/16

Fitxer d'script 3 -> ipt.shfent la feina amb ipables:

# считываем полезную информацию из перечней файлов
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

L'ús de sudo es deu al fet que tenim un petit hack per gestionar mitjançant la interfície WEB, però com ha demostrat l'experiència en l'ús d'aquest model durant més d'un any, WEB no és tan necessari. Després de la implementació, es va voler afegir una llista de llocs a la base de dades, etc. El nombre d'amfitrions bloquejats és de més de 250 + una dotzena d'espais d'adreces. Realment hi ha un problema en anar a un lloc mitjançant una connexió https, com l'administrador del sistema, tinc queixes sobre els navegadors :), però aquests són casos especials, la majoria dels desencadenants de la manca d'accés al recurs encara estan al nostre costat , també bloquegem amb èxit Opera VPN i complements com friGate i telemetria de Microsoft.

Font: www.habr.com