jak zablokować ruch tunelujący ssh?


14

gdyby ktoś założył tunel ssh do / z pracy lub do domu, czy istnieje sposób, aby zapobiec przyszłemu tunelowaniu SSH?

Rozumiem, że websense może blokować ruch, ale użytkownicy korzystający z tunelowania ssh mogą ominąć websense lub inne podobne produkty, ponieważ nie mogą odszyfrować ani szukać dalej w pakiecie, aby odróżnić ruch legalny od nielegalnego.

z niektórych lektur i badań wynika, że ​​niektóre rzeczy, które możesz zrobić, to: - całkowicie wyłączyć SSH; w ogóle niedozwolone - ogranicz dostęp ssh tylko do użytkowników, którzy go potrzebują, i odmów wszystkim dostępu ssh - utwórz niestandardowy protokół do czarnej listy lub białej listy ruchu ssh według miejsca docelowego (zakładając, że listy można zarządzać) - przeglądaj dzienniki ruchu ssh, przeglądaj docelowe adresy IP i sprawdź, czy odpowiadają one legalnym lub dopuszczalnym urządzeniom, czy też nie, lub sprawdź, czy jest większy ruch internetowy niż ruch tunelowy i możesz odmówić / umieścić na czarnej liście ten adres IP

Zastanawiałem się jednak, oprócz tych opcji, czy byłoby możliwe obejście powyższych opcji poprzez atak typu man-in-the-middle?

A może istnieje inna opcja blokowania ruchu tunelującego ssh lub nawet jakieś urządzenie sieciowe, które może filtrować / blokować ten ruch?

dzięki za pomoc.


tak przy okazji, oto kilka linków, które pomagają wyjaśnić tunelowanie ssh: chamibuddhika.wordpress.com/2012/03/21/ssh-tunnelling-explained revsys.com/writings/quicktips/ssh-faster-connections.html alvinalexander.com/unix / edu /… i niektóre, które wyjaśniają, że nie można zablokować tunelowania ssh, z wyjątkiem powyższych opcji: community.websense.com/forums/p/11004/28405.aspx
user1609

Odpowiedzi:


13

Zapobieganie wychodzącym połączeniom ssh, a tym samym wszelkim tunelom, wymagałoby całkowitej blokady połączeń wychodzących poprzez głęboką kontrolę pakietów. Patrzenie na porty będzie w 100% bezużyteczne. Musisz spojrzeć na rzeczywisty ładunek pakietu, aby wiedzieć, że jest to SSH. (właśnie to robi websense).

Jedyną inną opcją jest skonfigurowanie hosta „proxy”. Zablokuj konfigurację, aby klient i serwer ssh nie zezwalali na tunelowanie, a następnie zezwalaj tylko tej maszynie na wychodzące połączenia ssh - oczywiście obejmuje to również zabezpieczenie systemu, w przeciwnym razie ludzie będą mogli uruchomić dowolne oprogramowanie ssh.


Dziękuję za komentarz. więc ze wszystkich opcji brzmi to jak lepsze podejście. doceniam pomoc.
user1609

9

Jest jeszcze jedna metoda, jeśli chcesz tylko powstrzymać ludzi od używania SSH jako obejścia proxy, dlaczego nie ograniczyć prędkości do około 20 kB / s, co może być dość bolesne dla sieci, ale niewidoczne dla konsoli.

Jeśli jednak chcesz zezwolić na przesyłanie plików z normalną prędkością, nie byłaby to opcja.


ciekawy punkt i warto o tym pomyśleć. dzięki za udostępnienie tego.
user1609

1
Ograniczyłoby to również wszelki ruch „scp”, co może nie być zbyt dobre w zależności od częstotliwości kopiowania plików.
Ricky Beam

6

Jeśli kontrolujesz serwer SSH i zaporę, możesz kontrolować dostęp, blokując dostęp do dowolnego portu, z którego korzysta serwer SSH (domyślnie 22). O ile port nie został wcześniej otwarty, połączenia przychodzące i tak będą prawdopodobnie blokowane, chociaż prawdopodobnie okaże się, że połączenia wychodzące będą dozwolone. Dzięki właściwemu projektowi i planowaniu możesz kontrolować dostęp tak dokładnie, jak chcesz.

Jeśli nie kontrolujesz serwera SSH, nie możesz zagwarantować, że używa on portu, więc filtrowanie na podstawie samego portu będzie znacznie trudniejsze.

Jeśli chcesz zezwolić wszystkim na dostęp do serwera SSH, gdy są oni w twojej sieci, ale tylko nieliczni, gdy są poza nim, pukanie portów to czysty odczyt.


1
dzięki za udostępnienie. znalazłem kilka linków na temat pukania portów. to ciekawa koncepcja, kiedy po raz pierwszy o niej usłyszałem. dla wszystkich zainteresowanych, oto, co czytam do tej pory dla tej funkcji: portknocking.org i bsdly.blogspot.com/2012/04/why-not-use-port-knocking.html
user1609
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.