Iptables és a forgalom szűrése a szegények és lusták másként gondolkodók ellen

A blokkolás jelentősége, amely megakadályozza a tiltott források látogatását, minden adminisztrátort érint, akikkel hivatalosan eljárhatnak a jogszabályok vagy a megfelelő hatóságok előírásainak be nem tartásáért.

Miért találjunk fel újra a kereket, amikor már léteznek speciális programok és disztribúciók a feladatainkhoz, például: Zeroshell, pfSense, ClearOS.

Még egy kérdést tettek fel a főnökség részéről: Van-e az általunk használt terméknek biztonsági tanúsítványa az államunkban?

Van tapasztalatunk az említett disztribúciókkal:

• Zeroshell - a fejlesztők még két évre ingyenes licencet is adtak, de kiderült, hogy a számunkra érdekes disztribúció érthetetlen módon alapvető funkciót látott el számunkra;
• pfSense - tisztelet és megbecsülés, ugyanakkor unalmas, a FreeBSD tűzfal parancssorához való hozzászokás, és nem elég kényelmes számunkra (gondolom, a megszokás dolga, de ez nem vezetett a megfelelő megoldásra);
• ClearOS - a mi hardverünkkel nagyon lassú volt, és nem jutottunk el komoly tesztelésig, szóval miért vannak ilyen nehéz felületek?
• Ideco SELECTA. Az "Ajdeko" termékről külön beszélgetés van, érdekes termék, de politikai okokból nem nekünk való, és még mindig szeretnénk "megcselezni" őket a Linux, Roundcube stb. licencével kapcsolatban. Honnan tudják, hogy a felület leválasztásával Python és a szuperfelhasználói jogok elvonásával egy készterméket adhatnak el, amely az internete közössége által kifejlesztett és továbbfejlesztett modulokból áll, amelyek GPL & egyebek szerint terjesztettek?

Megértem, hogy most negatív megjegyzések zúdulnak rám azzal a kéréssel, hogy részletesen indokoljam szubjektív érzéseimet, de szeretném elmondani, hogy ez a hálózati csomópont egyben forgalomelosztó négy külső csatornára az internethez, mindegyik csatornával saját sajátosságokkal rendelkezik. Az is kulcsfontosságú lett, hogy az egyik több hálózati interfész más címzési térben működjön, és én kész vagyok elismerni, hogy a VLAN-ok alkalmazása mindenütt, ahol szükséges és nem szükséges, nem áll készen nem állok készen. Az használatunkban lévő eszközök, például a TP-Link TL-R480T+, nem viselkednek tökéletesen, összességében vannak saját sajátosságaik. Ezt a részt Linux alatt sikerült ésszerűen konfigurálni az Ubuntu hivatalos weboldalának köszönhetően. IP-Balanszírozás: több internetcsatornát egyesítünk egybe.. A ráadásul bármelyik csatorna bármikor "leállhat", ahogy fel is léphet. Ha érdeklik az aktuálisan működő szkriptek (erről külön publikáció érdemes) — írjon a megjegyzésekbe.

A szóban forgó megoldás nem állítja, hogy egyedi lenne, de szeretném feltenni a kérdést: „Miért kellene a vállalatoknak alkalmazkodniuk kétes külső termékekhez, amelyek komoly hardverigényekkel bírnak, amikor egy alternatív megoldást is figyelembe vehetnek?”.

Ha Oroszországban létezik a Roszkomnadzor listája, Ukrajnában pedig a Nemzetbiztonsági Tanács határozatának melléklete (pl. itt van), akkor a helyi vezetők sem tétlenkednek. Például átadták nekünk a vezetőség véleménye szerint a munkahelyi teljesítményt rontó blokkolt weboldalak listáját.

A kollégákkal más vállalatoknál beszélgetve, ahol alapértelmezés szerint tiltottak minden weboldalt, és csak kérések alapján, a főnök engedélyével lehet hozzáférni a konkrét oldalakhoz, tisztelettel mosolyogva, gondolkodva és a problémákra „rágyújtva” jutottunk arra a megértésre, hogy az élet mégiscsak szép, és elkezdtük a keresést.

