Чому блоковий порт 22 вихідний?

Я програміст і працював для кількох клієнтів, мережі яких блокують вихідні з'єднання через порт 22. Враховуючи, що програмістам часто потрібно використовувати порт 22 для ssh, це здається контрпродуктивною процедурою. У кращому випадку він змушує програмістів виставити рахунок компанії за 3G Інтернет. У гіршому випадку це означає, що вони не можуть ефективно виконувати свою роботу.

Зважаючи на труднощі, які це створює, чи може досвідчений сидсмін пояснити бажану користь тому, що здається програшним програшком?

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

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

Якщо fred - ваш робочий стіл, а Barney - важливий сервер вашої компанії, а wilma - це відкритий, працює (на fred):

ssh -R *: 9000: barney: 22 wilma

і вхід дозволить зловмиснику ssh перейти на порт 9000 на wilma і поговорити з демоном SSH Barney.

Ваш брандмауер ніколи не сприймає це як вхідне з'єднання, оскільки дані передаються через з'єднання, яке було спочатку встановлено у вихідному напрямку.

Це дратівлива, але цілком законна політика безпеки мережі.

Якщо вони блокують мішанину портів, пропускають якісь речі і блокують якісь інші речі навмання (я люблю сумну розповідь Пола Томбліна про людей, які блокують SSH і дозволяють Telnet), то вони або мають дуже дивний крайній випадок, як вони Подумайте про безпеку периметру мережі, або їх політика безпеки, принаймні, зовні, мабуть, погано продумана. Ви не можете зрозуміти подібні ситуації, тому просто стягуйте їх з курсом людей, які болять і продовжують свій день.

Якщо вони блокують ВСІ порти, якщо немає конкретного ділового випадку дозволу трафіку через цей порт, і в цей момент його ретельно керують, вони роблять це, оскільки вони компетентні на своїх роботах.

Коли ви намагаєтесь написати захищену програму, чи спрощуєте ви інші процеси читати та записувати інформацію до неї так, як їм подобається, чи у вас є кілька ретельно задокументованих API, які ви очікуєте, що люди дзвонять і які ви ретельно саніруєте?

Управління ризиками - якщо ви вважаєте, що трафік до вашої мережі або через мережу Інтернет є ризиком, то ви намагаєтеся звести до мінімуму кількість шляхів проникнення трафіку в Інтернет як за кількістю маршрутів, так і за кількістю методів. Потім ви можете відстежувати та фільтрувати вибрані «благословенні» шлюзи та порти, щоб спробувати переконатися, що трафік, який подорожує ними, - це те, що ви очікуєте.

Це політика брандмауера "заперечувати за замовчуванням" і зазвичай вважається гарною ідеєю, з якою я прийду. Це означає, що все заблоковано, якщо немає конкретної причини для його розблокування, а переваги причини переважують ризики.

Редагувати: Я мушу уточнити, я не просто говорю про ризики дозволу одного протоколу, а іншого заблокованого, я кажу про можливі ризики для бізнесу, який може дозволити надходити в мережу або виходити з неї неконтрольовано шлях.

Тепер про застереження та, можливо, план звільнення речей:

Це може бути прикро, коли вас щось заблокує - це позиція, з якою ви опинитесь у когось із своїх клієнтів. Занадто часто люди, які відповідають за брандмауер, думають, що їхня робота сказати "Ні", а не "Ось ризики. Тепер, які переваги, давайте подивимося, що ми можемо зробити".

Якщо ви розмовляєте з тим, хто керує мережевою безпекою для ваших клієнтів, вони можуть піддати налаштування чогось для вас. Якщо ви можете ідентифікувати декілька конкретних систем у їх кінці, вам потрібен доступ та / або гарантуєте, що ви підключитесь лише з певної IP-адреси, вони можуть бути набагато щасливішими, щоб створити виключення брандмауера для з'єднань SSH для тих конкретних умов, ніж вони було б просто відкрити зв’язки з усім Інтернетом. Або у них може бути VPN-центр, який ви можете використовувати для тунелю через брандмауер.

Якась велика компанія в Рочестері, Нью-Йорк, яка робила багато фільмів, блокувала вихідний ssh, коли я працював там, але дозволив telnet ! Коли я запитав про це, вони сказали, що ssh - це дірка безпеки.

Іншими словами, компанії іноді приймають дурні рішення, а потім виправдовують балонні виправдання щодо безпеки, а не визнають свої помилки.

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

Важливо зазначити, що така брандмауер, ймовірно, обмежить лише випадкового користувача SSH. Якщо хтось дійсно хоче SSH за межами (що, як правило, до сервера / машини, у них є значний доступ, за межами корпоративної мережі), він може легко запустити SSH-сервер на інший порт (наприклад, порт 80). Блок буде обійти легко.

Існує також кілька інструментів загальнодоступного домену, які дозволять вам вийти з підприємства через HTTP (порт 80 або порт 443 HTTPS) і надавати проксі, щоб дозволити вам підключитися до порту 22 зовні.

Редагувати: Гаразд, зачекайте, я маю уявлення, чому це може бути політика.

Іноді люди використовують SSH-тунелі для обходу основних вихідних брандмауерів для таких протоколів, як IM та Bittorrent (наприклад). Це // можливо // викликало таку політику. Однак я все ще вважаю, що більшість цих інструментів для тунелів змогли б працювати в інших портах, ніж 22.

