Dlaczego blokować port wychodzący 22?

61

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?

runako
źródło
1
Blokowanie portów to tylko połowa sukcesu. Aby ukończyć cykl, musisz upewnić się, że usługi, które próbujesz chronić, nie działają na niestandardowych portach.
aharden
1
Pytanie powinno naprawdę brzmieć „Po co blokować port wychodzący 22?” ponieważ istnieje milion dobrych powodów, dla których chcesz uruchomić usługę ssh na niestandardowym porcie. Wylotowe ... nie tak bardzo. Dodałem +1 do odpowiedzi Roberta Moira, który wykonał całkiem dobrą robotę, tłumacząc to.
KPWINC
@KPWINC, dodał wyjaśnienie do tytułu. Dzięki!
runako
3
Pomyśl o porcie 22 jak o pudełku pandory. Administratorzy sieci nie widzą, co jest w ruchu, a co najgorsze, ssh może być używany do ominięcia zabezpieczeń sieci, co zagraża integralności sieci.
biosFF
1
@biosFF: Port 443.
Hello71

Odpowiedzi:

77

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.

James F.
źródło
1
Dzięki za bardzo wnikliwą odpowiedź. Jest to jedna z nielicznych odpowiedzi, która odnosi się do ryzyka technicznego (w przeciwieństwie do ryzyka politycznego) otwartych portów wychodzących.
runako
6
+1 za uzasadnienie techniczne. (Jednak może to zrobić tylko złowrogi stażysta, który może również używać innych portów niż TCP 22 na zdalnym hoście. Za pomocą których wróciliśmy do niektórych zasad blokowania wszystkich zasad)
DerMike
7
Dzięki niestandardowemu protokołowi i sprytnemu programowaniu proxy można to zrobić za pomocą HTTPS - choć wolniej. Dopóki zezwalasz na wychodzący zaszyfrowany ruch, jesteś podatny na tego rodzaju „atak”.
Michael Sondergaard,
3
To dobra odpowiedź JamesF, ale nie jest to kwestia bezpieczeństwa, o której warto pomyśleć, ponieważ zakłada ona niezwykle rzadki scenariusz i wymaga wykorzystania serwerów / klientów SSH. Złośliwy użytkownik musiałby najpierw wykorzystać serwer SSH (na twoim komputerze) i wymyślić sposób na wykorzystanie twojego klienta SSH (na twoim biznesowym hoście). Ponieważ nie można użyć portu 22, aby uzyskać dostęp do hosta z zaporą biznesową (który ma tylko port wychodzący 22) lub porozmawiać z nim. Jeśli Twój standard bezpieczeństwa jest tak wysoki, Twój gospodarz biznesowy nie powinien nawet być w Internecie w żadnej sytuacji.
Dexter
1
Możesz tunelować ruch przez DNS (np. Za pomocą iodine), jeśli HTTPS i SSH są niedostępne. Ale to jest bardzo wolne.
Mark K Cowan
38

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ę.

Rob Moir
źródło
3
+1 za 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, wtedy robią to, ponieważ są kompetentni w swoich zadaniach.
cop1152
-1, ponieważ ssh nie może być monitorowany przez ochroniarzy, ale Telnet może. Chodzi mi o to, że chociaż istnieją głupie zasady bezpieczeństwa sieci, scharakteryzowanie tej zasady jako „losowej” i „whackjob” bez zrozumienia rzeczywistych potrzeb biznesowych jest również krótkie.
pcapademic
2
Cóż, masz prawo do swojej opinii, oczywiście, Eric, i chętnie zmienię te słowa, jeśli uważasz, że są one pejoratywne, ale jestem całkiem pewien, że taka polityka byłaby albo źle przemyślana, albo bardzo nietypowa sprawa.
Rob Moir
+1 za „wszystkie porty”
Ian Boyd
18

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.

