Вопрос: Почему Block Port 22 Outbound?


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

Учитывая трудности, которые это создает, мог ли опытный системный администратор объяснить желаемую выгоду тому, что кажется проигравшим?


54
2018-06-14 17:08


Источник


Блокировка портов - это только половина битвы. Чтобы завершить цикл, вы должны убедиться, что службы, которые вы пытаетесь защитить, не работают на нестандартных портах. - aharden
На самом деле вопрос должен быть «Зачем удалять порт 22?» так как есть миллион веских причин, почему вы хотите запустить службу ssh на нестандартном порту. Исходящий ... не так много. Я положил +1 на ответ Роберта Моира, так как он очень хорошо объяснил это. - KPWINC
@KPWINC, добавил пояснение к названию. Благодаря! - runako
Подумайте о порте 22 как о коробке пандоры. Администраторы сети не могут видеть, что находится в трафике и худшее, ssh можно использовать обход сетевой безопасности, нарушающий целостность сети. - biosFF
@biosFF: Порт 443. - Hello71


Ответы:


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

Если вы находитесь внутри брандмауэра и имеете исходящий SSH-доступ к машине в общедоступном Интернете, вы можете использовать SSH для этой общедоступной системы и в процессе создания туннеля, чтобы люди в общедоступном Интернете могли ssh подключиться к системе внутри вашей сети, полностью в обход брандмауэра.

Если fred - ваш рабочий стол, а barney - важный сервер в вашей компании, а wilma является общедоступным, работает (по fred):

ssh-R *: 9000: barney: 22 wilma

и вход в систему позволит атакующему ssh подключиться к порту 9000 на wilma и поговорить с демоном SSH Барни.

Ваш брандмауэр никогда не видит его как входящее соединение, потому что данные передаются через соединение, которое было первоначально установлено в исходящем направлении.

Это раздражает, но вполне законная политика сетевой безопасности.


65
2018-06-14 19:50



Спасибо за очень проницательный ответ. Это один из немногих ответов, которые касаются технических рисков (в отличие от политических рисков) открытых исходящих портов. - runako
+1 за хорошую техническую причину. (Тем не менее, это может сделать только злоумышленник, который также может использовать другие порты, чем TCP 22 на удаленном хосте. С которым мы возвращаемся к некоторому блоку всей политики) - DerMike
Благодаря специальному адаптированному протоколу и некоторому умному прокси-программированию это можно сделать через HTTPS - хотя и медленнее. Пока вы разрешаете исходящий зашифрованный трафик, вы уязвимы для такого рода «атаки». - Michael Sondergaard
Это хороший ответ JamesF, но не вопрос безопасности, о котором стоит подумать, потому что он принимает крайне редкий сценарий и требует использования SSH-серверов / клиентов. Вредоносный пользователь должен будет сначала использовать SSH-сервер (на вашем рабочем столе) и выяснить способ использования вашего SSH-клиента (на вашем бизнес-хосте). Поскольку вы не можете использовать порт 22 для доступа или ведения переговоров с узлом бизнес-брандмауэра (который имеет только исходящий порт 22). Если ваш стандарт безопасности настолько высок, ваш бизнес-хост не должен даже быть в Интернете в любой ситуации. - Dexter
продолжая то, что должен был сказать @Dexter, политики брандмауэра также могут быть реализованы в области интрасети. Таким образом, внутренние серверы защищены даже с настольных компьютеров в интрасети. - nass


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

Если они блокируют ВСЕ порты если нет конкретного бизнес-кейса для разрешения трафика через этот порт, после чего его тщательно управляемый то они делают это, потому что они компетентны в своей работе.

Когда вы пытаетесь написать защищенное приложение, вы упрощаете другим процессам читать и записывать информацию по своему усмотрению или у вас есть несколько тщательно задокументированных API, которые вы ожидаете от людей, которые вы звоните, и которые вы тщательно дезинфицируете?

Управление рисками - если вы считаете, что трафик в сеть или из вашей сети, идущей в Интернет, является риском, вы можете свести к минимуму количество путей, которыми может попасть трафик в Интернет, как по количеству маршрутов, так и по количеству методов. Затем вы можете отслеживать и фильтровать выбранные «благословленные» шлюзы и порты, чтобы убедиться, что трафик, перемещающийся по ним, является тем, что вы ожидаете.

Это политика брандмауэра «по умолчанию» и обычно считается хорошей идеей, с несколькими предостережениями, к которым я приду. Это означает, что все заблокировано, если нет особых причин для его блокировки, а преимущества этой причины перевешивают риски.

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