Áttekintve nemcsak analitikusan, hogy mit mondanak a „háztartási könyvekben” a forgalom szűréséről, hanem azt is megnézve, hogy mi történik a különböző szolgáltatók csatornáin, a következő receptet jegyeztük meg (bármelyik képernyőfelvétel kicsit meg van vágva, kérlek értsétek meg):

Szolgáltató 1
— nem foglalkozik vele, és rákényszeríti a saját DNS szervereit és átlátszó proxyt. Na és?… legalább elérjük azt, amire szükségünk van (ha ez szükséges :))

Szolgáltató 2
— úgy véli, hogy az ő felső szolgáltatójának kellene ebben gondolkodnia, a felső szolgáltató tech-támogatása még el is ismerte, hogy miért nem tudom megnyitni a szükséges, nem tiltott weboldalt. Gondolom, a kép mosolyt csal az arcunkra 🙂

Kiderült, hogy az általuk blokkolt weboldalak neveit IP címekké fordítják, és tényleg az IP-t blokkolják (nem zavarja őket, hogy ezen az IP címen akár 20 weboldal is elérhető).

Szolgáltató 3
— engedi a forgalmat abba az irányba, de visszafelé ugyanazon az útvonalon már nem engedi.

Szolgáltató 4
— megtilt minden csomagműveletet a megadott irányban.

Mi a teendő a VPN-nel (a Brave böngésző tiszteletére) és a böngésző pluginokkal? Amikor kezdetben a Mikrotik csomóponttal játszottunk, még egy erőforrásigényes L7 recept is készült, amit később el kellett vetnünk (a tiltott nevek száma lehet, hogy több is, szomorú, amikor a fő feladataink mellett a PPC460GT processzor terhelése 100%-ra ugrik a 30 kifejezésnél).

.

A következő tisztázódott:
A DNS 127.0.0.1-re nem csodaszer, a modern böngészők lehetővé teszik az ehhez hasonló problémák megkerülését. Nem lehet minden felhasználót korlátozott jogokkal ellátni, és nem szabad elfelejteni, hogy rengeteg alternatív DNS létezik. Az internet nem statikus, és az új DNS-címek mellett a tilalmas weboldalak új címeket vásárolnak, megváltoztatják a legfelső szintű domaineket, vagy akár szimbólumokat adnak hozzá/eltávolítanak a címükből. De van valami, ami mégis életképes:

ip route add blackhole 1.2.3.4

Teljesen működőképes lenne az IP-címek listájának beszerzése a tilalmas weboldalak listájából, de az említett okok miatt áttértünk az Iptables-ra. Már volt egy élő terheléselosztó a CentOS Linux 7.5.1804 verzióján.

A felhasználó internetkapcsolatának gyorsnak kell lennie, a böngésző nem várhat fél percet, hogy megállapítsa, hogy az adott oldal nem elérhető. Hosszas keresgélés után arra a modellre jutottunk:
Fájl 1 -> /script/denied_host, a tiltott neveket tartalmazó lista:

test.test
blablabla.bubu
torrent
porno

Fájl 2 -> /script/denied_range, a tiltott címtartományok és címek listája:

192.168.111.0/24
241.242.0.0/16

Fájl-skript 3 -> ipt.sh, amely az iptables-szal kapcsolatos munkákat végzi:

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

A sudo használata a webes interfész kezelésére vonatkozó kis hacktől függ, de az egyéves használat tapasztalata azt mutatja, hogy a webes felület nem annyira szükséges. A bevezetés után vágyunk arra, hogy a weboldalak listáját adatbázisba helyezzük, és hasonlók. A blokkolt hosztok száma meghaladja a 250-et + egy tucat címtartomány. Valóban probléma merül fel, amikor az oldalra HTTPS kapcsolaton keresztül lépünk, és mint rendszergazdának, vannak kifogásaim a böngészőkkel szemben :), de ez már egyedi eset, a legtöbb esetben a hozzáférés hiánya mégis a mi oldalunkon áll, az Opera VPN-t, a friGate típusú plugineket és a Microsoft telemetriát is sikeresen blokkoljuk.

Forrás: habr.com