Paul Tomblin
źródło
6
TELNET to dziura w zabezpieczeniach. Należy go zbanować (tylko po to, aby ludzie podejmowali lepsze głupie decyzje w przyszłości).
nik
3
Pozwól, że wyjaśnię tutaj, czym jest dziura bezpieczeństwa, która jest subiektywna dla zabezpieczanej powierzchni. Jeśli jesteś właścicielem strony internetowej i próbujesz połączyć się z serwerem, TELNET to dziura. Jeśli jesteś pracownikiem firmy finansowej, która próbuje połączyć się z serwerem domowym na zewnątrz (ponad liniami monitorowanymi przez twojego pracodawcę), SSH stanowi lukę bezpieczeństwa dla twoich pracodawców!
nik
1
Biorąc pod uwagę, jak łatwo jest sfałszować telnet w obu kierunkach, powiedziałbym, że telnet stanowi lukę w zabezpieczeniach nawet dla firmy, która pozwala mu działać. Ale firma, która na to pozwala, ale nie zezwala na ssh, w żadnym wypadku nie będzie podejmować inteligentnych decyzji dotyczących bezpieczeństwa.
Paul Tomblin
3
Telnet to prezent, który po prostu daje. Było ok 20 lat temu, ale teraz naprawdę chciałbym, żeby to się skończyło.
Rob Moir
2
Wszystko zależy od twojego POV. Prawdopodobnie mieli ludzi, którzy musieli uzyskać dostęp do niektórych starszych procesów przez Telnet, których nas łatwo można skontrolować. OTOH, nie masz pojęcia, co się dzieje z SSH, ludzie mogliby zakładać tunele do zagranicznych sieci i robić różne głupie rzeczy. Telnet nie powinien być używany w dzisiejszych czasach, ale każdy, kto pozwala wychodzącemu SSH, musi szukać nowej kariery.
duffbeer703
6

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.

nik
źródło
3
Port 443 jest lepszy, ponieważ zakłada się, że jest już zaszyfrowany, więc serwery proxy nie będą denerwować dziwnymi danymi. Możesz łatwo skonfigurować serwer ssh nasłuchujący na porcie 443, a stamtąd możesz iść gdziekolwiek.
bandi
1
W jednym miejscu, w którym pracowałem, jeden z moich współpracowników korzystał z programu, który tunelował cały ruch sieciowy przez tunel ssh przez nasz internetowy serwer proxy do portu 80 na jego komputerze domowym, a stamtąd do Internetu. Mógł użyć dowolnego protokołu, który chciał, ale wyglądało na to, że pochodzi on z jego domu zamiast z firmy. Na szczęście wiedział, jak nieświadomi są administratorzy sieci, więc nie ryzykował, że zostanie złapany.
Paul Tomblin
1
Oczywiście, jeśli zostaniesz przyłapany na przejściu jednego z tych skomplikowanych tańców, aby omijać zaporę, nie możesz tak naprawdę powoływać się na niewinność i ignorancję. Trochę ciężko to wszystko zrobić i powiedzieć „przepraszam szefie, to po prostu zadziałało, więc nie zdawałem sobie sprawy, że robię coś złego”.
Rob Moir
4

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ść.

Joe
źródło
Czy to nie oznacza, że ​​muszą również blokować HTTPS?
runako
3
Nie, umożliwiają kontrolę SSL. Ten proces odszyfrowuje HTTPS, a następnie ponownie szyfruje pakiety przychodzące / wychodzące poprzez wstrzyknięcie zaufanego certyfikatu na wszystkie stacje robocze według zasad grupy. W ten sposób mogą filtrować / skanować tak samo jak w przypadku HTTP. Sektor bankowy jest jednym z najbardziej drakońskich środowisk do blokowania sieci.
spoulson
4

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.

jtimberman
źródło
3

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).

David Spillett
źródło
Tak, jest całkiem prawdopodobne, że wszystkie usługi wychodzące, które nie są jeszcze wymagane, mogły zostać zablokowane (domyślnie).
nik
Ale blokowanie tcp / 22 nie zapobiegnie bezpiecznej komunikacji wychodzącej (która może być wykonana na dowolnym porcie, o ile użytkownik ma nasłuchującego na zewnątrz, co obecnie nie jest trudne).
nik
Jeśli sieć wewnętrzna ma zastosowanie do komunikacji SSH, blokowanie jej nie będzie działać, a jeśli nie jest wymagana komunikacja SSH, zazwyczaj w sieci nie będzie również wrażliwych maszyn nasłuchujących SSH. I, typowa propagacja robaków nie próbuje brutalnej siły SSH (jeśli martwisz się tym spojrzeniem na en.wikipedia.org/wiki/SSHBlock ), bardziej prawdopodobne jest, że spróbujesz tcp / 445 na twoich maszynach z Windows.
nik
3

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.

