Dotaz: blokování facebook.com (https) pomocí iptables

[walker]

Přílohy:

• fcb_deny1.png (91023 bytů)
• fcb_deny2.png (26822 bytů)

Přeji hezký den,

na linuxově založeném pc (IPCOP 2.0.6) se snažím zablokova https na facebook. Jelikož používám proxy (squid) v transparentním modu, není toto možné pomocí něho řešit. Na netu jsem našel funkční konfiguraci, která mi však jaksi nefunguje :(

FACEBOOK_ALLOW="192.168.168.100 192.168.168.102 192.168.168.109"
iptables -N FACEBOOK
iptables -I FORWARD -m tcp -p tcp -m iprange --dst-range 66.220.144.0-66.220.159.255 --dport 443 -j FACEBOOK
iptables -I FORWARD -m tcp -p tcp -m iprange --dst-range 69.63.176.0-69.63.191.255 --dport 443 -j FACEBOOK
iptables -I FORWARD -m tcp -p tcp -m iprange --dst-range 204.15.20.0-204.15.23.255 --dport 443 -j FACEBOOK
iptables -I FORWARD -m tcp -p tcp -m iprange --dst-range 66.220.144.0-66.220.159.255 --dport 80 -j FACEBOOK
iptables -I FORWARD -m tcp -p tcp -m iprange --dst-range 69.63.176.0-69.63.191.255 --dport 80 -j FACEBOOK
iptables -I FORWARD -m tcp -p tcp -m iprange --dst-range 204.15.20.0-204.15.23.255 --dport 80 -j FACEBOOK
iptables -I FORWARD -m tcp -p tcp -m iprange --dst-range 69.171.242.0-69.171.242.255 --dport 80 -j FACEBOOK
iptables -I FORWARD -m tcp -p tcp -m iprange --dst-range 69.171.229.0-69.171.229.255 --dport 80 -j FACEBOOK
iptables -I FORWARD -m tcp -p tcp -m iprange --dst-range 69.171.224.0-69.171.224.255 --dport 80 -j FACEBOOK
iptables -I FORWARD -m tcp -p tcp -m iprange --dst-range 69.171.242.0-69.171.242.255 --dport 443 -j FACEBOOK
iptables -I FORWARD -m tcp -p tcp -m iprange --dst-range 69.171.229.0-69.171.229.255 --dport 443 -j FACEBOOK
iptables -I FORWARD -m tcp -p tcp -m iprange --dst-range 69.171.224.0-69.171.224.255 --dport 443 -j FACEBOOK
iptables -I FORWARD -m tcp -p tcp -m iprange --dst-range 173.252.110.0-173.252.110.255 --dport 443 -j FACEBOOK
## FACEBOOK ALLOW
for face in $FACEBOOK_ALLOW; do
iptables -A FACEBOOK -s $face -j ACCEPT
done
iptables -A FACEBOOK -j REJECT

 

facebook je však dostupný ( ip 173.252.110.27)

Iptables v příloze

 

Neví někdo, v čem je zakopaný pes? Díky za každý tip.

---

---

Odpovědi

[Petr Šobáň]

No a kde je problém?

Prostě musíš zjistit kde ti to ty pravidla obejde, nějaké dřívější pravidlo co povolí vše?

Jinak přoč tam máš ten port 80 ten přece blokneš na squidu a ty co běží přes https musíš zablokovat přístup na ty IP co facebok používá...

Ovšem čeho tím chceš dosáhnout? Stačí aby použil nějakou jinou proxi v internetu a na facebok se dostane.

[walker]

problém je v tom, že to prostě nejde. Jak je patrno, tyto pravidla jsou přidána na začátek řetězce, tudíž první ve zpracování a nemá je co dřív pustit (pakliže správně chápu fungování iptables a chains)

s portem 80 máš pravdu, to už mám ošetřeno v squidu. a co se týká obejití přes nastavení proxy - jedná se o malou firmu, kde 90% je žen pro které je občas problém i zjistit, že program jim neuložil soubor do adresáře, protože ten neexistuje (i když jim vyskočí varovná hláška ...) ;)

[walker]

Tak problém byl mezi židlí a klávesnicí .

iptables funguje jak má, bohužel jsem nepromazal cache takže se uvodní stránka dočasně načítala z ní. odstraněno a plně funkční.