Теперь о предостережениях и, возможно, о планах освобождения:

Это может быть раздражающим, когда вы заблокированы из чего-то, что является позицией, в которой вы оказываетесь с некоторыми из ваших клиентов. Слишком часто люди, отвечающие за брандмауэр, считают свою работу «Нет», а не «Вот риски, теперь какие преимущества, давайте посмотрим, что мы можем сделать».

Если вы говорите с тем, кто управляет сетевой безопасностью для ваших клиентов, они могут поддаваться созданию чего-то для вас. Если вы можете идентифицировать несколько конкретных систем в конце, вам нужен доступ и / или гарантия, что вы будете подключаться только к определенному IP-адресу, что может быть намного счастливее создать исключение брандмауэра для SSH-соединений для этих конкретных условий, чем они было бы просто открыть соединения со всем Интернетом. Или у них может быть объект VPN, который вы можете использовать для туннелирования через брандмауэр.


36
2018-06-14 17:52



+1 для Если они блокируют ВСЕ порты, если нет конкретного бизнес-кейса для разрешения трафика через этот порт, после чего его тщательно управляют, то они делают это, потому что они компетентны в своих работах. - cop1152
-1, потому что ssh не может контролироваться людьми безопасности, но Telnet может быть. Моя точка зрения заключается в том, что, несмотря на наличие глупых политик сетевой безопасности, также характеризуется кратковременным обозначением политики как «случайный» и «ударный» без понимания реальных потребностей бизнеса. - pcapademic
Ну, вы имеете право на свое мнение, конечно, Эрик, и я с радостью измените эти слова, если вы чувствуете, что они уничижительны, но я уверен, что такая политика будет либо плохо продуманной, либо очень необычной. - Rob Moir
+1 для "всех портов" - Ian Boyd


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

Другими словами, компании иногда принимают глупые решения, а затем составляют балогийные оправдания безопасности, а не допускают свои ошибки.


17
2018-06-14 17:33



TELNET - это дыра в безопасности. Он должен быть запрещен (это просто для людей, чтобы принимать более глупые решения в будущем). - nik
Позвольте мне подробнее остановиться на том, что защитная дыра является субъективной для закрепляемой поверхности. Если вы являетесь владельцем веб-сайта, пытаясь подключиться к вашему серверу, TELNET - это отверстие. Если вы являетесь сотрудником финансовой компании, пытающимся подключиться к вашему домашнему серверу (над линиями, контролируемыми вашим работодателем), SSH - это дыра в безопасности для ваших работодателей! - nik
Учитывая, насколько легко обмануть telnet в обоих направлениях, я бы сказал, что telnet - это дыра в безопасности даже для компании, которая позволяет ей работать. Но компания, которая позволяет это, но не позволяет ssh, не собирается принимать интеллектуальные решения безопасности в любом случае. - Paul Tomblin
Telnet - это подарок, который просто продолжает давать. Это было нормально 20 лет назад, но теперь я действительно хочу, чтобы это остановилось. - Rob Moir
Все зависит от вашего POV. Вероятно, у них были люди, которым нужно было получить доступ к некоторому унаследованному процессу через Telnet, чей нам легко проверить. OTOH, вы понятия не имеете, что происходит с SSH, люди могут создавать туннели в зарубежных сетях и делать всевозможные немые вещи. Telnet не следует использовать в наши дни, но любой, кто разрешает исходящие SSH, должен искать новую карьеру. - duffbeer703


Я могу понять, что блокирование входящей связи SSH, если компания запрещает внешние логины. Но это первый раз, когда я слышу об исходящем блоке SSH.

Важно отметить, что такой брандмауэр, вероятно, ограничит только случайного пользователя SSH. Если кто-то действительно хочет SSH за пределами (который обычно будет на сервере / машине, у которого есть значительный доступ, за пределами сети предприятия), они могут легко запустить SSH-сервер на другом порту, отличном от 22 (например, порт 80). Блок будет легко обходить.

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


Edit: Хорошо, подождите секунду, у меня есть идея, почему это может быть политика.

Иногда люди используют туннели SSH для обхода основных исходящих брандмауэров для протоколов, таких как IM и Bittorrent (например). Это // может // вызвать такую ​​политику. Тем не менее, я по-прежнему чувствую, что большинство этих туннельных инструментов смогут работать с портами, отличными от 22.

