Почему порт блока 22 исходящих?

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

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

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

ssh-R*:9000:barney:22 wilma

и вход в систему позволит взломщику ssh, чтобы портировать 9000 на wilma и говорить с демоном barney SSH.

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

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

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

Конечно, если Ваши администраторы умны, они должны наблюдать за ssh трафиком, не только портом 22 трафика. Так, это кажется, что у Вас есть проблема политики, не техническая проблема.

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

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

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

Я видел 22 заблокированных, когда они обнаружили, что люди направляли трафик HTTP до 22. Это был выставочный стопор для тех из нас, кому был нужен он, но org стоял на своем.

Очевидно, исходящий блок TCP/22 легко обойти, если администраторы сети не предприняли серьезные, серьезные шаги для блокирования торговли SSH определенным. Кроме того, администраторы актива должны быть в курсе событий достаточно для выполнения актива, инвентаризирующего достаточный для ловли 3G модемов и подозрительных IP-адресов на 2-м NICs. У нас есть услуги Clearwire в нашей области, таким образом, у нас даже есть WiMax как управляемая концом опция вокруг нашей сетевой безопасности.

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

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

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

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

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

Это верно, telnet должен быть уничтожен в любой современной сети. Но, я вижу разрешение telnet из сети при запрете ssh. Telnet менее способен, чем ssh, и я могу всегда контролировать поток, в режиме реального времени, через моих снифферов. Если у меня нет устройств telnet в моей базовой сети, и некоторый пользователь хочет к telnet, о чем я забочусь. Я вижу его и проверяю, что это не угроза.

Конечно, все это зависит от идеи, что политика по умолчанию состоит в том, чтобы заблокировать весь выход и только позволить определенные протоколы. Бонусные очки, если Вы проксируете их перед хитом край.

Поскольку SSH может использоваться в качестве VPN. Это шифруется, таким образом, у сетевых администраторов нет буквально идеи, что оставляет их сеть (дамп базы данных клиентов, и т.д.). Я просто покрыл этот материал в своем ежемесячном столбце "Secret Tunnels". Стоимость некоторого Интернета 3G чертовски много меньше, чем необходимость волноваться о зашифрованных протоколах, направляющих Ваши данные из сети. Плюс то, если Вы принимаете значение по умолчанию, исходящий порт блока 22 и трафик осматривает Вас, может легко найти SSH на нестандартных портах и таким образом найти людей, нарушающих политику безопасности.

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

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

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

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

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

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

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

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

Существует две основных причины для блокирования исходящего порта 22, по-моему.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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