Dlaczego blokować port wychodzący 22?

Jestem programistą i pracowałem dla kilku klientów, których sieci blokują połączenia wychodzące na porcie 22. Biorąc pod uwagę, że programiści często muszą używać portu 22 do ssh, wydaje się to procedurą odwrotną do zamierzonej. W najlepszym razie zmusza programistów do wystawienia rachunku za Internet 3G. W najgorszym przypadku oznacza to, że nie mogą skutecznie wykonywać swojej pracy.

Biorąc pod uwagę trudności, jakie to stwarza, czy doświadczony administrator może wyjaśnić pożądaną korzyść, która wydaje się być działaniem polegającym na przegraniu?

Nie widzę, aby ktokolwiek szczegółowo opisał konkretne ryzyko związane z przekierowaniem portów SSH.

Jeśli znajdujesz się w zaporze i masz wychodzący dostęp SSH do maszyny w publicznym Internecie, możesz SSH do tego systemu publicznego, a następnie utworzyć tunel, aby osoby w publicznym Internecie mogły ssh do systemu w twojej sieci, całkowicie omijanie zapory ogniowej.

Jeśli fred to twój pulpit, a barney jest ważnym serwerem w twojej firmie, a wilma jest publiczna, działa (na fred):

ssh -R *: 9000: barney: 22 wilma

a zalogowanie pozwoli atakującemu ssh na port 9000 na wilma i rozmowę z demonem SSH Barneya.

Zapora nigdy nie widzi tego jako połączenia przychodzącego, ponieważ dane są przekazywane przez połączenie, które zostało pierwotnie ustanowione w kierunku wychodzącym.

To denerwujące, ale całkowicie uzasadniona polityka bezpieczeństwa sieci.

Jeśli blokują pomieszanie portów, przepuszczają niektóre rzeczy i blokują inne losowo (uwielbiam smutną historię Paula Tomblina o ludziach, którzy blokują SSH i zezwalają na Telnet), to albo mają bardzo dziwny przypadek, w jaki sposób zabezpieczyć ich obwód sieci lub ich zasady bezpieczeństwa są, przynajmniej z zewnątrz, najwyraźniej źle przemyślane. Nie możesz zrozumieć takich sytuacji, więc po prostu nalicz im stawkę za osoby, które są uciążliwe i kontynuują swój dzień.

Jeśli blokują WSZYSTKIE porty, chyba że istnieje konkretny przypadek biznesowy pozwalający na ruch przez ten port, w którym to momencie jest starannie zarządzany , robią to, ponieważ są kompetentni w swoich zadaniach.

Kiedy próbujesz napisać bezpieczną aplikację, czy ułatwiasz innym procesom odczytywanie i zapisywanie w niej informacji tak, jak im się podoba, czy masz kilka dokładnie udokumentowanych interfejsów API, do których dzwoni się od ludzi i które odkażają starannie?

Zarządzanie ryzykiem - jeśli uważasz, że ruch do lub z twojej sieci przechodzącej do Internetu stanowi ryzyko, to starasz się zminimalizować liczbę sposobów, w jakie ruch może dotrzeć do Internetu, zarówno pod względem liczby tras, jak i metod. Następnie możesz monitorować i filtrować wybrane „błogosławione” bramy i porty, aby upewnić się, że ruch, który je przejeżdża, jest zgodny z oczekiwaniami.

Jest to „domyślna odmowa” zapory ogniowej i jest zwykle uważana za dobry pomysł, z kilkoma zastrzeżeniami, do których dojdę. Oznacza to, że wszystko jest zablokowane, chyba że istnieje konkretny powód, aby go odblokować, a korzyści z tego powodu przeważają nad ryzykiem.

Edycja: Powinienem wyjaśnić, nie mówię tylko o ryzyku, że jeden protokół będzie dozwolony, a drugi zablokowany, ale mówię o potencjalnym ryzyku dla biznesu, że informacje mogą dostać się do lub z sieci w niekontrolowany sposób droga.

Teraz ostrzeżenia i być może plan uwolnienia rzeczy:

Może to być irytujące, gdy coś Cię zablokuje, czyli na pozycji, w której znajdujesz się u niektórych swoich klientów. Zbyt często ludzie odpowiedzialni za zaporę ogniową uważają, że ich zadaniem jest powiedzenie „Nie”, zamiast „Oto ryzyko, jakie są korzyści, zobaczmy, co możemy zrobić”.