Единственный способ, которым могут быть заблокированы исходящие туннели, - это обнаружение связи SSH на лету и (динамическое) блокирование этих TCP-соединений.


5
2018-06-14 17:32



Порт 443 лучше, потому что он уже считается зашифрованным, поэтому прокси не будут расстраиваться по странным данным. Вы можете легко настроить ssh-сервер, прослушивающий порт 443, и оттуда вы можете отправиться куда угодно. - bandi
В одном месте я работал, один из моих сотрудников использовал программу, которая туннелировала весь сетевой трафик через туннель ssh через наш веб-прокси до порта 80 на его домашнем компьютере, а оттуда в Интернет. Он мог использовать любой протокол, который хотел, но похоже, что он пришел из его дома, а не из компании. К счастью, он знал, как невежественные сетевые администраторы, поэтому он не рискует попасться. - Paul Tomblin
Конечно, если вас поймают, пройдя один из этих сложных танцев, чтобы совершить кругосветное брандмауэр, вы не можете действительно признать невиновность и невежество. Немного сложно сделать все это и сказать «извините, босс, он просто работал», поэтому я не понимал, что я делаю что-то неправильно ». - Rob Moir


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


4
2018-06-14 17:11



Разве это не означает, что они также должны блокировать HTTPS? - runako
Нет, они включают проверку SSL. Этот процесс расшифровывает HTTPS, затем повторно расшифровывает входящие / исходящие пакеты, вводя доверенный сертификат на всех рабочих станциях по групповой политике. Таким образом, они могут фильтровать / сканировать то же, что и с HTTP. Банковская индустрия является одной из самых драконовских сетей для блокировки сетей. - spoulson


Чаще всего это скорее блокировка всех исходящих подключений, если это не требуется, и пока вы не попробовали, никто не потребовал, чтобы порт 22 был доступен для исходящих подключений (всего 80, 433 и т. Д.). Если это так, то решение может быть таким же простым, как связаться с IS / IT и сообщить им, почему вам нужно добавить исключение, чтобы ваша станция могла отправлять исходящие SSH-соединения на определенные хосты или вообще.

Иногда вызывает беспокойство, что люди могут использовать средство для использования SSH в качестве способа настройки прокси (через перенаправление портов по ссылке), чтобы обойти другие элементы управления. Это может быть очень важным фактором в некоторых регулируемых отраслях (например, в банках), где все коммуникации должны контролироваться / регистрироваться по юридическим причинам (препятствовать инсайдерской торговле, обнаруживать / блокировать передачу корпоративных или личных данных и т. Д.) Или компаний, где это большой страх перед внутренними утечками, раздающими, случайно или иначе, коммерческую тайну. В этих случаях использование вашей 3G-связи (или других методов, таких как попытка туннелирования SSH через HTTP), чтобы обойти ограничения, может быть нарушением вашего контракта и, следовательно, увольнением (или, что еще хуже, правонарушением), поэтому будьте осторожны соглашайтесь, прежде чем пытаться.

Еще одна причина может заключаться в сокращении исходящего отпечатка (к внутренним услугам, доступным для хостов в брандмауэрах компании и в мире в целом), если что-то неспособное сможет установить себя на машине, запущенной компанией. Если на порту 22 невозможны SSH-соединения, многие более простые хаки, которые пытаются использовать SSH-серверы с грубой силой, поскольку один из маршрутов распространения будет заблокирован. В этом случае вы снова можете просто попросить добавить исключение, чтобы ваш компьютер мог создавать SSH-соединения, если эти подключения могут быть оправданы для людей, контролирующих брандмауэр (ы).


3
2018-06-14 17:33



Да, вполне вероятно, что все исходящие службы, которые не должны использоваться, могут быть заблокированы (по умолчанию). - nik
Но блокировка tcp / 22 не предотвратит безопасную исходящую связь (которая может быть сделана на любом порту, если у пользователя есть слушатель снаружи, что в наши дни не так сложно). - nik
Если внутренняя сеть использует связь SSH, ее блокировка не будет работать, и если нет необходимости в SSH-связи, обычно в сети не будет уязвимых SSH-систем для прослушивания. И, типичное распространение червя не пытается перебрать SSH (если вас беспокоит этот взгляд на en.wikipedia.org/wiki/SSHBlock), скорее всего, вы попробуете tcp / 445 с вашими оконными машинами. - nik


