як заблокувати трафік ssh tunneling?


14

якщо хтось повинен встановити ssh-тунель до / з роботи чи додому, чи є спосіб запобігти майбутньому трафіку тунелів SSH?

Я розумію, що websense може блокувати трафік, але користувачі, які використовують ssh-тунелінг, можуть обійти websense або інші подібні продукти, оскільки він не може розшифрувати або заглянути далі в пакет, щоб визначити різницю між законним або нелегітимним трафіком.

з деяких читань та досліджень я виявив, що ви можете зробити наступне: - повністю вимкнути SSH; взагалі не дозволено - обмежте доступ до ssh лише тим користувачам, які їм потрібні для доступу, і забороняйте усім іншим доступ до ssh - створіть спеціальний протокол до чорного списку або білого списку ssh-трафіку за призначенням (припустимо, що списки керовані) - перегляньте журнали на трафік ssh, перегляньте цільові IP-адреси та перевірте, чи вони дозволяють легітимним чи дозволеним пристроям чи ні, або перевірте, чи є більш регулярний інтернет-трафік, ніж тунельний трафік, і чи можете ви заборонити / переглядати цей чорний список

Але мені було цікаво, окрім цих варіантів, чи вдасться обійти вищезазначені варіанти за допомогою нападу "людина-в-середині"?

Або є інший варіант блокування трафіку ssh-тунелювання або навіть якогось мережевого пристрою, який може фільтрувати / блокувати цей трафік?

Дякую за допомогу.


До речі, ось декілька посилань, які допомагають пояснити ssh-тунелювання: chamibuddhika.wordpress.com/2012/03/21/ssh-tunnelling-explained revsys.com/writings/quicktips/ssh-faster-connections.html alvinalexander.com/unix / edu /… та деякі з пояснень про неможливість блокування ssh-тунелювання, за винятком наведених вище варіантів: community.websense.com/forums/p/11004/28405.aspx
user1609

Відповіді:


13

Запобігання вихідних з'єднань ssh і, отже, будь-яких тунелів вимагало б повної блокади вихідних з'єднань шляхом глибокої перевірки пакетів. Дивлячись на порти, буде на 100% марним. Ви повинні подивитися на фактичну корисну навантаження пакетів, щоб знати, що це SSH. (це те, що робить websense.)

Єдиний інший варіант - це налаштування хоста "проксі". Заблокуйте конфігурацію, щоб клієнт і сервер ssh не дозволяли тунелювати, тоді дозволяйте лише тій машині здійснювати вихідні ssh-з’єднання - звичайно, це включає і безпеку системи, інакше люди можуть запускати будь-яке програмне забезпечення ssh.


дякую за коментар тому з усіх варіантів це звучить як кращий підхід. цінуємо допомогу.
user1609

9

Існує ще один метод, якщо ви просто дивитесь на те, щоб люди не могли використовувати SSH як проксі-сервіс, чому не обмежувати його, щоб сказати, 20 кБ / сек або близько того, що в кінцевому підсумку є досить болісним для Інтернету, але непомітним для використання консолі.

Якщо ви хочете дозволити передачу файлів із звичайною швидкістю, це не було б варіантом.


цікавий момент і добре подумати. дякую, що поділилися цим.
user1609

1
Це також обмежує швидкість будь-якого "scp" трафіку, який може не надто добре залежати від того, як часто людям потрібно копіювати файли.
Рікі Бім

6

Якщо ви керуєте сервером SSH та брандмауером, то ви можете керувати доступом, блокуючи доступ до будь-якого порту, який використовує SSH-сервер (за замовчуванням 22). Якщо порт раніше не був відкритий, вхідні з'єднання, швидше за все, будуть заблоковані, хоча ви, мабуть, виявили, що вихідні з'єднання будуть дозволені. При правильному дизайні та плануванні ви можете контролювати доступ настільки дрібнозернистим або грубозернистим способом, як вам подобається.

Якщо ви не керуєте сервером SSH, ви не можете гарантувати порт, який він використовує, тому фільтрувати на основі одного порту буде набагато важче.

Якщо вам потрібно дозволити кожному отримати доступ до SSH-сервера, поки вони знаходяться у вашій мережі, але лише декілька вибраних, коли вони знаходяться поза нею, стукіт порту - це акуратне зчитування.


1
Дякую, що поділились. знайшли посилання про стукування порту. це цікава концепція, вперше я почув про неї. для всіх, хто цікавиться, ось, що я читаю поки що про цю функцію: portknocking.org та bsdly.blogspot.com/2012/04/why-not-use-port-knocking.html
user1609
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.