[Petr Šobáň]

Taková blbost a jak to nasere.......

[Punny]

male blbosti vzdy naserou :D zamena pismen v konfiguraku, misto dvojtecky strednik a asi nejvetsi nepritel vsech :D CACHE :D

[walker]

no to mi povídej :D tolik kávy večer mi to stálo :D :D no hlavně, že vyřešeno. a vlastními silami, no nejsem na tom s mozkem asi špatně ;) ... tak průměr

[lertimir]

Před skoro 20 lety, když jsem konfiguroval svou první DNS zónu v AV jsem zapomněl tečku za mail adresou v SOA záznamu. Hledal jsem chybu 3 dny.

[jbohac]

Nevím proč by se to nedalo řešit právě na tom transparentně běžícím squidu. Přišlo by mi mnohem čistší to řešit právě tam, místo iptables, kde musíš odněkud stahovat nějaké obskurní bloky IP adres, které se můžou různě měnit.

[walker]

tak to se mi nepodařilo, ani sem nenašel žádnou radu. A že jsem strýčka google trápil dlouho. Možná by jsi poradil ;).

Všude je uvedena známá věc, že při transparentní proxy https spojení přes ni nejdou.

[jbohac]

aha - https - špatně jsem četl, omlouvám se; to skutečně jít nemůže :(

[Petr Šobáň]

Však obyčejné http:// přes to filtruje a blokuje a https:// s tím bývá problém to jedině blokovat na firewallu se seznamem IP.

[nomen omen]

Co takhle vytvořit vlastní certifikační autoritu, její certifikát naimportovat do kancelářských počítačů a pak veškerý https provoz na squidu podepisovat tou CA?

[Petr]

Ahoj,

Nevim jak moc jsi praktik, nebo spis jen teoretik, ale to by musel na tom squid dynamicky generovat certifikaty pro vsechny jednotlive hostname v url ...

[Jendа]

Dělá se to, překvapivě běžně.

[pavlix]

+1

[j]

Prekvapive ti pri pouziti transparentni poxy nebude fungovat spousta webu - nejen tech bankovnich - spravne a nektere vubec.

[pavlix]

Netvrdím, že to nemůže být pravda, ale tvůj příspěvek bez dalších podrobností působí jako plané kecy.

[nomen omen]

Má pravdu, transparentní SSL proxy nemohou fungovat už z principu. Pro vygenerování podvrženého certifikátu potřebuješ i DNS name té sajty, která se pak v prohlížeči porovná se jménem v certifikátu. Při přesměrování veškerého tcp/443 provozu na port ssl proxy (třeba pomocí iptables) tuto informaci ztratíš.

Proto tyto proxy v praxi fungují jen při explicitním uvedení v prohlížeči.

[pavlix]

Při přesměrování veškerého tcp/443 provozu na port ssl proxy (třeba pomocí iptables) tuto informaci ztratíš.

V tom případě bys předně ztratil cílovou IP a neměl bys koho kontaktovat. Takhle se to dělat logicky nemůže, pokud nemá proxy přístup k datům z conntracku.

Proto tyto proxy v praxi fungují jen při explicitním uvedení v prohlížeči.

Tvé argumenty mě nepřesvědčily, spíše naopak.

[nomen omen]

http://wiki.squid-cache.org/Features/DynamicSslCert

Poupravuji svoji formulaci. Transparentní proxy funguje, dynamické generování certifikátů ne.

[Jendа]

Přílohy:

• ssl1.png (40733 bytů)
• ssl2.png (43241 bytů)

To je dobrá poznámka a přiznám se, že nevím, jak tohle komerční řešení dělají. Ale hostname v certifikátu bylo určitě správné. Možná to poslouchá DNS a když následuje DNS dotaz a potom pokus o navázání TLS spojení, hodí to do hostname jméno z toho dotazu.

[Jendа]

Pokud má koncové stanice pod palcem (neřekl), tak by bylo mnohem lepší použít nějaký backdoor přímo na těchto stanicích.

Protože takhle přímý přístup na FB zablokoval, ale co když stanice půjde přes proxy/VPN?

A pokud se jedná o zařízení, na kterých admina nemá (e.g. notebooky studentů), tak je tento problém neřešitelný.