Jeśli porozmawiasz z kimkolwiek, kto zarządza bezpieczeństwem sieci dla twoich klientów, może być skłonny do skonfigurowania czegoś dla ciebie. Jeśli potrafisz zidentyfikować kilka konkretnych systemów na ich końcu, potrzebujesz dostępu i / lub zagwarantować, że połączysz się tylko z określonego adresu IP, mogą być bardziej zadowoleni z utworzenia wyjątku zapory ogniowej dla połączeń SSH dla tych konkretnych warunków niż byłoby po prostu otworzyć połączenia z całym Internetem. Lub mogą mieć funkcję VPN, której można użyć do tunelowania przez zaporę.

Pewna duża firma w Rochester w Nowym Jorku, która kiedyś kręciła dużo filmów, blokowała wychodzące ssh, gdy tam pracowałem, ale pozwoliła na telnet ! Kiedy o to zapytałem, powiedzieli, że ssh jest luką bezpieczeństwa.

Innymi słowy, firmy czasami podejmują głupie decyzje, a następnie wymyślają wymówki dotyczące bezpieczeństwa zamiast przyznawać się do swoich błędów.

Rozumiem blokowanie przychodzącej komunikacji SSH, jeśli firma nie zezwala na zewnętrzne logowanie. Ale po raz pierwszy słyszę o wychodzącym bloku SSH.

Należy zauważyć, że takie zapory ogniowe prawdopodobnie ograniczą tylko zwykłego użytkownika SSH. Jeśli ktoś naprawdę chce SSH na zewnątrz (co zwykle będzie na serwerze / maszynie, do którego ma znaczący dostęp, poza siecią korporacyjną), może łatwo uruchomić serwer SSH na porcie innym niż 22 (powiedzmy port 80). Blok zostanie łatwo ominięty.

Istnieje również kilka narzędzi domeny publicznej, które pozwolą ci wyjść z przedsiębiorstwa przez HTTP (port 80 lub HTTPS port 443) i udostępnią proxy, które pozwolą ci połączyć się z portem 22 na zewnątrz.

Edycja: Ok, chwileczkę, mam pomysł, dlaczego może to być polityka.

Czasami ludzie używają tuneli SSH, aby ominąć podstawowe wychodzące zapory ogniowe dla protokołów takich jak IM i Bittorrent (na przykład). To // mogło // uruchomić takie zasady. Jednak nadal uważam, że większość z tych narzędzi tunelowych byłaby w stanie pracować na portach innych niż 22.

Jedynym sposobem na zablokowanie takich tuneli wychodzących jest wykrycie komunikacji SSH w locie i (dynamiczne) blokowanie tych połączeń TCP.

Prawdopodobnie jest to kwestia przepisów / zgodności. Twój pracodawca chce mieć możliwość odczytu / archiwizacji całej komunikacji. Jest to bardzo często wymagane w branżach takich jak bankowość.

Moim zdaniem istnieją dwa podstawowe powody blokowania portu wychodzącego 22.

Po pierwsze, jak wspomniano, przekierowanie portów SSH może być używane jako proxy lub ominięcie innych portów i usług, aby uniknąć polityki IT stwierdzającej, że taki ruch jest niedozwolony.

Po drugie, wiele złośliwych programów / botnetów korzysta z portu 22, ponieważ często jest postrzegany jako „bezpieczny” i dlatego jest dozwolony. Następnie mogą uruchamiać procesy z tego portu, a zainfekowane komputery mogą również przeprowadzać ataki SSH typu brute force.

Najczęściej jest to raczej przypadek blokowania wszystkich połączeń wychodzących, chyba że jest to potrzebne, i dopóki nie spróbujesz, nikt nie zażądał, aby port 22 był dostępny dla połączeń wychodzących (tylko 80, 433 itd.). W takim przypadku rozwiązanie może być tak proste, jak skontaktowanie się z IS / IT i poinformowanie ich, dlaczego potrzebujesz dodania wyjątku, aby Twoja stacja mogła nawiązywać wychodzące połączenia SSH z określonymi hostami lub ogólnie.

