Я программист и работал с несколькими клиентами, чьи сети блокируют исходящие соединения на порту 22. Учитывая, что программистам часто требуется использовать порт 22 для ssh, это кажется контрпродуктивной процедурой. В лучшем случае это заставляет программистов выставлять счет компании за 3G Интернет. В худшем случае это означает, что они не могут эффективно выполнять свою работу.
Учитывая трудности, которые это создает, может ли опытный системный администратор объяснить желаемую выгоду от того, что кажется безнадежным?
Я не вижу, чтобы кто-то подробно описал конкретный риск, связанный с переадресацией портов SSH.
Если вы находитесь внутри брандмауэра и имеете исходящий 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, когда я там работал, но разрешила телнет! Когда я спросил об этом, они сказали, что 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-адресов на вторых сетевых адаптерах. У нас есть услуга ClearWire в нашем районе, поэтому у нас даже есть WiMax в качестве конечного варианта нашей сетевой безопасности.
Мы не организация, которая серьезно озабочена утечкой информации. Но если бы это было так, нам пришлось бы сочетать драконовскую политику сетевой безопасности с драконовской политикой активов с аудитом. Насколько мне известно, я не думаю, что существует готовый пакет безопасности, который отключал бы сетевой разъем актива, инвентаризации с помощью какого-либо внешнего сетевого подключения. Это может произойти.
В отсутствие такого пакета процесс инвентаризации активов - один из лучших способов поймать конечное сетевое соединение, такое как 3G или WiMax.
И, наконец, слепая блокировка TCP / 22 заблокирует только малейшее из намерений конечных пользователей нарушить AUP для своей рабочей сети.
Я видел 22 заблокированных, когда они обнаружили, что люди направляют HTTP-трафик через 22. Это было препятствием для тех из нас, кто в этом нуждался, но организация стояла на своем.
Большинство крупных организаций будут блокировать все и разрешать доступ HTTP / HTTPS только через прокси-сервер.
Я был бы очень удивлен, услышав о каких-либо корпорациях, разрешающих прямые внешние подключения с настольных компьютеров или серверов, если в этом нет особой необходимости.
Ничто не мешает вам запустить удаленный sshd на порту 80. И ssh, и sshd имеют параметр -p для установки порта.
Конечно, если ваши администраторы сообразительны, они должны следить за трафиком ssh, а не только за трафиком порта 22. Итак, похоже, у вас есть проблема с политикой, а не техническая проблема.
Однако, как указывали другие, зашифрованные протоколы могут вызвать изжогу у людей, которым приходится беспокоиться о различных проблемах с соблюдением требований.