Єдиний спосіб, коли такі вихідні тунелі можуть бути заблоковані, - це виявлення зв'язку SSH на ходу та (динамічно) блокування цих з'єднань TCP.

Ймовірно, це питання регулювання / дотримання. Ваш роботодавець хоче мати можливість читати / архівувати все спілкування. Це дуже часто є вимогою в таких галузях, як банківська справа.

На мою думку, є дві основні причини блокувати вихідний порт 22.

По-перше, як згадували люди, переадресація портів SSH може використовуватися як проксі-сервер або обхід навколо інших портів і служб, щоб уникнути ІТ-політики, яка заявляє, що такий трафік заборонено.

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

Найчастіше це випадки блокування всіх вихідних з'єднань, якщо це не потрібно, і поки ви не спробували, ніхто не вимагав, щоб порт 22 був доступний для вихідних з'єднань (всього 80, 433 тощо). Якщо це так, то рішення може бути таким же простим, як зв’язатися з IS / IT та сказати їм, чому вам потрібно додати виключення, щоб ваша станція могла здійснювати вихідні SSH-з'єднання з певними хостами або взагалі.

Іноді викликає занепокоєння те, що люди можуть використовувати засоби для використання SSH як способу встановлення проксі-серверів (через переадресацію портів по лінії зв'язку), щоб обійти інші елементи управління. Це може бути дуже важливим фактором у деяких регульованих галузях (тобто банках), де всю комунікацію потрібно контролювати / реєструвати з юридичних причин (відмовляти від торгівлі інсайдерами, виявляти / блокувати передачу корпоративних чи персональних даних тощо) або компаній, де є великий страх перед внутрішніми витоками, які випадково чи іншим чином передають комерційну таємницю. У цих випадках використання вашої посилання 3G (або інших методів, таких як спроба тунелю SSH через HTTP), щоб обійти обмеження, може бути порушенням вашого контракту, а отже, злочинним звільненням (або, що ще гірше, юридичним правопорушенням), тому будьте уважні погоджуйте свою дію, перш ніж спробувати.

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

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

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

Тому що SSH може використовуватися як VPN. Він зашифрований, тому мережеві адміністратори буквально не мають уявлення про те, що залишає їх мережа (скидання бази даних клієнтів тощо). Я щойно висвітлював цей матеріал у своїй щомісячній колонці "Таємні тунелі" . Вартість деякого Інтернету 3G набагато менше, ніж турбуватися про зашифровані протоколи, що скеровують ваші дані з мережі. Плюс якщо ви блокуєте вихідний порт 22 та перевірку трафіку, ви можете легко знайти SSH на нестандартних портах і таким чином знайти людей, що порушують політику безпеки.

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

Або навіть просте переадресація порту ( ssh -L ....), якщо порт дійсно заблокований через обмеження на сайті, я б перейшов до:

• місцевий адміністратор та
• ваш керівник проекту

заведіть їх до столу і нехай вони детальніше розкриють причину, чому це заблоковано. Звичайно, для створення внутрішнього продукту вам потрібні вагомі причини, чому вам потрібен доступ до зовнішнього порту SSH (внутрішня істота: навіщо вам потрібен доступ до boxA.example.com, коли ви працюєте в компанії snakeoil.invalid)

Але я ще не бачив компанії, що блокує вихідний SSH :)

Очевидні відповіді всі були викладені. Це зашифрований протокол, який можна використовувати для обходу політики шляхом створення тунелів (це чудовий спосіб пройти корпоративних веб-фільтрів), а також загрози, яку створюють несанкціоновані канали зв'язку (зворотний проксі).

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

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

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

Зрозуміло, що вихідний блок TCP / 22 легко обійти, якщо адміністратори мережі не доклали серйозних, серйозних зусиль для конкретного блокування трафіку SSH . Більше того, адміністраторам активів потрібно бути на кулі, щоб провести інвентаризацію активів, достатню для лову 3G-модемів та підозрілих IP-адрес у 2-х NIC. У нас є сервіс ClearWire у нашому районі, тому навіть у нас є WiMax як кінцевий параметр навколо нашої мережевої безпеки.

Ми не є установою, яка в основному займається витоком інформації. Але якби ми були, нам потрібно було б поєднати драконівську політику безпеки мережі з політикою драконовських активів і аудитом. Наскільки мені відомо, я не думаю, що існує нестандартний пакет безпеки, який вимикає мережевий роз'єм активу, який описується із зовнішнім мережевим підключенням. Це може статися.

За відсутності такого пакету процес інвентаризації активів є одним з найкращих способів підключення кінцевого мережевого з'єднання, наприклад 3G або WiMax.

І нарешті, сліпе блокування TCP / 22 лише заблокує найменшу хитрість кінцевих користувачів, які мають намір порушити AUP для своєї робочої мережі.

Я бачив 22 заблокованих, коли вони виявили, що люди направляють http-трафік через 22. Це був шоу-пробка для тих із нас, хто цього потребував, але орг стояв на їх підставі.

Більшість великих організацій блокують усе, і лише дозволятимуть доступ HTTP / HTTPS через проксі-сервер.

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

Ніщо не заважає вам запустити ваш віддалений sshd на порт 80. І ssh, і sshd мають опцію -p для встановлення порту.

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

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