Iptables og filtrering af trafik fra fattige og dovne dissidenter

Relevansen af ​​at blokere besøg på forbudte ressourcer påvirker enhver administrator, som kan blive officielt sigtet for manglende overholdelse af loven eller ordrer fra de relevante myndigheder.

Iptables og filtrering af trafik fra fattige og dovne dissidenter

Hvorfor genopfinde hjulet, når der er specialiserede programmer og distributioner til vores opgaver, for eksempel: Zeroshell, pfSense, ClearOS.

Ledelsen havde et andet spørgsmål: Har det anvendte produkt et sikkerhedscertifikat fra vores stat?

Vi havde erfaring med at arbejde med følgende distributioner:

  • Zeroshell - udviklerne donerede endda en 2-årig licens, men det viste sig, at det distributionssæt, vi var interesseret i, ulogisk nok udførte en kritisk funktion for os;
  • pfSense - respekt og ære, på samme tid kedeligt, at vænne sig til kommandolinjen i FreeBSD-firewallen og ikke praktisk nok for os (jeg tror, ​​det er et spørgsmål om vane, men det viste sig at være den forkerte måde);
  • ClearOS - på vores hardware viste det sig at være meget langsomt, vi kunne ikke komme til seriøs test, så hvorfor så tunge grænseflader?
  • Ideco SELECTA. Ideco-produktet er en separat samtale, et interessant produkt, men af ​​politiske årsager ikke for os, og jeg vil også gerne "bide" dem om licensen til den samme Linux, Roundcube osv. Hvor fik de den idé, at ved at skære grænsefladen ind Python og ved at fratage superbrugerrettigheder, kan de sælge et færdigt produkt, der består af udviklede og modificerede moduler fra internetfællesskabet distribueret under GPL&osv.

Jeg forstår, at nu vil negative udråb strømme i min retning med krav om at underbygge mine subjektive følelser i detaljer, men jeg vil sige, at denne netværksknude også er en trafikbalancer for 4 eksterne kanaler til internettet, og hver kanal har sine egne karakteristika . En anden hjørnesten var behovet for en af ​​flere netværksgrænseflader til at fungere i forskellige adresserum, og jeg klar indrøm, at VLAN'er kan bruges overalt, hvor det er nødvendigt og ikke nødvendigt ikke klar. Der er enheder i brug som TP-Link TL-R480T+ - de opfører sig generelt ikke perfekt med deres egne nuancer. Det var muligt at konfigurere denne del på Linux takket være Ubuntus officielle hjemmeside IP-balancering: kombination af flere internetkanaler til én. Desuden kan hver af kanalerne "falde" til enhver tid såvel som stige. Hvis du er interesseret i et manuskript, der fungerer i øjeblikket (og dette er en separat publikation værd), så skriv i kommentarerne.

Den løsning, der overvejes, hævder ikke at være unik, men jeg vil gerne stille spørgsmålet: "Hvorfor skal en virksomhed tilpasse sig tvivlsomme tredjepartsprodukter med alvorlige hardwarekrav, når en alternativ mulighed kan overvejes?"

Hvis der i Den Russiske Føderation er en liste over Roskomnadzor, er der i Ukraine et bilag til afgørelsen fra det nationale sikkerhedsråd (f. her), så sover lokale ledere heller ikke. For eksempel fik vi en liste over forbudte steder, der efter ledelsens mening forringer produktiviteten på arbejdspladsen.

Kommunikation med kolleger på andre virksomheder, hvor som standard alle websteder er forbudt, og kun efter anmodning med tilladelse fra chefen kan du få adgang til et bestemt websted, smilende respektfuldt, tænker og "ryger over problemet", kom vi til den forståelse, at livet er stadig god, og vi startede deres søgning.

Da vi ikke kun havde mulighed for analytisk at se, hvad de skriver i "husmødrebøgerne" om trafikfiltrering, men også for at se, hvad der sker på forskellige udbyderes kanaler, bemærkede vi følgende opskrifter (enhver skærmbillede er lidt beskåret, tak forstå, når du spørger):

Udbyder 1
- gider ikke og pålægger sine egne DNS-servere og en gennemsigtig proxyserver. Nå?.. men vi har adgang til, hvor vi har brug for det (hvis vi har brug for det :))

Udbyder 2
- mener, at hans topudbyder burde tænke over dette, topudbyderens tekniske support indrømmede endda, hvorfor jeg ikke kunne åbne det websted, jeg havde brug for, hvilket ikke var forbudt. Jeg tror, ​​billedet vil more dig :)

Iptables og filtrering af trafik fra fattige og dovne dissidenter

Som det viste sig, oversætter de navnene på forbudte websteder til IP-adresser og blokerer selve IP'en (de er ikke generet af, at denne IP-adresse kan være vært for 20 websteder).

Udbyder 3
— tillader trafik at gå dertil, men tillader den ikke tilbage langs ruten.

Udbyder 4
— forbyder enhver manipulation med pakker i den specificerede retning.

Hvad skal man gøre med VPN (respekt for Opera-browseren) og browser-plugins? Ved at lege med noden Mikrotik i starten fik vi endda en ressourcekrævende opskrift på L7, som vi senere måtte opgive (der kan være flere forbudte navne, det bliver trist, når det ud over dets direkte ansvar for ruter, på 3 dusin udtryk går PPC460GT-processorbelastningen til 100 %).

Iptables og filtrering af trafik fra fattige og dovne dissidenter.

Hvad blev klart:
DNS på 127.0.0.1 er absolut ikke et vidundermiddel; moderne versioner af browsere giver dig stadig mulighed for at omgå sådanne problemer. Det er umuligt at begrænse alle brugere til reducerede rettigheder, og vi må ikke glemme det enorme antal alternative DNS. Internettet er ikke statisk, og udover nye DNS-adresser køber forbudte websteder nye adresser, ændrer topdomæner og kan tilføje/fjerne et tegn i deres adresse. Men har stadig ret til at leve noget som:

ip route add blackhole 1.2.3.4

Det ville være ret effektivt at få en liste over IP-adresser fra listen over forbudte websteder, men af ​​ovennævnte årsager gik vi videre til overvejelser om Iptables. Der var allerede en live balancer på CentOS Linux udgivelse 7.5.1804.

Brugerens internet skal være hurtigt, og browseren bør ikke vente et halvt minut og konkluderer, at denne side ikke er tilgængelig. Efter en lang søgen kom vi frem til denne model:
Fil 1 -> /script/denied_host, liste over forbudte navne:

test.test
blablabla.bubu
torrent
porno

Fil 2 -> /script/denied_range, liste over forbudte adresserum og adresser:

192.168.111.0/24
241.242.0.0/16

Script fil 3 -> ipt.shgør jobbet med 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

Brugen af ​​sudo skyldes, at vi har et lille hack til at administrere via WEB-grænsefladen, men som erfaring med at bruge en sådan model i mere end et år har vist, er WEB ikke så nødvendigt. Efter implementering var der et ønske om at tilføje en liste over websteder til databasen mv. Antallet af blokerede værter er mere end 250 + et dusin adresserum. Der er virkelig et problem, når man går til et websted via en https-forbindelse, som systemadministratoren, jeg har klager over browsere :), men disse er specielle tilfælde, de fleste af triggerne for manglende adgang til ressourcen er stadig på vores side , blokerer vi også Opera VPN og plugins som friGate og telemetri fra Microsoft.

Iptables og filtrering af trafik fra fattige og dovne dissidenter

Kilde: www.habr.com

Tilføj en kommentar