duffbeer703
źródło
Dziękuję za odpowiedź. Jak obchodzisz się z dedykowanymi VPNami na stronach poza Twoją kontrolą (np. EC2, hosty internetowe itp.)? Czy ci dostawcy zazwyczaj chcą po prostu wykonać tę niestandardową konfigurację dla Ciebie, czy też zazwyczaj musisz podjąć jakieś duże minimalne zobowiązanie biznesowe, aby ich do tego skłonić?
runako
2
Czy martwisz się również, że zmuszasz ludzi do korzystania z kart 3G poza siecią, aby wykonywać swoją pracę? Z mojego doświadczenia wynika, że ​​zablokowane sieci nieuchronnie prowadzą do wielu kart 3G i innych ukrytych obejść, ponieważ ludzie nie mogą wykonać swoich zadań w wyznaczonym czasie, jeśli muszą czekać na IT, aby zatwierdzić ich użycie, jeśli ktokolwiek nawet wie, kto zadzwonić, aby uzyskać wyjątek. (Jedna rażąca sprawa obejmowała serwer pocztowy, który nie akceptowałby przychodzących załączników z Internetu. Tak!) Byłbym ciekawy, jak poradzisz sobie z tą równowagą.
runako
1
Dodaj komentarz na temat przekierowywania portów przez ssh i myślę, że to poprawna odpowiedź na pytanie. ssh może być dobrym protokołem zezwalającym na serwer proxy. Administratorzy mogą monitorować, co się dzieje, mogą blokować przekierowanie portów, a ludzie mogą go używać do zdalnej powłoki i usług zdalnego kopiowania.
pcapademic
Jesteśmy na tyle duże, że prawdopodobnie 90% naszych usług nie wymaga uruchomienia administracji wychodzącej. Zazwyczaj, gdy to robimy, stawiamy dedykowany tunel VPN jako wymóg w zapytaniu ofertowym, który ma tendencję do eliminowania dostawców, którzy nie chcą lub nie mogą go zapewnić. Z tego powodu uważam, że minimalna liczba osób korzysta z 3G i podobnych obejść.
duffbeer703
Nie możesz też pozwolić, aby osoby odpowiedzialne za bezpieczeństwo dyktowały dostęp. Zezwalasz pracownikom działu wsparcia aplikacji i sieci na wypracowanie akceptowalnego rozwiązania, z zastrzeżeniem przeglądu bezpieczeństwa. Opracuj to rozwiązanie na wczesnym etapie procesu, a nie rano, gdy musisz przejść do produkcji. Dzięki temu unikniesz opóźnień w przyjmowaniu wniosków w stylu DMV.
duffbeer703
2

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.

Kurt
źródło
Dzięki za wgląd. Wygląda na to, że nie uważa się 3G za tajny tunel. Czy mógłbyś rzucić nieco światła na to, dlaczego sensowniej jest mieć ludzi całkowicie odłączonych od sieci podczas komunikacji z Internetem? Wygląda na to, że wolisz nieuczciwe urządzenia nawet mniej niż otwarte 22 dla połączeń wychodzących.
runako
1
„... możesz łatwo znaleźć SSH na niestandardowych portach ...” Naprawdę? Jak szukasz negocjacji SSL / TLS na portach innych niż 443? Bardzo ciekawy.
Dscoduc
Tak, możesz wykryć ruch ssh, Google: snort / ssh / detection / content / rules, nie wiem o innych systemach IDS, ale jeśli Snort to zrobi, będzie musiał zostać popsuty, aby tego nie zrobić.
Kurt
1

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 :)

Serverhorror
źródło
Widziałem jedną firmę, która blokuje wychodzące SSH. Zablokowali także prawie wszystko inne i na przykład wirus sprawdził wszystkie transfery HTTP za pomocą proxy. Firma była centralnym depozytem papierów wartościowych.
Esko Luontola,
Pracuję dla takiej firmy. Na szczęście SSH można tunelować przez https. Oczywiście pozwalają one tylko https na port 443 ... sslh na ratunek!
Mikeage
proxytunnel FTW :)
serverhorror
1

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ź.

dr.pooter
źródło
0

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.

Maximus Minimus
źródło
0

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.

sysadmin1138
źródło
Możesz dostosować raporty za pomocą SCCM, aby uzyskać te informacje. Tam, gdzie pracuję, używanie osobistego laptopa lub karty WAN w celu ominięcia bezpieczeństwa sieci podlega postępowaniu dyscyplinarnemu.
duffbeer703
0

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ę.

Shawn Anderson
źródło
0

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.

Cefas
źródło
0

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ą.

Bruce ONeel
źródło