iptables do blokowania stron https

9

Chcę zablokować w mojej organizacji kilka witryn, które również działają na https, takich jak Facebook, Twitter i Gmail. Kalmary nie powinny być tutaj używane zgodnie z poleceniami wyższego kierownictwa. Możemy użyć pakietu Untangle Lite i iptables.

Czy jest jakaś opcja inna niż Squid? Przydałaby się też pewna iptableszasada blokowania tego rodzaju ruchu.

znalazłem to

iptables -t filter -I INPUT -m string --string facebook.com -j LOG --algo bm
iptables -t filter -I INPUT -m string --string facebook.com -j REJECT --algo bm

ale https nadal działa na komputerach oprócz lokalnego.

iptables filter

— Dharmit
źródło

2

powinieneś wyjaśnić swojej firmie, że unikanie https dla konta osobistego nie jest dobrym pomysłem, ponieważ może prowadzić do kradzieży tożsamości w firmie, wdrożenie certyfikatu na wszystkich komputerach i działanie jako człowiek pośrodku byłoby znacznie lepszym sposobem sprawdzenia, kto łączenie z Facebookiem. też nie jestem pewien, ale myślę, że nie można już połączyć Gmaila bez https.

— Kiwy

Może wiem skąd masz te wszystkie adresy IP pls

— Jagadeesh

12

Zamiast dopasowywać na podstawie adresu URL, spróbuj dopasować na podstawie zawartości certyfikatu.

iptables -t nat -I INPUT --sport 443 -m string \
                 --string www.facebook.com --algo bm -j REJECT

Możesz również dopasować odcisk palca, ale jeśli miejsce docelowe zmieni lub zaktualizuje swój certyfikat, spowoduje to unieważnienie reguły.

— pr0f3550r
źródło

może to blokować wszystko, co pasuje do www.facebook.com, nawet w treści HTML, ale jest to uzasadnione, tak jak to w polu komentarza. Można go zablokować na poziomie adresu URL, ale co z adresem ipada?

— Nikhil Mulley,

@NikhilMulley: Nie, będzie pasować tylko do certyfikatu SSL obsługiwanego przez Facebooka. Cała reszta jest zaszyfrowana i nie można jej zobaczyć.

— bahamat

2

Tylko pierwszy pakiet połączenia wchodzi do nattabeli (i nie ma łańcucha INPUT w tabeli nat), myślę, że miałeś na myśli filterto. Ponadto istnieje (bardzo) zdalna szansa, że dopasuje pakiety, w których 443 jest portem klienta

— Stéphane Chazelas

Czy ktoś skorzystał z tego rozwiązania? Pomijając brak -p tcpreguły, nie wydaje się to być przydatne ...

— ivanleoncz 27.09.17

10

Zapora nie może kontrolować adresów URL HTTPS, do których klient próbuje uzyskać dostęp, ponieważ adres URL jest szyfrowany. Zapora może kontrolować tylko, z którymi stronami łączy się klient, używając adresów IP, ale to nie pomaga, jeśli wersje HTTP i HTTPS witryny mają ten sam adres URL (a nawet jeśli nie są, to masz aby utrzymać ogromną listę adresów IP).

Jedynym realistycznym sposobem na zablokowanie HTTPS jest całkowite zablokowanie. Nalegaj, aby wszystkie połączenia musiały być poprawnym HTTP (tj. Klient zaczyna od wysłania HTTPlinii itd.). Nie można tego zrobić za pomocą tylko IPtables, potrzebujesz rzeczywistego proxy obsługującego protokół, takiego jak Squid. (Nie wiem, do czego jest zdolny Untangle Lite).

Możesz zablokować większość ruchu HTTPS, blokując ruch wychodzący do portu 443, ponieważ prawie wszystkie serwery HTTPS znajdują się na tym porcie. Lub, stosując podejście z białej listy, zezwalaj tylko na ruch wychodzący do portu 80 (normalny port HTTP).

Innym podejściem byłoby proxy do wszystkich połączeń HTTP i HTTPS. Następnie możesz dopasować według adresów URL. Wymaga to przeprowadzenia ataku man-in-the-middle na klientów. Możesz to zrobić, jeśli wdrożysz własny urząd certyfikacji na wszystkich komputerach klienckich i zarejestrujesz go jako źródło zaufania. Można to uznać za nieetyczne.