Czasami istnieje obawa, że ​​ludzie mogą korzystać z narzędzia do korzystania z SSH jako sposobu konfigurowania serwerów proxy (poprzez przekierowanie portów przez łącze) w celu obejścia innych kontroli. Może to być bardzo ważny czynnik w niektórych regulowanych branżach (np. Bankach), w których cała komunikacja musi być monitorowana / rejestrowana ze względów prawnych (zniechęcanie do wykorzystywania informacji poufnych, wykrywanie / blokowanie przekazywania danych korporacyjnych lub osobowych itp.) Lub firm, w których to wielki strach przed wewnętrznymi wyciekami, które ujawniają, przypadkowo lub w inny sposób, tajemnice handlowe. W takich przypadkach korzystanie z łącza 3G (lub innych technik, takich jak próba tunelowania SSH przez HTTP) w celu obejścia ograniczeń może stanowić naruszenie umowy, a zatem przestępstwo zwolnienia (lub, co gorsza, przestępstwo prawne), więc należy zachować ostrożność, aby uzgodnij swoje działanie przed jego podjęciem.

Innym powodem może być ograniczenie zajmowanego miejsca (do usług wewnętrznych dostępnych dla hostów w firmowych zaporach ogniowych i ogólnie dla całego świata), jeśli coś niestosownego uda się zainstalować na maszynie uruchomionej przez firmę. Jeśli żadne połączenia SSH nie są możliwe na porcie 22, wiele prostszych hacków, które próbują użyć logowania SSH typu brute-force, ponieważ jedna z ich tras propagacji zostanie zablokowana. W takim przypadku możesz ponownie poprosić o dodanie wyjątku, aby Twój komputer mógł nawiązywać połączenia SSH, jeśli połączenia te mogą być uzasadnione dla osób kontrolujących zaporę (firewall).

Twoi klienci prawdopodobnie posiadają nietrywialne dane, które chcieliby zatrzymać. Outbound SSH to naprawdę zła rzecz, jaką można mieć dla całej sieci. Omijanie serwerów proxy, danych wrażliwych na wyciek i generalnie jest wstrętne.

IMO, wszystko, co przechodzi przez obwód sieci / Internetu, powinno być zrozumiałe i możliwe do kontrolowania. Jeśli grupa deweloperów potrzebuje dostępu do serwerów u dostawcy hostingu przez ssh, to w porządku - ale trzeba to również udokumentować. Zasadniczo w miejscach, w których pracowałem, ustanawiamy dedykowane połączenia VPN między lokalizacjami do lokalizacji poza naszą siecią (zasadniczo rozszerzając naszą sieć wewnętrzną) i unikamy protokołów klienta, takich jak SSH, przez Internet.

Ponieważ SSH może być używany jako VPN. Jest zaszyfrowany, więc administratorzy sieci dosłownie nie mają pojęcia, co opuszcza ich sieć (zrzut bazy danych klientów itp.). Właśnie opisałem to w mojej miesięcznej kolumnie „Tajne tunele” . Koszt niektórych sieci 3G jest o wiele niższy niż konieczność martwienia się o szyfrowane protokoły kierujące dane z sieci. Dodatkowo, jeśli domyślnie zablokujesz port wychodzący 22 i przeprowadzisz kontrolę ruchu, możesz łatwo znaleźć SSH na niestandardowych portach, a tym samym znaleźć osoby naruszające zasady bezpieczeństwa.

Znam kilka osób, które nadużywają możliwości SSH do instalowania proxy SOCKS przez SSH, tym samym omijając niektóre ograniczenia witryny.

Lub nawet proste przekierowanie portów ( ssh -L ....), jeśli port jest rzeczywiście zablokowany z powodu ograniczeń witryny, poszedłbym do:

• lokalny administrator i
• twój kierownik projektu

zabierz ich do stołu i pozwól im wyjaśnić, dlaczego jest to zablokowane. Oczywiście musisz mieć dobre powody, dla których potrzebujesz dostępu do zewnętrznego portu SSH w celu opracowania produktu wewnętrznego (wewnętrznie: Dlaczego potrzebujesz dostępu do boxA.example.com, kiedy pracujesz dla firmy snakeoil.invalid)

