Зачем блокировать исходящий порт 22?

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

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

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

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

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

SSH-R *: 9000: Барни: 22 Вилма

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Другая причина может заключаться в уменьшении исходящего пространства (для внутренних служб, доступных для узлов в брандмауэрах компании и для всего мира), если что-то неуместное удастся установить самостоятельно на управляемой компанией машине. Если никакие соединения SSH не возможны на порту 22, многие более простые хаки, которые пытаются использовать логины 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-й сетевой карте. У нас есть сервис ClearWire в нашем регионе, поэтому у нас даже есть WiMax в качестве конечной опции для обеспечения безопасности нашей сети.

Мы не учреждение, которое в основном занимается утечкой информации. Но если бы мы были, нам нужно было бы объединить драконовскую политику сетевой безопасности с драконовской политикой активов и аудитом. Насколько я знаю, я не думаю, что существует готовый пакет безопасности, который отключит сетевое гнездо актива, инвентаризующего с каким-либо внешним подключением к сети. Это может быть

В отсутствие такого пакета процесс инвентаризации активов является одним из лучших способов перехвата конечного сетевого подключения, такого как 3G или WiMax.

И, наконец, слепая блокировка TCP / 22 блокирует только наименее хитрых намерений конечных пользователей нарушить AUP для своей рабочей сети.

Я видел 22 заблокированных, когда они обнаружили, что люди направляли http-трафик через 22. Это было шоу-стопором для тех из нас, кто нуждался в этом, но организация стояла на своем.

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

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

Ничто не мешает вам запустить удаленный sshd на порту 80. Как ssh, так и sshd имеют опцию -p для установки порта.

Конечно, если ваши администраторы умны, им следует следить за трафиком ssh, а не только за портом 22. Похоже, у вас есть проблемы с политикой, а не с техническими проблемами.

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