Bez względu na to, co robisz, zdeterminowani użytkownicy skonfigurują proxy poza twoim środowiskiem i będą uruchamiać IP przez HTTP lub coś w tym rodzaju.

Wygląda na to, że albo próbujesz naprawić problem społeczny za pomocą środków technicznych, które prawie nigdy nie działają, albo starasz się wdrożyć głupie wymagania zarządzania (w takim przypadku wybrałbym blokowanie portu 443, być może tylko dla niektóre adresy IP, które pozwolą Ci zgłosić, że wykonałeś swoją pracę, bez względu na to, jak bezużyteczne).

— Gilles „SO- przestań być zły”
źródło

1

Profesjonalna zapora ogniowa, taka jak Checkpoint, pozwala na filtrowanie https bez wdrażania certyfikatu klienta w najnowszej wersji. Nie wiem, jak sobie z tym poradzą, ale działa.

— Kiwy

4

Znam jedną opcję.

Jeśli masz wewnętrzne serwery DNS do użytku, umieść w danych strefy TLD odniesienia statyczne, które rozwiązują domeny (których nie chcesz nawiązywać z zewnętrznymi połączeniami), tylko do 127.0.0.1. W ten sposób wszystkie hosty korzystające z centralnego DNS w sieci zamieniają domeny (facebook.com/twitter.com per se) na adresy pętli zwrotnej, co nigdzie nie prowadzi.

Działa to, jeśli masz całkowitą autorytatywną kontrolę nad konfiguracją resolvera komputerów klienckich w sieci. Jeśli stacje robocze / klienci mają uprawnienia do zmiany / edycji / etc / hosts lub /etc/resolv.conf, mogą obejść tę opcję.

— Nikhil Mulley
źródło

+1 za to. Można to zrobić, wstawiając te odwołania do /etc/hostspliku. Na przykład:127.0.0.1 www.facebook.com

2

Lub, dla bardziej cywilizowanego rozwiązania, ustaw rekordy DNS A (lub wpisy host / hosts.txt), aby odwoływały się do hosta intranetowego na serwerze internetowym, co dokładnie wyjaśnia, dlaczego użytkownik nie został wysłany do Facebooka itp. Pamiętaj, że to łamie HTTPS, ponieważ zamierzona nazwa hosta (np. Www.facebook.com) nie będzie zgodna z certyfikatem CN.

— Alexios

@Alexios: OpenDNS to świetne rozwiązanie do tego.

— Kevin M

@KevinM: dzięki, warto wiedzieć. Będę o tym pamiętać (chociaż mamy własną małą farmę DNS w pracy)

— Alexios

2

Opcją jest blackhole trasy do bloków sieciowych: (wymienione są dla FB)

ip route add blackhole 69.171.224.0/19
ip route add blackhole 74.119.76.0/22 
ip route add blackhole 204.15.20.0/22
ip route add blackhole 66.220.144.0/20
ip route add blackhole 69.63.176.0/20
ip route add blackhole 173.252.64.0/18

— samego siebie
źródło

1

nie, nie jest, to zbyt skomplikowane, aby utrzymać listę adresów IP dla Facebooka Twittera, a nawet Google'a, który nie komunikuje się już z własnymi zakresami adresów IP.

— Kiwy

1

Zwykły filtr zawartości nie może blokować strony ssl.

Użyj narzędzi ochrony przed włamaniami, takich jak snort / suricata.

Przykładowa reguła IPS : do blokowania adresów URL ssl dla określonego adresu IP.

drop ip any 443 -> 192.168.3.30 any (content:".facebook.com"; msg:"Simplewall Ssl block for User30 : Urls => .facebook.com " sid:26648513;rev:1;)

drop ip any 443 -> 192.168.3.30 any (content:".fbcdn.net"; msg:"Simplewall Ssl block for User30 : Urls => .fbcdn.net " ;sid:11469443;rev:1;)

drop ip any 443 -> 192.168.3.30 any (content:".youtube.com"; msg:"Simplewall Ssl block for User30 : Urls => .youtube.com " ;sid:13989722;rev:1;)

Pobierz Simplewall : w zasadach polityki simplewall udostępnianych przez Squid + Suricata IPS.

— Chetan Muneshwar
źródło

0

Powinieneś umieścić to w łańcuchu FORWARD, np

iptables -I FORWARD  -m string --string "facebook.com" \
                     --algo bm --from 1 --to 600 -j REJECT

Wpłynie to na inne systemy w sieci, z wyjątkiem zapory.

— Senthamil
źródło