Ale jeszcze nie widziałem firmy blokującej wychodzące SSH :)

Wszystkie oczywiste odpowiedzi zostały podane. Jest to zaszyfrowany protokół, którego można użyć do obejścia zasad poprzez tworzenie tuneli (jest to świetny sposób na ominięcie korporacyjnych filtrów sieciowych), a także na zagrożenie stwarzane przez nieautoryzowane kanały komunikacyjne (odwrotne proxy).

To prawda, że ​​telnet powinien zostać zniszczony w każdej nowoczesnej sieci. Widzę jednak, że zezwalam na telnet poza siecią podczas blokowania ssh. Telnet ma mniejszą zdolność niż ssh i zawsze mogę monitorować strumień w czasie rzeczywistym za pomocą moich snifferów. Jeśli nie mam żadnych urządzeń Telnet w mojej sieci bazowej, a jakiś użytkownik chce się z niego telnetować, co mnie obchodzi. Widzę to i sprawdzam, czy to nie jest zagrożenie.

Oczywiście wszystko to zależy od idei, że domyślną zasadą jest blokowanie wszystkich wyjść i zezwalanie tylko na określone protokoły. Punkty bonusowe, jeśli przybliżasz je przed uderzeniem o krawędź.

Nie chodzi o blokowanie portu 22, ponieważ administratorzy mają coś przeciwko SSH, a raczej o otwieranie portów, o których wiedzą, że potrzebują otwarcia. Jeśli administratorowi nie powiedziano, że SSH jest potrzebny, administrator go zablokuje, zgodnie z tą samą zasadą, która dotyczy wyłączania nieużywanych usług na serwerze.

Oczywistym jest, że wychodzący blok TCP / 22 jest łatwy do obejścia, chyba że administratorzy sieci podjęli poważne, poważne wysiłki, aby w szczególności zablokować ruch SSH . Co więcej, administratorzy zasobów muszą być na bieżąco, aby przeprowadzić inwentaryzację zasobów wystarczającą do przechwycenia modemów 3G i podejrzanych adresów IP na drugiej karcie sieciowej. W naszej okolicy mamy usługę ClearWire, więc nawet WiMax jest opcją końcową w zakresie bezpieczeństwa naszej sieci.

Nie jesteśmy instytucją zajmującą się głównie wyciekiem informacji. Ale gdyby tak było, musielibyśmy połączyć drakońską politykę bezpieczeństwa sieci z drakońską polityką aktywów, z audytem. Według mojej najlepszej wiedzy nie sądzę, aby istniał gotowy pakiet zabezpieczeń, który wyłączałby gniazdo sieciowe zasobu, który inwentaryzuje z jakimś zewnętrznym połączeniem sieciowym. To może nadchodzić.

W przypadku braku takiego pakietu proces inwentaryzacji zasobów jest jednym z najlepszych sposobów na złapanie końcowego połączenia sieciowego, takiego jak 3G lub WiMax.

I wreszcie, ślepe blokowanie TCP / 22 zablokuje tylko najmniej sprytnych użytkowników końcowych, którzy zamierzają naruszyć AUP w swojej sieci roboczej.

Widziałem 22 zablokowanych, gdy odkryli, że ludzie kierują ruchem http przez 22. To był przystanek dla tych z nas, którzy tego potrzebowali, ale orgia nie zgodziła się.

Większość większych organizacji będzie blokować wszystko i zezwalać na dostęp HTTP / HTTPS tylko przez serwer proxy.

Byłbym bardzo zaskoczony, gdybym usłyszał o wszelkich korporacjach, które zezwalają na bezpośrednie połączenia zewnętrzne z komputerów stacjonarnych lub serwerów, chyba że istnieje konkretna potrzeba.

Nic nie stoi na przeszkodzie, aby uruchomić zdalny sshd na porcie 80. Zarówno ssh, jak i sshd mają opcję -p, aby ustawić port.

Oczywiście, jeśli twoi administratorzy są sprytni, powinni uważać na ruch ssh, a nie tylko na port 22. Wygląda na to, że masz problem z polityką, a nie problem techniczny.

Jak zauważyli inni, zaszyfrowane protokoły mogą powodować zgagę u ludzi, którzy muszą się martwić o różne problemy związane ze zgodnością.