Czy można utworzyć zaporę ogniową, która zezwala tylko na prawidłowy ruch serwera na porcie 443, a nie na żadną inną usługę?

Zawsze korzystałem z prostej sztuczki, aby ominąć większość zapór ogniowych, co uniemożliwiało mi korzystanie z jakichkolwiek portów. Po prostu otworzyłem ssh na jednym z moich serwerów na porcie 443 i tunelowałem cały ruch.

Jednak jestem teraz w sieci, która ma zaporę ogniową, której nigdy wcześniej nie widziałam i nawet nie wiedziałam, że to możliwe.

W tej sieci można używać portu 443 tylko do legalnego ruchu na serwerze WWW. Jeśli otworzę ssh lub cokolwiek innego na porcie 443 i spróbuję połączyć się tam z tej sieci, zostanie on natychmiast zabity. Jeśli uruchomię apache na tym serwerze, to działa.

Jak to w ogóle jest możliwe? Czy istnieją jakieś bardzo wyrafinowane zapory ogniowe, które potrafią nawet analizować zaszyfrowany ruch w celu zweryfikowania, czy jest to legalny ruch https? W jaki sposób?

networking ssh firewall

— Petr
źródło

Nazywa się SPI, sprzęt wyższej klasy może wykonywać bardziej zaawansowane kontrole i przerywać niechciane połączenia.

— Linef4ult 11.01.16

Możesz utworzyć białą listę i zezwolić tylko na ten ruch. Problem polega na tym, że legalny ruch na serwerze WWW może ulec zmianie, adresy IP mogą zostać ponownie przypisane, więc tym, czym może być dziś Microsoft, może być jutro Google. Lepiej skorzystaj z bezpiecznego tunelu do komunikowania się z serwerami i utwórz białą listę dozwolonych klientów, a następnie określ procedurę dodawania kolejnych klientów w przyszłości (ponieważ ta lista się zmieni).

— Ramhound

Możesz użyć np. Obfsproxy, aby zaciemnić ruch SSH jako nieszkodliwy ruch HTTP (S).

— Michael

Tak i nie potrzebują tutaj żadnej magii, po prostu trywialne dopasowanie zawartości pakietu TCP. Mimo że SSH i TLS (SSL) szyfrują swoje ładunki , same nagłówki protokołów są nadal rozróżnialne i bardzo się od siebie różnią. Na przykład połączenie SSHv2 zawsze rozpoczyna się od wysłania przez klienta SSH-2.0-(client name and version). Podobnie, mimo że zapora sieciowa nie może naprawdę wiedzieć, czy połączenie TLS przenosi HTTP wewnątrz, może rozpoznać sam TLS .

Takie sprawdzanie warstw powyżej TCP zazwyczaj wchodzi w zakres „Głębokiej kontroli pakietów”, stosunkowo częstej funkcji.

Jednym z oczywistych sposobów na ominięcie tego jest tunelowanie SSH w TLS - na przykład za pomocą stunnela, haproxy lub sniproxy. (Oprócz zwykłego tunelowania, gdzie port 443 jest dedykowany SSH-over-TLS, mogą również multipleksować SSH / HTTP / inne protokoły przez ten sam port w oparciu o SNI i ALPN.)

Chociaż nie zawsze pokonuje to naprawdę skomplikowaną analizę ruchu, nadal omija większość filtrów, które jedynie sprawdzają „czy to wygląda jak nagłówek TLS”.

Są też denerwujące zapory ogniowe - takie, które przechwytują TLS w celu odszyfrowania i ponownego zaszyfrowania całego ruchu. Mogą one faktycznie zobaczyć wewnątrz TLS i mogą przekazywać żądania HTTP, jednocześnie blokując wszystko inne. (Pamiętaj, że niektóre programy antywirusowe również robią to samo.) Możesz rozpoznać tego rodzaju, patrząc na certyfikaty serwera; wszystkie certyfikaty generowane przez proxy wyglądają tak samo i często nie przechodzą walidacji, podczas gdy prawdziwe certyfikaty są wydawane przez różne różne urzędy certyfikacji.

— grawitacja
źródło

Czyli SSH ma swoje własne zabezpieczenia na poziomie aplikacji, a nie tylko kolejny protokół TLS (który domyślnie nie używa)?

— Medinoc,

@Medinoc: Tak, to realizuje podobne funkcje (w „transport” SSHv2 i „autoryzacja” warstw ) i nie potrzebują TLS za nic.

— grawity

Czy jest jakiś niezawodny sposób na rozpoznanie tych wąchających zapór ogniowych? Nie podoba mi się pomysł, że ktoś przechwytuje moje hasła podczas korzystania z protokołu https. Do tej pory nawet nie wiedziałem, że to możliwe.

— Petr

POST / HTTP / 1.0 base64garbage HTTP / 200 200 OK base64garbage tworzy protokół transportowy

— Joshua

@Petr Rozszerzając uwagi grawitacji, jeśli jest to komputer pracodawcy, certyfikaty prawdopodobnie zostały zainstalowane, zanim Ci je dały; a zapora MITM zostanie skonfigurowana tak, że jeśli nie używasz ich certyfikatu, ruch https nie będzie dozwolony, więc twoje wybory będą zgodne z zasadami lub nie będą miały https. OTOH w takim przypadku sprawdzenie certyfikatu prawdopodobnie powie coś w stylu „zweryfikowany przez nazwę pracodawcy” i coś podobnego w nazwie urzędu certyfikacji, jeśli dokonasz głębszych ćwiczeń. np. na moim komputerze roboczym jest to bluecoat.companyname.com (gdzie bluecoat jest marką używanego firewalla).

— Dan Neely,