Возможно, у ваших клиентов есть нетривиальные данные, которые они хотели бы сохранить. Исходящий SSH - это очень плохо, чтобы открывать для всей сети. Это довольно тривиально, чтобы обойти прокси, данные, чувствительные к утечке, и быть вообще неприятными.

ИМО, все, что проходит через сетевой / интернет-периметр, следует понимать и контролировать. Если группе разработчиков требуется доступ к серверам хостинг-провайдера через ssh, это нормально - но это также необходимо документировать. В целом в тех местах, где я работал, мы устанавливаем выделенные VPN-соединения между сайтами, расположенными за пределами нашей сети (существенно расширяя нашу внутреннюю сеть) и избегаем клиентских протоколов, таких как SSH через Интернет.


3
2018-06-15 00:24



Спасибо за ответ. Как вы обрабатываете выделенные VPN на сайтах вне вашего контроля (например, EC2, веб-хосты и т. Д.)? Являются ли эти поставщики, как правило, желающими просто выполнить эту настраиваемую настройку для вас, или вам, как правило, приходится делать некоторые большие минимальные обязательства в отношении бизнеса, чтобы заставить их сделать это? - runako
Кроме того, вы беспокоитесь, что вы заставляете людей использовать сетевые карты 3G для выполнения своей работы? По моему опыту, блокированные сети неизбежно приводят к большому количеству 3G-карт и других скрытых обходов, поскольку люди не могут выполнять свою работу заочно, если им придется ждать, пока ИТ-специалисты одобрят их использование, если кто-нибудь даже знает, кто для вызова исключения. (Один вопиющий случай включал почтовый сервер, который не принимал бы входящие вложения из Интернета. Yikes!) Мне было бы любопытно, как вы управляете этим балансом. - runako
Добавьте в комментарий о переадресации портов через ssh, и я думаю, что это правильный ответ на вопрос. ssh может быть хорошим протоколом, позволяющим через прокси-сервер. Администраторы могут следить за тем, что происходит, могут блокировать перенаправление портов, и люди могут использовать его для удаленной оболочки и удаленных служб копирования. - pcapademic
Мы достаточно большие, что, вероятно, 90% наших услуг не требуют запуска исходящего администрирования. Обычно, когда мы это делаем, мы создаем выделенный VPN-туннель в RFP, который, как правило, устраняет поставщиков, которые не смогут или не смогут его предоставить. Из-за этого я считаю, что у нас есть минимальное количество людей, использующих 3G и подобные обходные пути. - duffbeer703
Кроме того, вы не можете позволить людям безопасности диктовать доступ. Вы позволяете разработчикам приложений и сетевым пользователям разрабатывать приемлемое решение с учетом обзора безопасности. Выработайте это решение на ранней стадии процесса, а не утром, когда вам нужно идти в производство. Это задерживает вас от задержек в стиле DMV при получении запросов. - duffbeer703


На мой взгляд, есть две основные причины блокировки исходящего порта 22.

Во-первых, как отмечали люди, пересылка портов SSH может использоваться как прокси-сервер или обход вокруг других портов и служб, чтобы избежать политики ИТ, заявляющей, что такой трафик не разрешен.

Во-вторых, много вредоносных программ / бот-сетей будет использовать порт 22, потому что его часто считают «безопасным» и, следовательно, разрешенным. Затем они могут запускать процессы из этого порта, а зараженные компьютеры также могут запускать атаки SSH с использованием грубой силы.


3
2018-06-15 03:38





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

Или даже некоторые простые переадресации портов (ssh -L ....), если порт действительно заблокирован из-за ограничений сайта, я бы пошел:

  • местный администратор а также
  • ваш менеджер проекта

доведите их до стола и дайте им понять, почему это заблокировано. Конечно, у вас должны быть веские причины, по которым вам нужен доступ к внешнему порту SSH для разработки внутреннего продукта (внутреннее: зачем вам нужен доступ к boxA.example.com, когда вы работаете в компании snakeoil.invalid)

Но мне еще предстоит увидеть компанию, блокирующую исходящий SSH :)


1
2018-06-14 17:12



Я видел одну компанию, которая блокирует исходящий SSH. Они также блокировали почти все остальное, и, например, вирус проверял все передачи HTTP с использованием прокси. Компания была центральным депозитарием ценных бумаг. - Esko Luontola
Я работаю в такой компании. К счастью, SSH можно проложить через https. Конечно, они только позволяют https подключать 443 ... sslh к спасению! - Mikeage
proxytunnel FTW :) - serverhorror